• 10-October-2021

How to Interview Programmers

“I don’t know why but I like this candidate, my gut tells me he/she is going to be great” — the wrong way to hire people

In his recent book Talking to Strangers, Malcolm Gladwell notes the science behind “gut feel” and how it is usually wrong. Judges in the legal system, whose job is to “judge” a person’s character think they have experience and a sense for reading a person by their looks or vocal tone but are proven to usually be wrong. A more systematic process is needed. Let’s walk thru some of the popular methods and analyze them.

The Coding Test

Photo by Christian Erfurt on Unsplash

This is probably the most divisive method out there — do you give programmers a test and how? In some ways it is insulting and denigrating, but most experienced managers can you tell you how shockingly easy it is to be faked out if you don’t do a basic test.

There are 3 popular ways to do this.

Live whiteboard test

Present a problem and let the candidate ease their way thru. Add some complexity to see how they adapt, ask them about corner cases and performance. All tricky problems seem obvious once solved thus don’t be tricky — pick something easy to understand.

• Pro: A good programmer should be excited to punch up some code
• Con: The best programmer I knew would choke up and panic at these

Online timed test (Hackerrank, etc)

Some people work better without an interviewer breathing down their neck (who doesn’t?). Offline tests like Hackerrank aren’t a bad approach. The caveat/downside is that people can cheat (looking up answers on Google or calling for help — heck who wouldn’t for a top $$ job ?)

• Pro: Doesn’t take up your teams’ time interviewing
• Con: Easy to cheat — which I suspect happens quite often

Offline HW (project)

I’ve been given these a few times — a design coding problem where they give you a project to deliver in a week or two. These can take hours to days to complete. It can be a little bit excessive if you are not paying top dollar, offering a dream job, or are desperate.

• Pro: Give candidates a chance to really prove themself (ie, good for borderline candidates)
• Con: Will scare or turn off the majority of candidates

Advice on Coding Tests

If coding is important then go with a live test but make it a positive experience and start simple, knowing it is not a typical way people really code. Also be aware many people practice dozens to hundreds of LeetCode and HackerRank in prep — ie, the unique/tricky problem you present may be something they already know quite well.

Design Case Study

Photo by Kaleidico on Unsplash

A pretty common step in the process is the system design interview. Many candidates prepare for this via the famous “Grokking the System Interview” guide or other online materials (and yes you should study these if you are an interviewer).

The idea is to present a basic system you need to build and walk thru how to design it. Common cases ask you to design a clone of Twitter, DropBox, Uber and other popular services.

What you are looking for:

• Ability to explain a design and its tradeoffs
• Understanding of modern technologies and where they fit in
• A good sense of scale and feel for what works and what doesn’t
• Non-cocky good attitude while explaining and defending their choices

I think this is a great way to figure out if the candidate’s ability to independently think thru solutions. You should expect really strong intuition and problem-solving ability from senior candidates and a sharp eye for how things work/don’t work from all candidates. This is so important, many firms do 2 rounds of design.