Recruitment-related tasks have been filling most of my days at work since January. Now I am finally seeing a glimpse of light at the end of the tunnel. We are close to signing a contract with a good back end developer, and today for the first time we had a really promising candidate for the front end role.
By now I have a pretty solid and stable process worked out. First I read their CV and/or cover letter, and ask for clarification where I their background really seems to not fit our needs. Well over half of the candidates get discarded at this stage – surprisingly many candidates seem to apply for any job that seems even remotely related to their skills, and don’t hesitate to apply for jobs that they are clearly under-qualified for.
Next I ask them to do a coding task at home, at their own pace. After this we have a brief phone interview. I used to do it the other way round, because I didn’t want to do give them unnecessary work – the task takes a couple of hours to do at least, whereas a phone interview is no more than 30–40 minutes. But it turned out that a lot of people who sounded knowledgeable on the phone failed the coding task, so it ended up wasting a lot of my time instead. And since I get to decide, I’d rather have them waste their time, not mine. The coding task not only filters out the candidates who can talk but not do – it also gives us something concrete to discuss during the phone interview, and therefore makes the interview much more effective.
Now the funnel works quite well. Occasionally I say yes to someone who I am unsure about, and thus far these candidates have always disappointed in the next round. So if the candidate doesn’t seem to have enough relevant experience, they don’t do well on the coding task. And the ones whose coding task does not impress don’t make a better impression on the phone.
All the coding tasks until now have been sort of mediocre, “good enough” at best. We’ve been trying to weigh them against each other but never really come to any firm conclusions. Is one kind of mediocrity better than another? What’s worse, stupid variable naming or badly organized code? How bad is too bad?
The one we got today stood head and shoulders above all the previous ones, and the interesting thing was that this time there was no discussion, no hemming and hawing. The moment we saw the code it was obvious to all those involved that this one was in a completely different league from the others. Distinguishing a really good solution from a mediocre one is so much easier than comparing two mediocre ones. Even if we for some reason end up not hiring this guy, he has at least given us a yardstick for evaluating future candidates.
Another observation we made today was that the good front end developers we’ve met (including those in our team) are all ex back end developers. In other words, they are developers who have chosen to specialize in front end work. The ones who come from the other direction – the designers, the web developers – lack the necessary fundamental development skills. Their solution may work but just it’s like a house of straw: you can see at a glance that it is structurally weak. They don’t build, they hack.
PS: I just counted: I have received 43 applications for this job, reviewed 13 coding tasks, had 10 phone interviews and 2 face-to-face interviews (with 2 more already booked).
Leave a comment