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:

  • It’s Time for the Federal Government to Embrace Wireless and Mobility

    The United States has turned a corner on the adoption of mobile phones, tablets and other smart devices, outpacing traditional desktop and laptop sales by a wide margin. This issue brief discusses the state of wireless and mobility in federal government and outlines why now is the time to embrace these technologies in government.

    Download
  • Featured Content from RSA Conference: Dissed by NIST

    Learn more about the latest draft of the U.S. National Institute of Standards and Technology guidance document on authentication and lifecycle management.

    Download
  • A New Security Architecture for Federal Networks

    Federal government networks are under constant attack, and the number of those attacks is increasing. This issue brief discusses today's threats and a new model for the future.

    Download
  • Going Agile:Revolutionizing Federal Digital Services Delivery

    Here’s one indication that times have changed: Harriet Tubman is going to be the next face of the twenty dollar bill. Another sign of change? The way in which the federal government arrived at that decision.

    Download
  • Software-Defined Networking

    So many demands are being placed on federal information technology networks, which must handle vast amounts of data, accommodate voice and video, and cope with a multitude of highly connected devices while keeping government information secure from cyber threats. This issue brief discusses the state of SDN in the federal government and the path forward.

    Download
  • The New IP: Moving Government Agencies Toward the Network of The Future

    Federal IT managers are looking to modernize legacy network infrastructures that are taxed by growing demands from mobile devices, video, vast amounts of data, and more. This issue brief discusses the federal government network landscape, as well as market, financial force drivers for network modernization.

    Download

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