Was out the other night for a beer with a friend and former colleague and he was telling me of the interview process where he works and it got me thinking about the technical interview stage when trying to hire someone. Having interviewed for positions myself, I sometimes was left questioning the effectiveness of the process itself. I know I haven’t been coding forever, but I’ve been through interviews that left me thinking “they haven’t even begin to assess what I’m capable of”, and like that it was over.
I think a lot of potential candidates may get unfairly filtered out of the hiring process. Let’s look at it; a hiring manager may ask one of their more senior developers to ‘do a technical interview’ of a potential candidate, that developer (who probably prefers to write code) ‘interviews’ them, then reports his/her findings and the search goes on or an offer is made. If you are in charge of hiring someone, does the following sound familiar?
“Here is your task sheet. Your job is to program an App that does the following three things. (e.g. make a request to a webservice, parse the result, then display those results in a table view). You have 3 hours. Here are the constraints (e.g. which frameworks you can or can’t use, which format the webservice is in, etc.)
I already see a few problems with this approach, though not a bad one, but it leaves me thinking and my questions to the interviewer are these: How often do you actually need a programmer to get a task like that done in under 3 hours on a regular basis? In my experience, not often. Do you want fast solutions from a potential hire, or good solutions? If a programmer is not familiar with your approach to solving tasks (i.e. because he’s not familiar with the same frameworks you are when you designed the task), does that make him a bad programmer? When you assign the tasks, are you making it clear to the programmer WHAT it is you are actually testing him/her on before they begin?
As it often occurs in software development, many problems arise simply because people don’t communicate with each other. They dive into coding and report when they’re done. If it works, everyone goes “Hooray!” Would you ever have to take that code 4 months later and extend it? Or better, have another programmer extend it? How long would it take for that person to get up to speed? (because perhaps the first person wasn’t following standard practices / design patterns)
During this conversation over a beer, I challenged this friend of mine to re-evaluate their techniques. Ultimately in a tech interview I want to know a few things from a potential hire that are slightly more abstract but ultimately more telling if that person is someone that would be nice to work with:
- Before they start coding, ask them HOW would they approach the problem? i.e. in plain English (or whatever language you speak at the office). This tells me more about how the programmer thinks. How they might structure their work. Ultimately when working in a team environment, the way a person structures their code is going to have a big influence over how others will change it later, and speaks for its future maintainability. Getting something to just work is the beginning of being good at what you do. This would tell me they’re not just a stackoverflow.com abuser who just looks for someone else’s posted recipe. If you can understand HOW a problem is approached, it’s easier to forgive them for not knowing the framework, or the approach you perhaps already thought they should take (let’s face it, if you designed the test, chances are you have tunnel vision when it comes to how to solve the problem.)
- When providing a task, have you condensed the task into clear subtasks that are independent of one another? For example, what if they don’t have experience with Asynchronous data communications, but DO have experience with table views, can they at least create a table view that displays dummy data? This way they can create the table view at the beginning of the test, then teach themself what they don’t know so well with their remaining time. Or put another way, if tasks B, C, D, and E are dependent on the success of task A (which the candidate for whatever reason can’t do), you’ve torpedoed a potential good hire because of a poorly designed test.
- Have you made it clear which areas of knowledge you are testing? “We just want to be able to see that you know a bit about x-y”, so that even if the candidate doesn’t solve the task in its entirety, he/she can show you at least how fit they are in that area of knowledge.
- Further, after having discussed their approach, so that you get some confidence that they do know conceptually what to do, why give them a hurried 3 hours? Why don’t you tell them to return the task to you tomorrow (committing their results to a repo along the way)? If they already know conceptually what to do, (they can’t really cheat that), you can then give them some time to solve the problem in a way that suits them best. The chances of them cheating are going to be low, especially when they’ve already told you what they’ll do. In the end, what they return to you should indicate whether they did do that, or if their solution was totally different than their conceptual approach, you can give them a chance to explain themselves afterwards.
Even if they somehow did make it past all the guards, and cheated somehow, this is why every job has an initial probation period. It will come out in the wash that this person can’t do what they said, so I really wouldn’t worry about them solving the task off-site.
Anyway, it’s worth thinking about. I’m sure that many good candidates are passed up for positions just because the format of the evaluation process is flawed. So my hope is that if you consider these above, you, and they, will find the right fit.
(PS: Self-promotion: Also wrote an article, now for me a bit outdated but still useful, on what to ask developers at the interview… before it gets to this stage.)
(UPDATE: This article is also a very excellent read!)