A more useful hiring metric

I’ve taken part in a lot of interviews. A lot.  I’ve conducted a lot of phone interviews, and read even more resumes. I’ve also had my share of weird interviews. If reading my old blogs posts on the subject tells me anything, it’s that even after doing it for years, I still have no idea what I’m doing.  I know, I should be an expert; but every time I think I’ve got this whole thing figured out, I realize: I don’t.

I’m not sure any of us do.  That isn’t to say that we’re incompetent (far from it) just that interviews aren’t a solved science; they aren’t something where you can change one variable to test what works and what doesn’t.  Every person you interview, every situation you sit in will be so different that it’s hard to draw any meaningful conclusions based on objective metrics.

As an example:

I took part in an interview once where there was this code exercise that was given to me. Originally it was to be given at 8pm at night, and I’d have an hour to do it.  This was after I’d already spent 10 hours working (I took a break, as I always do, to have dinner with my family and put my daughters to bath and bed).  If you’re wondering about the math, I had started working at 7am that morning.  By the time the code test started; it was 8:40pm (already 40 minutes late due to interviewer error) and I was tired.  Since I believe in the 8 hour burn, I should have pulled the rip cord; but I didn’t.

The purpose of the code exercise was to see how well I code.  Here’s the actual text of the exercise (anonymized):

Create a form using bootstrap that has 2 controls: date input & submit button (see video and screenshots below) . Click Submit button should calculate:
1. User’s age based on the selected date (long form date)
2. User’s next birthday (long form date)

Use the following libraries:

My success was determined not by how well I code; but by how well I implement a specific library’s control, with a specific library’s validation; in an hour, after having already spent 10 hours working. My success hinged as much on the documentation available for that library as it did on my own programming prowess. Also:  I can spend an hour mucking with CSS to get it to vertically align something correctly. As you can tell, I failed; but it left me with a realization: interviews reveal as much about the state of the company you’re interviewing at as they reveal whatever the interviewer wants to know about you.  Not necessarily what they vocalize, but what they actually want to know.

These types of interviews make me wonder: Is this what programming is about? Being able to implement a control you’ve never seen in a very specific way with a specific design in an hour? Is this what we’re hiring for as an industry? If so, what’s wrong with us?

On a practical level, I have never been in a situation where if I didn’t implement a new feature in an hour, we’d lose a client.  I have been in situations where I had to quickly fix complex problems in an hour (usually less time than that), but I had a lot of domain knowledge already. I knew the systems involved and could figure out what part to look at.

The more I think about it, the more I think our priorities as an industry are inverted. The evidence seems to bear this out.

We want to see how quickly someone can do something; or how many years of experience they have in a technology.

But does that really matter? Does it matter whether it takes me 1 hour or 2 to implement that control? Does it matter whether I have 3 or 5 years of experience in a framework? I don’t think so, and neither do a lot of other people.

What matters to me is something near and dear to my heart: What mistakes have you made with language/platform x?  With the technologies I’m not a beginner in, I can list out my mistakes all day long. I could tell you multiple stories about how I broke production because of something stupid I did.

It’s embarrassing; but without those mistakes, I wouldn’t know half of what I’ve learned.  It’s even more embarrassing telling someone else (hello internet!) about my mistakes; but ultimately, those mistakes are how we learn.  If someone doesn’t make mistakes, they’re either really really really awesome, or they’re not doing anything.  The latter is far more likely.

I used to think those mistakes meant I was a bad programmer.  I don’t any more.  Now, I take them for what they are: growth.  There’s a (perhaps apocryphal) story being shared on twitter right now along those same lines:


That story gives me hope. Maybe with the social web stories like this will infect the leadership in business, and change what we look for in an industry.  But for my part; whenever I have the power to do so, I want to work with individuals that are ok with making mistakes; of knowing that they don’t know the answer; but working to figure it out.  I want to work with someone not because they have x years of experience, but because they have made mistakes and learned from them. To me, that seems a far better indicator of someone’s value.

Leave a Reply