My Developer Interviewing Principles

As a senior developer, a part of my job is giving technical interviews to candidates for developer positions at Futurice. Developer interviewing is quite a well-discussed topic around the Internet, and over time, following these discussions and thinking what I want to see, I’ve developed something of a style. For this post, I’ve attempted to distill this style into a set of principles that I try to follow whenever I’m interviewing.

An Interview Is Not an Exam

In an interview, I am evaluating your developer knowledge. This is similar to an exam, which is also about evaluating your knowledge. But an exam is limited to a specific area of knowledge, which makes it possible to “cram” for it. An interview should cover a much wider area than an exam, and also be more interactive than a typical exam.

In fact, I think if it’s possible or necessary to cram for an interview, it’s a bad interview. My task in the interview is to determine whether the candidate has the skills that my company needs of a developer. If I give an interview that can be crammed for and “passed” without possessing the needed skills in reality, I’m making a potentially costly mistake.

This principle I followed already when I was first looking for a developer position. I never prepared for the interviews. I just went in and was myself, answering questions based on what I could think up on the spot, not giving prepared answers. And I feel like I would not want to work in a company where that method does not work.

An Interview Is Not an Interrogation

Some interviewers seem to treat the interview like an interrogation. They ask questions in a rapid-fire style, expect only short answers, and work off a specific list that they have. This is not how I like to do things. I try to get you to talk most of the time, as I feel that’s how I can get the best evaluation out of you. And I try to pick up specific points from your answers and ask follow-up questions about those, making the interview more of a discussion than a Q&A session.

That doesn’t mean I don’t have a list of prepared questions. Working off a specific list, with good ideas of what kinds of answers are expected, helps ensure that the evaluation is performed similarly for different candidates. The difference is, my questions don’t usually have simple answers, so they serve more as discussion starters, with potential for following up to whatever level you’re proficient at.

There Should Be No One Right Answer

Software development is not an exact science. And even if it was, the amount of variables is so large that even very similar problems can call for very different solutions. It is very rare that a practical question could have just one answer that is correct every time. So I prefer open-ended questions with many possible solutions to questions where I would be hunting for a very specific response.

Yes, this means I won’t be asking specifics about language syntax or libraries. I do expect a developer to have a working knowledge of these, but that knowledge is better demonstrated by writing code, not answering questions about them. When I care, say, about some library functionality, I prefer to introduce the general problem, discuss that, and see if you’re aware of the common libraries or methods to solve that problem. I won’t expect you to know the precise functions to call off the top of your head, let alone their syntax, but awareness of the functionality could be expected.

My Opinions Are Not the Only Correct Ones

Even keeping in mind the previous point, we developers do tend to pick favorites. For common problems, we have specific solutions that we tend to reach for, assuming they’re not infeasible. I acknowledge that both I and you will have these favorites, and we may have picked different ones. As long as you show familiarity with your solution, including its potential drawbacks, I won’t hold it against you if we didn’t pick the same one.

Typically, you won’t even find out my opinion on whatever I asked about. Knowing what I like can easily bias you to giving that answer even if you prefer something else. And that will tell me less about how you think. So I try to keep my questions neutral, I try to be aware of the drawbacks of any of the potential solutions and ask about how you would address them.

Sometimes I Ask Bad Questions

I don’t actually have a principle to ask bad questions occasionally… But we’re all human, and no matter what lofty principles I try to follow, I will make missteps. The important thing for me is to recognize I asked a bad question, put the blame on myself and not penalize you for not comprehending what I was going for, and learn from it for the future.

The most important thing, when I notice I asked a bad question, is to put you back at ease. Not being able to answer an interview question can easily feel like you’ve failed. So I won’t just move on. I will try to rephrase what I was asking, clarify if needed, and if it seems appropriate, admit that it wasn’t a good question. We’re not robots, and it’s good for me as an interviewer to also admit I can make mistakes.

I Don’t Care How Well You Function under Pressure

A job interview is a stressful situation. But that’s not what the work itself should be like. If you’re constantly under stress at work, there is something wrong in the environment that should be fixed. So putting you under pressure in the interview is not going to tell me anything useful about you. That means, for instance, no live coding. It wouldn’t be a typical environment for you, and I think the time can be spent better.

Keeping in mind all the points made above should also help in relieving the pressure. When I treat the interview more as a discussion, ask questions prompted by what you say, and don’t make you recall minutia, that usually contributes to making you more at ease. But I still need to observe, and try to adapt if you begin to look stressed, because not everyone is the same, and not everyone has the same pressure thresholds.

But I Do Want to See Your Code

To be hired as a developer, you should know how to code. As I said above, I don’t think making you code in the interview is going to show that usefully. But I still need to evaluate your coding ability. So that means, you need to provide some code of yours for me to see. And this should be done before the interview so that I can consider it properly.

I don’t care so much where the code is from. It can be something you’ve already done, or it can be a coding exercise specifically for the interview made on your own time. Whatever suits you best. I won’t require you to have an extensive existing open-source portfolio ready to show, and I consider the calls to require such to be a bad idea in general.

Much of the interview will be spent on looking at your code together. I will look for typical good coding practices. I will ask you to explain why you designed the code the way you did. I will ask about functionality that you might have to implement next. And I will ask about specific pieces of code where I see multiple reasonable ways to accomplish the goal.

Because of what I want to ask about, my preference is for a short, 2–3-hour, specific coding exercise. Such an exercise would be defined to require functionality that we typically encounter in real projects, and I can ask about the same questions of everyone. Also, since you wrote the code shortly before the interview, it’s likely to be clearer in your mind. But as long as the code you provide has the interesting functionality, and is written to show your skills instead of being a quick hack, it should be just fine.