Coding Interviews: Assessing for Potential
If you are a developer who cares about the culture you work in, chances are you will get involved with the technical hiring at your company. Working out who to hire can feel as daunting as learning to code all over again, and way more risky — there are no A/B tests here, no roll backs, no rebase! You are testing in production.
Sometimes the pair programming interview is all that stands between you and working with a brilliant jerk for ever and a day. Worse, it could lead to a missed opportunity to work with someone great who is full of potential, but crap at interviews.
In my role I am lucky to work with an awesome hiring squad made up of passionate developers volunteering their time. I help get them trained and ready to run interviews for our engineering candidates and assess them objectively.
Understanding how to conduct the verbal interviews seems straight forward, but the pair programming stage often seems ambiguous to new interviewers. I get questions like, “do we swap after each test passes”, “should I ever be typing?”, “when do I drive?”, “should I insist I get my hands on that keyboard”. These questions show me I have missed the mark in communicating the intent of the whole interview stage.
Assess for potential, not just experience
Early on in my experience with hiring people — before the coding interview — I would get candidates to send through their solutions to a fairly mundane coding challenge, and then spend ages trying to compile and run them locally, looking for tests, patterns, code smells and other attributes that show their coding experience. Sometimes I would reject them, after all the hours they had invested, possibly away from their families, because their recent experience didn’t extend to test driven development, or something as trivial.
I can remember being disappointed when receiving a particular code submission that was fairly basic, used older coding constructs and had no tests. I had been excited by the candidate’s resume and then in the verbal interview, as her values and passion were strongly aligned with our culture. At this point, we would usually have rejected, but I brought her in for the coding interview anyway.
I started the interview by asking about the absence of unit tests, and she said “what’s a unit test?” My heart sank. (now, keep in mind this was a while ago —yes, I still fondly recall on-prem server rooms). But, “must have unit testing experience” was in our criteria. I thought, eh, I’m here for another 56 minutes, might as well answer that question. I wrote one test and made it pass. This was one of those moments when you swear you see the light bulb go off. Her face lit up, she took back the keyboard and proceeded to rewrite her whole code base, all wrapped up in unit tests, excitedly asking questions along the way.
That day the penny dropped for me too. This was someone who was excited to learn. Instead of hiring experience, I could teach it! After all, hadn’t someone done that for me?! I shudder to think how long I had been dismissive of people who had just not been given the same opportunities I had, and hadn’t been in a team before that valued the same engineering practices I did. The risk paid off. Within a handful of months she was inducting other new starters to the ins and outs of TDD.
My advice for conducting these interviews is to give the candidate space for a light bulb moment. Step in to show a keyboard shortcut or a new language feature, enlighten them to a pattern or construct and see how they run with it.
The goal of the interview is to work out if they can cobble together a basic algo and have the potential to learn the rest. How you get there is highly contextual. Maybe the person who forcefully rejects your ideas about cleaner naming conventions won’t be the one you hire, despite their demonstrated grasp of high cohesion.
Chicken and the egg
If you don’t yet have a learning and teaching culture, with a sprinkle of programming practice on top, you may want to experiment lightly with this approach before diving in head first. Having said that, bringing in voracious learners who have room to grow may just be the best way to get that culture started.
Show a little respect
The code submission is no longer a stage gate for us. If someone has taken the time to complete our coding challenge, then we take the time to see how much potential they have. Every interview is a chance to up-skill more of our hiring squad and provide even the unsuccessful candidates with feedback and advice on how they can improve and be successful next time.
I hope this post inspires you to get involved with the tech hiring at your company. And maybe, to try something new. Please add a comment below if you have any questions.
