Sunday, May 15, 2016

A short comment about the technical interview

There’s been a terrific backlash against the whiteboard-test commonly given in technical interviews. I think it’s a terrible tool to use in an interview. What the hell is the interviewer really testing for? Proximity to date-of-graduation? How well someone has memorized a breadth-first-search algorithm?

The first question I asked myself after several years of being a bad interviewer was “What am I really testing for when I interview a candidate?”

What’s the goal of each section of the interview? Better yet, let me back up even more: What are the values of my product development team (the team that includes the software developers) and the values I look for in co-workers?

Once that’s answered, an interview can be developed to filter for these values.

That list is for another post, so for now I want to focus on two values that’s pertinent to the kind of developer I like to hire: The ability to intelligently, quickly, and accurately find solutions to tasks and problems and implementrobust(1) solutions quickly. And: Are they a mature human being who can communicate well, govern their emotions while under stress (interviews are stressful), and have some level of intellectual curiosity with the ability and drive to satisfy this curiosity?

One of the big complaints lately was about getting the dreaded (and useless) “Go to the whiteboard and code a BFS”, or “Go to the whiteboard and code a maze-solver”, one solution for which requires a BFS and an implementation of Dykstra’s shortest-path algorithm (I had to look it up, of course). I’d never ask someone to do that at a whiteboard sans tools, references, etc., ever. What the hell would it tell me other than how well the candidate can remember university CS degree work? (Maybe it might tell me whether a developer suffers from not-invented-here syndrome, but that’s probably silly, and I digress)

But the question itself is a good one. Even though very few developers, especially ones who’ve been working for several years, can stand up and — under the stress and pressure of an interview — code this up from memory. But most developers understand the problem, regardless that this is one that seldom comes up in the daily grind of work, and given the right tools the best candidates can arrive at the solution. Now I don’t know about you, but I want to work with the kinds of devs who can find the right solution using the right tools.

So here’s what I’ve been doing to replace the whiteboard test: I want to know what kind of person the candidate is to work with. Given an uncommon problem (implement a maze-solver, or implement k-Nearest-Neighbor), lets use the tools we’d expect to have available to us day-in-and-day-out and come up with the beginning of an implementation. So therefore, the candidate and I sit side-by-side in front of their laptop and I watch them, and if necessary coach them through, work on the task.

I look for several things: do they search for solutions in the problem domain; can they discern between correct and robust solutions vs. incorrect, hacky solutions; a corollary to the previous point is do they understand what they are reading, and understand the underlying algorithms and implementation; do they simply pick the first answer they find from Stack Overflow? (a big red flag). This latter point should tell me whether or not a candidate truly understands data-structures.

Overall, can the candidate research, understand, and implement a correct solution to a problem that’s either unfamiliar to them or not memorized and do so in an environment that resembles the real-life environment of our team? What are they like to work with? Are they eager to learn or uninterested in anything not immediately familiar? Are they easy to work with or easily frustrated and/or defensive? Can they use the tools they will be expected to use in their daily work(2)? Can they communicate clearly? Do they ask pertinent questions?

I think that the best way to find whether or not you want to work with someone and have them on your team is to — wait for it — work with someone. Although an interview of an hour or two isn’t the same as working with someone on a team (it’d be great to bring in a candidate for a day or two and have them work alongside us, but I haven’t figured out how to get this though H.R.), it’s close enough if and only if you set up the interview to simulate as closely as possible the actual conditions of your technical environment.

(1) adj: strong and effective in all or most situations and conditions

(2) And we’ll do some debugging too. Can they and do they use a debugger, logs, and print statement? Do they ask the right questions when debugging: what do I expect the code to do, what is the code actually doing, and how do I know it’s actually doing it?

No comments:

Post a Comment