Sign up FAST! Login

What We've Learned About Interviewing


Stashed in: Hiring, Culture, Jobs

To save this post, select a stash from drop-down menu or type in a new one:

There is no one brilliant solution to the interviewing problem.

Deciding if someone should spend 40+ hours a week with you for the next several years is a very hard question to answer based on a couple hours of contact. The one tried-and-true method we have is the interview.

Interviewing is based more on tradition and "doing what the guy who interviewed you did," than hard science. With rare exception, it's impossible to tell if you are hiring the best candidates, or missing some of the best. Each company has their own formula, and even the worst systems (looking at you 90s era Microsoft) are allowed to persist for decades.

There is no one brilliant solution to the interviewing problem. Evaluating the developers you have hired is an unsolved problem, much less trying to evaluate everyone you don't hire. It's best to avoid the "clever" solutions and stick with a simple formula.

More and more, the brainteaser method of interviewing is looking like a flop.  Stick to the basics and try to determine which important concepts the interviewee is already familiar with.  

"He knows X,Y & Z which usually correlate to successful devs, but has some holes with..."

Then figure out if they are a culture fit or not.  

Culture fit seems more important than skills fit as long as the person can learn.

I personally try to evaluate people for personality fit and culture fit almost to the exclusion of evaluating or proving their technical skills. For the most part I trust what people put in their resumes. If they're a bullshitter, you can usually tell that by talking to them. And if they're good liars and are lying about their skills they will be in trouble once they're expected to actually perform.

Brainteasers are retarded. I went to an interview a few days ago where they gave me some riddle about 4 guys crossing a bridge in pairs with a flashlight, and then a question about efficiently searching a binary tree or some shit. Neither question correlated with what the job entailed in any meaningful way, but instead are meant to show "how you think." I prefer to just invite the candidate to have a beer with the team, and perhaps ask them to do a small coding exercise afterwards, both as a test of their interest in the company and, secondarily, as a RELEVANT test of their skills.

You May Also Like: