recommended reading

Hiring a Developer? Don’t Do These 5 Things

Olivier Le Moal/Shutterstock.com

ARCHIVES

By Laurie Voss Quartz September 2, 2014

recent posts

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.

(Image via Olivier Le Moal/Shutterstock.com)

Read more at Quartz.

JOIN THE DISCUSSION

Close [ x ] More from Nextgov
 
 

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

  • Modernizing IT for Mission Success

    Surveying Federal and Defense Leaders on Priorities and Challenges at the Tactical Edge

    Download
  • Communicating Innovation in Federal Government

    Federal Government spending on ‘obsolete technology’ continues to increase. Supporting the twin pillars of improved digital service delivery for citizens on the one hand, and the increasingly optimized and flexible working practices for federal employees on the other, are neither easy nor inexpensive tasks. This whitepaper explores how federal agencies can leverage the value of existing agency technology assets while offering IT leaders the ability to implement the kind of employee productivity, citizen service improvements and security demanded by federal oversight.

    Download
  • Effective Ransomware Response

    This whitepaper provides an overview and understanding of ransomware and how to successfully combat it.

    Download
  • Forecasting Cloud's Future

    Conversations with Federal, State, and Local Technology Leaders on Cloud-Driven Digital Transformation

    Download
  • IT Transformation Trends: Flash Storage as a Strategic IT Asset

    MIT Technology Review: Flash Storage As a Strategic IT Asset For the first time in decades, IT leaders now consider all-flash storage as a strategic IT asset. IT has become a new operating model that enables self-service with high performance, density and resiliency. It also offers the self-service agility of the public cloud combined with the security, performance, and cost-effectiveness of a private cloud. Download this MIT Technology Review paper to learn more about how all-flash storage is transforming the data center.

    Download

When you download a report, your information may be shared with the underwriters of that document.