The glory and misery of IT interviews, from the other side of the table

At first I laughed while reading A Sad Report on the State of the IT Market, but then it gave me chills. It describes how plenty of people read a few blog posts by Googlers and are now copying them blindly. A few years ago interviewers liked to ask questions such as “Why are manhole covers round?” or “How many trainsets does the Prague Metro put into service each day?” until everyone realized those questions were useless. I hope we soon get to a point where no one makes you code at a whiteboard or on paper in an interview. The most you learn from that sort of nonsense is how the candidate responds under stress and how much they have memorized. Samuraj explains this in his article. I've said it here many times. Whether someone can write merge sort in twenty lines or forty is irrelevant. What matters is whether they fit the culture of your development team. Of course, if inflated egos define your culture, the whiteboard will come in handy. That's something you have to judge for yourself. In this article I'll offer the view from my side of the table, as someone who conducts several interviews a week. This is my own know-how, but feel free to use it if it helps improve the way interviews are done today.

First of all, treat candidates the way you'd want someone to treat you. I never make candidates program at the whiteboard, because that's like being back at school. If I want to see how someone thinks about a problem, I give them a take-home assignment. I don't mind if they look things up on Google. That's life. There's one exception. If someone lists experience with distributed systems on their résumé and I ask where they've encountered CAP, I expect one practical example of running up against that constraint. It tells me they understand the issue in practice. It carries much more weight than a mathematical proof on the whiteboard followed by an explanation that they used a replicated cache and never actually ran into CAP.

If we're talking about school, I'd rather ask about the subject of their final thesis. It often tells you more about someone than you might expect. At the very least, it shows how much they cared about doing something worthwhile and what they could get excited about. Unfinished studies can also tell you quite a bit. I always want to know why the candidate didn't finish. What I'm getting at is whether they reflect on it, whether they regret it or make excuses. I can't stand people who dodge responsibility. The first and most important quality is a sense of ownership (what's the Czech term for that?). It isn't a definitive sign, but it tells you something.

What matters to me is where and how people keep learning and why they decided to make a change. “The culture there is shit” doesn't satisfy me. I want to know what they did to improve it. That goes especially for people who present themselves as a scrum master or agile coach. Answers like “I'm the smartest person there” or “I won't do X” are major warning signs. We already talked about the smartest person in the room and egos at the whiteboard. In my experience, people without that “I won't do X” attitude are much more open to learning. Those are the people you want.

Once I've formed a picture of a candidate, I give them a take-home assignment. At our company, it involves writing code against our public API. When they submit it, the developers take a look and we usually send back their feedback. Sometimes I paste their comments in as they are. The reactions are interesting. The worst one for me is “Nobody asked for that in the assignment” when, for example, the feedback points out that the code has no tests at all. Damn it, whose work is on show here, mine or the candidate's? Sometimes a candidate simply says they wanted to save themselves some work, explains why, and comes back with a much better second version. That's the right approach, and we appreciate it. Incidentally, when you give a developer this sort of feedback, they appreciate you and think more highly of you. It shows that you take an interest in their work and respect it. I haven't always done this. Sometimes the result is such a mess that all you can say is that you have a fundamentally different idea of what it should look like. And sometimes the code is just great, so I write back straight away, “The code looks great. It's time to meet the developers.”

I'm hardly interested in what the developers and candidate say to one another. That's between them. I always tell our developers to be honest with the candidate. If something here bothers you or isn't working, say so. Do they want to see our code? Show them. What I want to impress on people, and I'll say it again, is “Treat them the way you'd want to be treated if your positions were reversed.” I call this round “sniffing each other out.” The aim is to see whether the candidate and their new colleagues get along.

Either way, there is little point in adding more rounds. It's a lottery, so I don't really understand why people need them. Things can drag on at our end too. Sometimes we're negotiating the budget and looking for room to maneuver. That's why I try to be honest with candidates. Something that doesn't work out today may be on the table again in a few months. When I make a final offer, I've found it helps to write down why I think the job would suit the candidate. Before the take-home task, I also send a summary of what I think defines our culture and the principles we follow, with links. A personal approach works well in general. I take pride in it from the first time I contact someone. Above all, no automated emails from templates.

I'm convinced that the culture and vision I emphasize in interviews, a personal and fair approach, and an interesting product are what usually tip the scales in our favor. I hope this helps improve interview culture, even a little. Now that we've rooted out the most idiotic HR question, “Where do you see yourself in five years?” or “Why are manhole covers round?”, let's get rid of schoolroom exercises like “Write me a reverse function on paper.” Here's to better interviews.