You are bad at giving technical interviews. Yes, you. You’re looking for the wrong skills, hiring the wrong people, and actively screwing yourself and your company. Without changing anything about your applicant pool, you can hire different people and your company will do better and you will enjoy your job more.

I realize these are bold claims. In the ten years since I became senior enough to be asked to interview people, I have conducted a great number of technical interviews, been part of a lot of teams at companies big and small, and watched the effect that different types of hires have had on those companies. I’m not claiming to be perfect at hiring — at various points, I have done nearly all of the things wrong that I’m about to tell you not to do. But here’s what I’ve learned so far.

You are looking for the wrong things

1. Don’t hire for what they already know

The primary mistake that people make when interviewing is over-valuing present skills and under-valuing future growth. Don’t hire people for what they already know; the pool of people who do exactly the thing you need them to do is much, much smaller than the pool of people who are smart enough to be good at that job.

But even worse is the way we try to determine whether people have these skills. People ask questions in interviews about obscure syntactical features of programming languages, or details of popular APIs. The famous fizzbuzz test simply asks “are you aware of the modulo operator?” If the answer is “no” then they are probably a pretty weak candidate, but it provides exactly 1 bit of data. Yet people will spend twenty minutes on it in an interview, a huge waste of limited time.

2. Don’t hire for what they can remember in an interview room

I used to ask people to write code in interviews. This is terrible. Writing code on a whiteboard is an experience so far removed from the real practice of writing code as to be no predictor. Even writing code on a computer, as part of a pair for instance, tests for the wrong ability — you are asking them to write code under time pressure, with somebody watching. Some of the best engineers I know would melt under those conditions. And if your belief is that writing code under intense time pressure is part of your job, then you should examine whether that’s a problem your company has.

Whiteboard and coding interviews also routinely ask people to re-implement some common solution or low-level data structure. This is the opposite of good engineering. A good engineer will try to maximize productivity by using libraries to solve all but the most novel problems. It’s also a poor test: how do you know if somebody is solving the problem or merely remembering somebody else’s solution? There is no value to memorizing the details of algorithms you can google in 15 seconds.

3. Don’t hire for a fancy degree

Some people are impressed by academic credentials. Having gone to a good college, or having gone to college at all, are not in my experience good predictors of ability as an engineer. Having a PhD in a relevant field is interesting but also an unreliable predictor: engineers write code and ship software; academics prove theories and write proofs of concept. Somebody smart might be able to do both but it’s by no means a given, or even very strongly correlated.

4. Don’t hire for their previous employers

People also over-value brand names on resumes. Don’t hire somebody because they worked at a hot company, or a famous one, especially not if that company is big. Variation across teams in big companies is enormous. Just because a company was successful doesn’t mean your candidate had anything to do with that. If you are familiar enough with another company’s hiring process that you can vouch for it as a good selector of qualified people, you might use that to bump them to the front of an applicant queue, but beyond that, go with what’s in front of you.

5. Don’t hire friends and family

And finally, never hire your family and if you can avoid it, don’t hire your friends either. Existing relationships create bias and implicit power structures, webs of obligation and loyalty that are at odds with what is best for your company. You will either compromise your friendship or your company, and rather than being forced to pick one or the other, just avoid the conflict entirely.

FROM OUR SPONSORS

sponsored

JOIN THE DISCUSSION

By using this service you agree not to post material that is obscene, harassing, defamatory, or
otherwise objectionable. Although Nextgov does not monitor comments posted to this site (and has
no obligation to), it reserves the right to delete, edit, or move any material that it deems to
be in violation of this rule.

Thank you for subscribing to newsletters from Nextgov.com.
We think these reports might interest you:

Data-Centric Security vs. Database-Level Security

Database-level encryption had its origins in the 1990s and early 2000s in response to very basic risks which largely revolved around the theft of servers, backup tapes and other physical-layer assets. As noted in Verizon’s 2014, Data Breach Investigations Report (DBIR)1, threats today are far more advanced and dangerous.

PIV- I And Multifactor Authentication: The Best Defense for Federal Government Contractors

This white paper explores NIST SP 800-171 and why compliance is critical to federal government contractors, especially those that work with the Department of Defense, as well as how leveraging PIV-I credentialing with multifactor authentication can be used as a defense against cyberattacks

This research study aims to understand how state and local leaders regard their agency’s innovation efforts and what they are doing to overcome the challenges they face in successfully implementing these efforts.

The U.S. healthcare industry is rapidly moving away from traditional fee-for-service models and towards value-based purchasing that reimburses physicians for quality of care in place of frequency of care.