So many times over the past decade I was that guy on the other side of the table, the one obstacle between you and your next job. I never held a management position but was always an appreciated senior technical figure, so I was often trusted with doing the technical interview. I also was present in many interviews as an observer, and saw other people interview, so I think I have a pretty solid perspective on this process.

Let me start by saying something that sounded obvious to some but at the same time surprised others: Interviewing is hard!. Think about it, you have to judge someone’s technical skill according to a one-hour chat. That’s impossible! Added the stress that usually accompany candidates in interviews, it makes interviewing a hard task.

So here I’d like to discuss how I interview. I don’t know if it’s the best advice, or the only one, but I know that I strongly believe following these guidelines makes me a better interviewer.

Don’ts

Let’s start with the things I won’t do in an interview, or I disliked seeing other interviewers do:

Give them hell

This is a very common approach for interviewers, that try to pressure and give candidates a hard time with questions. This might come as offensive interrogation style line of questions, or just noticing a doubt or a weak spot with the candidate and grill them on that.

One time an interviewer told me that first he beats the candidate to the floor by picking on their knowledge gaps, and then let them recover with easier questions.

Obviously I strongly oppose. My approach is that it is in your (the interviewer’s) best interest to bring out the best of the candidate, in order to really see “what they really worth”. An interview is stressful enough situation for the candidate which means that for most people they are at their 70% to begin with. Adding more stress and FUD only makes it worse and instead of helping you to see the candidate’s true potential, you make them deliver half their potential at best. What you should do instead is support and embrace them from the beginning, and help them build confidence so they’re at their 100%. Now you can see who they really are under the FUD mask.

“it is in your (the interviewer’s) best interest to bring out the best of the candidate”

Crazy riddles

You know how many windows there are in New York? Who cares, that’s how many. Enough with the stupid riddles, mind games, MBA quizzed and “IQ” tests. Decide what competencies you are looking for in the candidate based on the role and requirements, and look for those. If you are recruiting an analyst it might be relevant to feel their sense of perspective using a question like this, or if the riddle is just an informal way to ask a programming question, so be it. But it feels like people ask this questions to determine if “you are smart”, and that’s what I am mostly against.

Computer Science questions

This is a controversial one. If you are looking for a programmer, front-end, back-end, or whatever, chances are what you are looking for is someone with skills in the technology that your team is invested in, and some solid understanding of programming concepts. Because let’s be honest, when is the last time you had to write your own sorting algorithm?

Let’s be honest, when is the last time you had to write your own sorting algorithm?

I think we should have different expectations from those who develop products, and those who develop technologies. Those developing a technology should definitely know the theory of their trade, so the one developing the game’s engine should know physics, and the one developing the database should know data structures and complexity. But for most developers who don’t build technologies, but use them to build products, this is unnecessary.

Oh, and please leave your fancy university pride out of it. People who went to colleges can be just as good and talented, and people without higher level education as well. I hate it when good people gets screened out by HR based on their education history alone.

People are not compilers

No one writes perfect code at first run, and so doesn’t you. So don’t expect everyone to remember all the quirks and features of a language of the top of their head. That’s what compilers are for. Yes – ask about important language features and even ask to demonstrate or use them. No – don’t ask the candidate to spot a null reference exception on paper.

Do’s

Here I’d like to share what I do like doing in an interview:

Start with asking about past experience

In my opinion past experience is the most important criteria to determine one’s abilities. Never mind what you remember right now, show me what you are capable of.

Never mind what you remember right now, show me what you are capable of

You should also deep dive into a project \ product \ feature they did.

“Tell me more about XYZ you just mentioned. How was it designed, implemented, why did you choose X over Y, how did you manage this and that”

This is your place to start and challenge with follow up questions about things they did. This is OK because it’s things they did, not a question you made based on your knowledge.

This is a very important step. You might think this is too easy, asking people about things they already know and had plenty of time to think about, but you will be surprised how many candidates don’t invest in fully understanding the domain, the technology and the details of what they did. Some programmers just write code, not develop software. If someone can’t convince you of his abilities by talking about stuff they already did (and they chose to discuss) than this is a bad sign.

Ask about their strong \ favorite skills

This serves multiple purposes:

  • Boosts their confidence that you are on their side and help them be their 100%.
  • The topics they pick here can say a lot about their background, breadth of knowledge.
  • In my opinion a developer needs to love their job, and should have at least few technologies that makes them feel.
  • By picking on those topics you can challenge the candidate even deeper without being a prick, because they stated that they are good at.

There’s one caveat here – you might not know what to ask if it’s something you don’t know too well. If you are recruiting to a specific role and know what screening process they went through you usually know what to expect here. I did some interviews for architect positions, where people come with various different backgrounds and career paths, and picked topics I knew nothing about. In this case I might ask the candidate to explain or introduce the topic to me (also a good test), and try to ask cross cutting questions that apply to every technology.

What you like \ dislike about technology XYZ

This is by far my favorite question to ask. In order to develop love \ hate relationship to something you need to go through some mileage, and by answering this question you can see how much mileage was done there.

Define foo

Again, a simple question that reveals a lot. Some things we are so used to, that we forgot to think about what they are good for. “What’s the web? What’s JavaScript? What’s HTTP? What’s HTML?” – I know it sounds stupid, but it’s so refreshingly fun to talk with a web developer about what these things really are to them. Think for a moment about how you would answer each

Hands on tasks – good. Homework – better. Portfolio – best.

There’s only so much you can just talk about technology, and remember that at the end of this one hour meeting you have to determine whether or not this candidate will do a good job or not, not weather they are a good interviewees or not. So why not just see how well they are at their job.

remember that at the end of this one hour meeting you have to determine whether or not this candidate will do a good job or not, not whether they are a good interviewees or not

It’s a good idea to let them do a hands on tasks, but here are the rules:

  • If it’s a design question, then white board is your friends, but please - no white board programming. Unless it’s pseudo code or just a draft for a solution.
  • Let them choose the technology \ programming language \ tools they are comfortable with.
  • Allow unlimited use of the internet. Google, Stack Overflow are a developer’s best friends.
  • Don’t lean over their shoulder, leave them be, even leave the room.
  • Be clear about the problem, success criteria, and times.

It is common to see hands on tests during technical interviews. It might be even better to take the test offline, let them complete it at home, before the interview or after. But in my opinion the best thing to is to see something they already did. It’s the best representation of what they can really do outside the artificial boundaries of the interview.

see something they already did. It’s the best representation of what they can really do outside the artificial boundaries of the interview

A note about cheating: There is no such thing as cheating in software development. Googling the answer, copy-pasting from Stack Overflow, using something from GitHub (unless it’s what the task was about), and even calling a friend for advice are all legitimate ways to solve the problem. You know why? Because there are all also available to them in the real world. And besides, Googling is also an important skill for developers to master, and being connected to smart friends who can help will be an asset for your team. If your other developers on the team can do it, so can the candidate during the interview.

Summary

As I said, interviewing is hard. I always find it too hard to summarize a person into a few sentences in a textbox, and even harder checking that Hire\No Hire checkbox. So far I don’t regret any decision I have made about hiring, and have always managed to value people’s qualities, and flaws. I hope this will help you think about how you do interviews, and maybe also help interviewees prepare better for the process.