How to Hire Developers
This is a SFW version of an article I wrote called “How to (#$@*&!) Hire Developers”.
This is a topic that has really gotten out of hand. There are all sorts weighing in these days — along with far too much hand waving by middle managers and idealist super hackers.
So let’s cut to the chaff, shall we? Here’s how to hire a great developer:
1. Use credentials.
I don’t know how the discussion has devolved to the point that this isn’t obvious. You’re not going to somehow probe the extent of a persons’ mental faculties by quizzing them on minutiae that virtually nobody commits to memory. You judge a person based on what they’ve done before they land in your office. It’s simply not possible to compress a college education or a product launch into a 30 minute interview.
“Sure — but college isn’t the real world. What good is a bunch of theory when I need someone practical?”
The purpose of a college education is to demonstrate the ability to learn and excel at a high level. If a candidate managed to distinguish herself in school, pay attention. For computer scientists (unlike, say, English majors) part of that training is legitimately practical: we learn how to engineer software using big-kid tools. Ask us about our projects and then decide if they’re credible.
The notion that the years we spent pounding on books and keyboards doesn’t count as much as writing slapdash browser plugins for $20/hour is simply unfair. Disregarding students’ investment as mere rigmarole is equivalent to asserting that Gandhi went on hunger strikes because he wasn’t hungry. Many of us sacrificed for our education; the least you can do is honor it.
“Fine — but what if a candidate slipped through the cracks? Or earned bad grades? Or didn’t go to college? What then?”
Respect for learning is hard to fake. Consider: past-experience; volunteering; open source; projects; hobbies. It’s not the college so much as the education. Which brings us to…
2. Pay attention to outside projects.
Who really cares if an engineer can write a binary search? Anyone who still writes code to sort a batch of integers is either (1) a student, (2) not merely sorting integers, or (3) a total amateur. How do you sort a list? You invoke sort. Next?
“But that’s a trivial question! What about sorting seventy eight petabytes of cat images on a machine with forty kibibytes of RAM and a system bus that’s only two and a half bits wide?”
Okay. That’s interesting — and we’ll get to the questions you should ask next — but there’s an easier way to cut the fat:
Spend four minutes actually checking out the candidate’s outside projects. Do they have a github? Did they write a thesis at school? Did they send you a code sample? Did they provide a recommendation from a professor?
When you ask people to write programs or solve programming riddles in front of you, you’re testing thousands of irrelevant skills at the same time. For one, there’s a huge difference between coding and coding on a dirty whiteboard in front of a manager as she breathes down your neck and weaves a frosty web of critique. For another, developers (usually) make awfully nervous thespians.
Besides, a developer will almost never encounter a similarly abusive situation in practice: code reviews and discussions are conducted by peers and friends who aren’t simultaneously computing an ultimate judgement of your person and intellect.
In fact, let’s get even more specific…
3. Get (and study!) a code sample.
What’s better than yakking in front of a whiteboard for thirty minutes? Reading through original source code that the candidate is genuinely proud of and that she deems worthy of your eminence.
And you know what’s better than tossing around open questions about favorite bugs and algorithms?
Asking those same questions about the candidate’s code sample while it’s actually out in front of you.
Heck, you can really dig into that sample — the more code the better. If there aren’t interesting questions to ask about the candidate’s specimen, well, either they’re dumb or you are.
But don’t forget: use code that we’ve had time to architect and think about. And most importantly…
4. Don’t give any homework.
I’m looking for a job. I’m busy interviewing at fifty different companies in fifty different townships. I’m trying to make ends meet and I certainly don’t have time to write a spellchecker for you in C++.
It’s not fair for you to ask someone to spend hours writing dumb programs for you and it’s certainly not fair for you to ask someone to spend hours working on your dumb programs without paying them (just because I’m a developer doesn’t mean I can’t wait to write plugins for your marketing tool).
Don’t take the easy way out: get that code sample, study it, and then ask me about it. Simple as pi.
And while you’re asking me questions…
5. Don’t you dare ask me a riddle.
Whoever started posing brain teasers on tech interviews deserves a swift elbow to the gut. Brain teasers are completely unrelated to:
- my ability to code
- my creativity
- my ability to design algorithms
- my performance as an employee
- my performance under pressure
- my intelligence
- my engineering experience
- my personality
You know who’s good at brainteasers? People who are good at brainteasers. That’s about it. The rest of us spend our time writing awesome code, learning about system architecture, and having a life instead of trying to figure out how many blind prisoners on a desert island ate green pudding last Tuesday.
Don’t waste our time…
6. Ask relevant questions.
Really want to see what color I turn when I’m forced to be insightful and creative in a strange person’s office? Fine. But at least ask me relevant questions that emphasize process over results.
As was mentioned, don’t grill me on minutae like syntactical quirks or the x86 paging model. Focus on genuinely creative questions that are interesting without requiring a stroke of genius solution.
For instance, if you’re hiring a network architect, ask your interviewee to design a hypothetical protocol for swapping cat images among a ring of anonymous, volatile nodes. Or, if you’re hiring someone who will legitimately need to design algorithms (which is much less common than it ought to be), ask him or her to walk you through the design of a lesser known algorithm and then perhaps give you some basic runtime analysis.
Most importantly, don’t get hung up on the details and do not pose questions that require a blinding flash of brilliance to solve: algorithmic plot twists are fun when you’ve got a few hours to think about them — not when you’re being grilled by someone who already knows the answer.
And please, for Pete’s sake…
7. Care about my personality.
The sad, sorry truth about the hiring process is that even a super brilliant ubergeek is worth dirt if she’s incompatible with your team.
In fact, I’d say the most — if not only — important thing to evaluate during an interview is whether a person is capable of learning quickly and whether that person is also someone you’d enjoy working with every day for the next five years.
Being smart, considerate, and (if necessary) a leader doesn’t require two decades of experience writing XSLT. These are intrinsic qualities that can only be ascertained by genuinely getting to know someone over a long period of time. Isn’t that the basis friendship?
While you can never know for certain whether a candidate is genuinely smart (… and genuinely not a jerk) there are a few things you can do to hedge your risk:
First, if any of your employees seem socially handicapped or otherwise sassy, don’t let them conduct interviews. You need friendly, kind folks who are capable of judging character — not the guy who “pwns Haskell” with his “skillz”. Fools beget fools.
Second, invite your candidates to join you for lunch, dinner, a snack, a company outing, whatever. Do your best to abolish the negative vibe so you can learn more about who your candidates really are.
That’s it.
Hiring developers doesn’t need to be dramatic and it certainly doesn’t need to be painful. Embrace the candidate’s humanity and focus instead on his or her existing street cred and his or her existing personality. If you must quiz, stay relevant — and most of all, don’t be a jerk.
Your startup sucks,
Brandon
Recent comments