The limits of trying to test people when you’re hiring

Edited excerpt from Why we don’t hire programmers based on puzzles, API quizzes, math riddles, or other parlor tricks by David Heinemeier Hansson:

I remember the first time I interviewed for a front-end programming position and got asked how to do something in JavaScript on a white board. The specifics are vague, but it’s crystal clear how stupid it made me feel and how little it had to do with the actual job.

I’ve known fabulous programmers flame out in the quizzing cage and terrible ones excel. So unless you’re specifically hiring someone to design you the next sorting algorithm, making them do so on the white board is a poor gauge of future success.

The only reliable gauge I’ve found for future programmer success is looking at real code they’ve written, talking through bigger picture issues, and, if all that is swell, trying them out for size.

(1) In other words, the problem with using tests to ascertain a candidate’s capabilities is that tests don’t replicate a real work context.
(2) Here’s an alternative approach: How to run a job interview.
(3) See also The best question to ask in a job interview: Sonya Meloff and Jamie Scarborough.

One thought on “The limits of trying to test people when you’re hiring

  1. Pingback: How to avoid unconscious bias when hiring | A Founder's Notebook

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s