The technical coding experience I think is an import filter for identifying someones coding chops that can’t be replaced. I usually get really positive feedback from how I conduct interviews for software engineers. Here are my thoughts on the subject.

Why I like coding interviews

I used to think coding interviews were silly, and that technical discussion could replace that step in the interview process. But, after I had been on the other side of the table, I found that not only were there poor candidates out there, but there were some candidates who had very strong soft skills that masked their technical ability. This is dangerous for the hiring organization.

Thinking about the cost of the hiring process, the technical interview is the most expensive step, since you’re taking high paid engineers and assigning them a 1 hour interview, (plus summary and review time). What I’ve found is soft skills are front loaded, which means candidates who are actively interviewing are going to get more practice with those skills. Relying on technical discussion interviews isn’t enough to identify strong technical skills.

Be Friendly and Compassionate

Technical interview suck, they feel very binary and transactional, but they don’t have to be! When I’ve interviewed as a candidate, I’ve found situations where the proctor was very dull, showing no personality or signs of compassion or friendliness, that sucks! Maybe this is a sign to the candidate of what the culture is like at that company! Either way, I try to show up with a smile and be friendly, explain the process and generally try to make it a good time.

Use domain specific examples

I try to frame the problem as close to a real world example as possible, if possible. When working at an Asset Discovery company, we framed the technical problem in the domain of that, network scanning. The actual problem was more general than that but the data you worked with and the deliverables were all very realistic and in the realm of the domain.

But, be careful with this, in highly specific domains this may work against the interviewer. In the example above, we were a technical company and so there was close correlation to domain expertise and day-to-day understanding from software engineers.

Explicitly be a resource

I try to act as a fellow engineering and sherpa during the exercise, and less of a proctor. I say this explicitly at the beginning of the interview. “We are on your team as fellow engineers / product managers”. I want them to use us a resource and ask questions. We might know the API you want to use (but googling it is OK too!).

Flex opportunities

Ensure the technical interview has a challenging enough component to allow the candidate to flex their skills.

One problem we had when designing the technical interview is that it was more of a checklist, did they get the basic stuff done, we’re they able to talk through the problem and come up with a solution. Unfortunately, we didn’t provide a way for candidates flex or to stick out from each other. Maybe it wasn’t challenging enough, but there’s probably a way to build a problem so that a really good candidate can really show their ability. \shower-thought

“The [golf] professionals forget that the whole idea of a Pete Dye golf course is to require players to hit a wide variety of shots,” Dye said. “I’ve always felt that a good player who’s playing well wants to play a difficult golf course because he knows the winner won’t be someone who can just out-putt him.”

– Pete Dye

Pete Dye was maybe the best golf course designer ever. I thought this quote captured the need for a flex opportunity pretty well.