if you can read, you can code

Hi,

Months ago, I read a particularly interesting line from Haruki Murakami's Colorless Tsukuru Tazaki and His Years of Pilgrimmage- 'if you can read, you can cook'. Lately, I've found the line coming to mind whenever I am asked about my SQL programming experience during a job interview.

These questions range from informal (talk about your experience) to formal (please complete this questionnaire/assessment). The result is either a near philosophical conversation about database querying or a very detailed account of what projects I happened to work on in the past, respectively.
 
Both lines of discussion are useful in certain contexts, of course. One such case is when no specific role is being applied for.

But I struggle to understand how helpful they might be in learning about a candidate's programming ability to complete a specific role or project. The reason I toss this thought out there is because almost every programming script I ever wrote required me to do at least one of the following:
 
1) Read an old script I wrote that did a similar function
2) Search online for the correct syntax
3) Ask a colleague for guidance
 
Often, I would do all three. Since all three of these methods require reading (even #3, since I usually 'asked' via email), you could say my programming slogan is 'if you can read, you can code'. Just like with cooking, once certain basic knowledge about the programming language is known, you can pretty much solve any problem you want as long as someone else wrote down what you might need to know in a place where you can easily find it. But beyond listing those three points, it is tough to highlight that process-minded approach in an interview setting when the questions encourage strictly backward-looking responses.

I think my overall sense is that these types of questions do not offer much insight into how a candidate would complete the jobs I am applying for. In other words, for these specific roles, I think it is generally not relevant to talk database philosophy (since the role is not for a computer science professor) or use an assessment that asks detail-level questions like what is the difference between a clustered and non-clustered index (since most jobs tend to allow access to the internet, a useful tool for answering such questions) (1).

But if my conclusion is true, so what? Or to put it more professionally, what is the best way to assess the skill level of a candidate?

In a broad sense, this is an example of perhaps the trickiest part in defining an open position- what skills are needed prior to starting the role and what skills are OK to learn as the new hire goes (2)?

In my prior role, I faced this question and concluded that we needed to see clear evidence of the things which could not be taught (or, the things I was incapable of teaching anyone) if we were to move forward with any candidate.
 
To make an attempt to answer my own question in this context- I would either try to confirm that a candidate has the bare basics needed to quickly learn, on the job, the programming required or offer a simple short term project/contract in which a successful outcome will utilize all the skills needed that the organization is incapable of teaching a new hire.

I'm not sure this will work perfectly but it is better than what seems to be the current trend. It does at least have the advantage of tailoring the recruiting process to fit the job opening as closely as possible. And I can't (yet) think of a good reason why that would not be a strong design for any job interview.

Signed,

The Business Bro


Footnotes?

1. OK, hotshot, we know all this is a way to hide that you have no clue what a clustered index is!

Who cares? Google it. Here is the first hit from my search. It took seven seconds to find, twenty seconds to read, and the rest of the minute to understand.

My technique for googling SQL concepts is very simple. Over time, I've come to a tentative conclusion that the website Stack Overflow is my preferred source for finding answers to my SQL questions. But, I do not find the navigation within the website very helpful.

To get around this problem, I almost always type my search terms into Google and include 'stack overflow' at the end. This takes advantage of Google's superior ability to filter and find websites while ensuring that, in the event of a tie, content from my preferred website is placed atop the list.
 
2. Passion...

From my own experience, doing this part of the process properly lead to very interesting insights. One such moment involved 'passion' for the role- surely, we would seek candidates ' passionate' about the industry we were in?
 
When I took a closer look at the existing team (and company), I realized that not a single person could be described as 'passionate' about the industry. They were passionate about many things- teamwork, completing high quality work, constantly learning or growing, etc- but not about the industry. So I played a hunch and dismissed it as a category for consideration.

Was I right to do this? Possibly not. Likely not. It may have been the case that finding someone passionate about the industry would have truly transformed the team. But the team had been transformed in the past by those without this passion, too. Ultimately, it seemed a better use of time to focus on other attributes in the hiring process.

What were those attributes? They were not technical skills. Rather, they were the basic components of fitting into the team- characteristics such as an enthusiasm to learn and the ability to communicate clearly in writing. The things I or the team could teach were assessed on whether a candidate reached the bare minimum level needed to learn from us.