How to (Fucking) Hire Developers

This is a fairly coarse article. There’s a gentler version posted here.



This is a topic that has really gotten out of hand. There are all sorts weighing in these days — along with far too much jowl waggling by middle managers and idealist super hackers.

So let’s cut the shit and get down to business, shall we? Here’s how to fucking hire a great developer:

1. Use fucking 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 literally nobody commits to memory. You judge a person based on what they’ve done before they land in your office. Why? Because it’s not possible to compress a college education or a product launch into a 30 minute blabberfest.

"Wah! Boo-hoo. College isn’t the real world. I can’t use no book learnin’ to straighten out our VB.NET calculator optimization plant!"

You are what’s wrong with the industry. The whole point of a college education is to demonstrate the ability to learn and excel at a high level. If a candidate distinguished 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 bullshit browser plugins for $20/hour is flaming garbage. 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 and you better damn well pay attention to it.

"Hurr-durr, what if a candidate slid by? 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. Fucking pay attention to outside projects.

Who gives a shit 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 loser. 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 sweaty meatball breathing down your neck and belching a constant stream 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 measuring the length and girth of one’s coding prowess.

In fact, let’s get even more specific…

3. Get a fucking code sample.

What’s better than bullshitting 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 like “lol what was ur favorite bug???” or “hehe wut algorithms do u think r kewl?” Ooh! I know:

Asking those same questions about the candidate’s code sample while it’s actually out in front of you.

Hell, 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 me any bullshit 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 bullshit spellchecker for you in C++.

Do you ask a cleaning service to clean your home before you hire them? Do you ask your accountant to file your taxes just to see if they’re any good? Do you sleep with a love interest before going on that magical first date?

No. 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 apps using your proprietary API).

And while you’re asking me questions…

5. Don’t you fucking dare ask me a riddle.

Whoever started posing brain teasers on tech interviews deserves to be elbowed heartily in the junk. 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 libido
  • 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 goddamn 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 toddle through 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. Give a shit about my personality.

The sad, sorry truth about the hiring process is that even a super brilliant ubergeek is worth dirt if she’s a douche-nozzle (or, more delicately, “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 giving a fuck over a long period of time. Isn’t that the basis of friendship?

While you can never know for certain whether someone 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 douchey, don’t let them conduct interviews. You need friendly, kind folks who are capable of judging character — not the guy who “rapes Haskell” with his “skillz”. Dicks tend to attract dicks.

Second, invite your candidates to join you for lunch, dinner, a snack, a company outing, whatever. Do your best to abolish that dank S&M vibe to 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 dick.

Your startup sucks,
Brandon