Interviewing Developers: triggers, part I

5 min readNov 24, 2016

The series:

This post also appears in my original blog.

Recently I explained the key principles that I follow when interviewing developers, but didn’t cover an important aspect — the triggers that may significantly influence the flow of the interview. The trick is the more you do interviews, the better you deduce the character of a candidate from some of their behaviors. In particular, I certainly learned to notice particular responses that the candidates we don’t hire may give. Even though one can’t base the final decision on a single phrase, these triggers may both save some time and allow to avoid fatal mistakes. To begin with, here are 4 phrases that I heard from some developers.

Candidate: “Normally I work in IDE, so I can’t solve this exercise on paper”

I’ve seen this one several times and it always came as a surprise. Yes, we love paper-programming! We ask quite some practice questions, but hardly ever give the candidate a laptop. I acknowledge that developers rely a lot on the comfort of IntelliSense, ReSharper and ability to run the code and tests that a laptop with an IDE provides. At the same time, offering to do an exercise on paper we want to check certain things about the candidate and refusal to undergo this check is what brings me closer to rejecting.

The idea behind coding without an IDE and compiler is that it allows us to see how a programmer makes assumptions about their task and tools and acts under a healthy portion of uncertainty. In other words, paper-programming focuses more on how you think and approach programming, than on your ability to brute-force the solution by trial and error. I interpret such a dependency on one’s tools as unwillingness to think and work under unfamiliar conditions, which for me means being unable to adapt to temporary difficulties and generally far from what we call a professional.

Candidate: “It doesn’t matter that I can’t solve the dumb programming exercise — I am good at real problems!”

Here it is dead simple: no, you aren’t. Not unless you can show that and the “dumb” exercises are here exactly to allow you to do that. The purpose of sample problems is to verify certain skills. that we expect our potential employee to possess, and to see what kind of mistakes they make. If a person fails at this it doesn’t mean we won’t hire them — in many cases we spot what we need even behind a failure. But if someone tries to sell us the idea that, while they can’t solve our mostly simple tasks, there are some mythic problems that they address easily, that is a sign of a phony, who speaks a lot, but does little. I don’t think that loud yet empty bragging is characteristic of a great developer, be they junior or senior, — I believe they either succeed at a task or accept the failure and use the discussion to analyze their solution and spot mistakes there.

Candidate: “I don’t remember the theory — it’s only practical considerations that are important”

It’s not that our job is about reciting some “Introduction to OOP” book to each other, but it certainly hurts when people respond this way to a question like “what polymorphism stands for?”. I expect some respect for the theory simply because it helps do our work better choosing the most suitable solutions and gives us a language to communicate with each other. Because the questions I ask are quite basic, those who fail to answer may have difficulties understanding software requirements and commit stupid mistakes. I’m pretty sure that someone who doesn’t remember the key principles of OOP or can’t explain the internals of a hash-table from the top of their mind can do good as a developer, but not when they denounce knowledge. Here, in addition to an attempt to gain my confidence by empty talk, I see reluctance to learn, which means I would have to invest a lot of time and effort into bringing the person up to the team’s pace and establishing communication with them — the time and effort that I likely won’t have.

Interviewer: “Could you please elaborate the answer and explain your reasoning?”

Candidate: “I just think that’s the correct answer”

Interviewer: “What makes you think so?”

Candidate: “I just think so”

I was very surprised when I had this dialogue for the first time, but it was real and happened to me more than once since then. Sometimes I meet people who just come across a thing that looks like an answer to the question and try to sell it to me as though that’s simply the answer that I need. As I must have repeated several times already, I am looking at the person’s reasoning and striving to understand them better — not just trying to check whether they are able to guess a number. Even though it makes me feel somewhat stupid, it’s not even the fact that this dialogue comes after I give some hints to indicate that the answer is incorrect that is most annoying. The problem is that such attitude shows that the candidate is bad at explaining their solutions and will hardly be able to contribute to a discussion of a complex problem with their ideas, not to speak of guiding other programmers and any kind of seniority. Even worse, like all the phrases above, this one is a sign of refusal to exercise one’s brans — a very unlucky feature for a developer.

As you can see, these triggers show something about the person’s approach to solving problems — not about which technologies they know or what tools they mastered. I pay that much attention to this aspect because it is relatively easy to teach a curious and thoughtful programmer a new language or a nice trick, but way more difficult and unrewarding to attempt raising a good developer from a person who doesn’t want to study and sometimes even to think.

Even though hearing any of these phrases doesn’t mean I would instantly stop the interview and refuse the candidate, they greatly impact the outcome of the interview. I have seen other managers hiring people who failed to solve an exercise or answer a couple questions and did that myself too. Still, I haven’t yet met a person who behaved in the manner described above during their interview, but gave enough reasons to hire them nevertheless.

There are a couple other ways in which a candidate can draw my attention — both in positive and negative ways. I will get back to these in future posts. In the meantime, what do you think of these triggers? Do you believe they are valid or should interviewers be more forgiving?

Interviewing Developers: triggers, part I

Written by Alex Turok