Confession time: I was never a very good student.

Back in grade school, I was completely average. The occasional A in reading, Cs in math, but mostly Bs. I especially muddled through tests, never really comfortable with the subject matter in an environment that demands the right answer, now. With the clock ticking.

Tests all too often felt like contrived situations. If I could grade the tests I had been given in school, I’d consider them average at best! And it turns out I’m not alone in that thinking: there’s an academic term for the kind of test that makes sense to me: authentic tasks. While I often questioned the assumptions behind test questions, I couldn’t focus on delivering the answer.

I bring this up because of an experience I had this week. As some of you may know, I’ve been job hunting of late, and I was given a rare opportunity to interview with a well-known software company (who shall, of course, go un-named). After the initial talk with an HR person, I was told there would be up to five additional interviews, each with a developer, the sole purpose of which would be to pass me through programming exercises. My fitness in these tests would be the chief determinant as to whether I would be offered a job.

I honestly didn’t think much of it at the time. I’ve been programming for almost 15 years; I’ve used PHP, Javascript, Ruby and Objective-C, with several lesser-used ones thrown in. I’m self-taught, but I’ve got enough experience that I figured these tests would be pretty straight-forward.

Boy, did I have that wrong.

Into the Fire

The developer who interviewed me was incredibly kind, patient and personable. He sent me a link to a shared text editing workspace in a browser, which he described as “the worst text editor in the world”. Never knowing where a programmer’s allegiances lie, I refrained from informing him that the title is already held by Emacs.

This is where I got into trouble. My interviewer pasted in a blob of text that looked like ASCII art: groups of numbers and letters joined with pipes (vertically) and hyphens (horizontally). Each group of letters and numbers appeared to represent a node in a tree, and further investigation revealed what I was looking at as a “rope structure”. You can get way ahead of the game by reading this Wikipedia entry, which really illuminated things for me after the interview was over.

I had trouble figuring out what I was being asked to do with these ropes. My initial sense of being dumbfounded grew as I was forced to split my attention between what I was seeing and what my interviewer was explaining. I started to understand, but kept missing important instructions.

It eventually grew clear to me that he wanted me to write a method that, given an index number, would return the relevant character inside the string stored in this rope structure. As the seconds ticked by, and I kept trying to understand the problem, I grew increasingly unsure of myself. I considered a recursive function that would compare the index of each node, but that felt overly complicated. I kept abandoning the idea and listening as my interviewer repeatedly said “let’s take a step back…”

The doubt in my brain was only escalating. After 20 minutes of talking about the rope structure, and some approaches to parsing it, he eventually gave up and showed me the solution. It was a simplified version of the “index” operation given on that Wikipedia page, and it made perfect sense once I saw it.

By the time I hung up the phone, I knew that I was done with that company. Before I did though, I asked him, “is this really the only way you have to evaluate developers?” And he said they get so many applicants, this is the only way they know how.

Algorithms Make Mistakes, Too

I was feeling furious with myself, and humiliated after that call. It was a tough experience, and one that I won’t be jumping at anytime soon. But I also have to wonder at that interviewing phenomenon. Is a live programming exercise like that a worthwhile filter for developers?

Any prospective employer needs to find a way to evaluate applicants, especially if there are too many to handle. But raw knowledge of algorithms doesn’t feel like the only determinant. I only know this because I’ve made successful contributions to so many software projects, and I’ve done it without a computer science degree, or any formal training.

This interview technique is actually diametrically opposed to the way I’ve hired developers myself. Typically, I look at people who obviously have development experience, but I want to talk to them. When I do, I’m really looking for one thing: are they into this business because it’s a way to make money, or do they fucking love programming?

I only recommend hiring the latter. Because in them I recognize a kindred spirit: someone who never stops learning, who loves solving problems, who wants to create great software with their own hands. I’ve been fortunate to find terrific people that way.

Unfortunately, you can’t make that kind of choice algorithmically. Therefore, I’ll never work for a company that chooses their people by putting them into a high pressure situation like that. And for better or worse, such companies will never have people like me.

Keep on moving, friends.

Update
My friend Gord Fontenot and his co-worker Mark Adams riffed on this theme in their podcast, Build Phase, this week. I really enjoyed their take; it echoes many thoughts here, but includes a lot of great info on how ThoughtBot does applicant filtering. Really enjoyable show.