How to interview tech people (especially programmers)


We believe that a critical factor in project success is the quality and approach of the people working on it. In programming, this applies tenfold and your team’s quality can make or break the project. An interview is a great opportunity to find out if a candidate will be an asset and it’s crucial to gather as much information from it as possible.


The best way to uncover details regarding a candidate’s attributes and abilities is to let them talk. Letting them talk about their interests is particularly effective as they will naturally wish to speak more. Logically then, our interview questions are almost always open-ended. There is no particular correct answer. Instead, we expect to strike up a conversation with the candidate.

Some examples of questions we tend to use:

  • Tell us about your last project at work. What did you like most about it? What do you think about the architecture? How was the project managed?
  • If the candidate lacks previous job experience, you can ask about their graduation thesis, or any projects they did in their spare time.
  • Compare any two programming languages you have experience with. Which one do you like more? Why?
  • Pick a feature you like from your favourite programming language/framework/library and tell us what’s so great about it.
    Alternatively, you can ask a candidate to tell you what’s not-so-great about a feature they dislike. This will show you if they can criticise things constructively.

What’s important here is the way the candidate explains things to you. Since the questions are open-ended and it’s up to the candidate to pick a particular topic or technology, it’s likely they will start mentioning things you have limited or no experience with. Can they explain these to you clearly and understandably? Are their explanations simple and to the point? If yes, that’s certainly a good sign. In work and especially in a tech world, you will frequently find yourself in situations where you’ll need to explain things to people.

Does the candidate get at least a little excited when talking such topics? Even the shyest person will, when talking about something they are deeply interested in, momentarily forget their nervousness. Don’t be afraid to go into more detail and ask “why?” more than once.

How did the candidate solve problems they encountered? Were they passive and went with the flow, or did they actively contribute to solving the problem? Look for specific examples of either and don’t get misled by vague answers. Again, don’t be afraid to dig into their examples to ensure you are getting the specifics you need to know how the candidate really performed in those situations.

Are they an expert in any technology or domain? If so, it’s very likely they will be able to learn some other technology or framework as well, which is an excellent skill to have.


These are, of course, necessary. We never hire candidates without them writing at least some code. With technical questions, we focus on everything mentioned previously i.e. we are not expecting a perfect answer to a quiz-like question. Instead, we are interested in watching how a candidate tackles an open-ended question, which questions they ask for clarification and their thought process.

As a good warm-up exercise, we usually start with a FizzBuzz-styled question. Any at least semi-competent candidate should solve this question in a matter of minutes. It should be a warning sign if the candidate struggles with the question or considers it too simple to even bother with.

You can continue with other questions aimed at gradually testing a candidate’s technical knowledge. The exact questions to ask depend on the technology stack of the job position in question, but to provide an example, here is a multi-layered question we usually ask when interviewing for a C#-related position:

The question begins rather simply: we ask a candidate to write a method to reverse a string. If the candidate simply uses something like Enumerable.Reverse, you can follow up with questions about C# extension methods and related topics like LINQ.
Moving on, the candidate then has to write a method to reverse the order of words in a sentence. At this point, the best candidates will realize that the method written previously (to reverse a simple string) can be reused. If not, we nudge them towards this and watch how they approach the problem. The discussion can then continue with polymorphism or generics.

Again, it’s not that important which exact questions you use. What certainly is important is how the candidate reacts – do they ask questions of their own to clarify what was asked of them? Are they able to improvise, or listen to your hints and come up with a solution? If so, you will probably not make a mistake hiring them.


So, the interview has concluded and now it’s decision time. Here, we totally agree with Joel’s Spolsky’s excellent interview guide – if you are in doubt whether to hire someone, the correct answer is simply no. You shouldn’t have any doubts about your decision to hire someone. Aside from Joel’s blog, we also recommend these excellent interview tips from industry veterans.

What is your experience with interviewing for tech positions? Is there something you’d like to add?