Observations after another go-round of tech interviewing

Hey! Thanks for reading! Just a reminder that I wrote this some years ago, and may have much more complicated feelings about this topic than I did when I wrote it. Happy to elaborate, feel free to reach out to me! 😄

Ha! So I'm leaving Reonomy. Not what I thought I'd write after the way that last post ended. But we muster the most hope when it's most desperately needed, and I was needing it then.

This means, hopefully for the last time, I went through the famed Tech Interview Experience again. Here are some findings and reactions; most of this is old hat for anyone with the ear to the ground, but hopefully someone finds this interesting.

"Hopefully for the last time"?

There's a great passage in a favorite essay "Don't Call Yourself A Programmer, And Other Career Advice":

"Read ad. Send in resume. Go to job interview. Receive offer.” is the exception, not the typical case, for getting employment: Most jobs are never available publicly, just like most worthwhile candidates are not available publicly (see here). Information about the position travels at approximately the speed of beer, sometimes lubricated by email. The decisionmaker at a company knows he needs someone. He tells his friends and business contacts. One of them knows someone — family, a roommate from college, someone they met at a conference, an ex-colleague, whatever. Introductions are made, a meeting happens, and they achieve agreement in principle on the job offer. Then the resume/HR department/formal offer dance comes about.

Perusing my public code, I've written C code to build an obscure data structure in a custom binary protocol, Erlang code to read it and subsequently play Scrabble with it, and a terminal client in Ruby that wraps ncurses to interface with it. I've written Go code to do OAuth on the Twitter API without a library. Most of that was done ~3-5 years ago, more recently I wrote a web app in Erlang.

And while I try to be humble, if I'm being honest it's hard to come out of the last two startups I've had and feel anything other than that I was one of the most effective and impactful engineers there. I wrote the API backend that powered two products, and for the previous gig I wrote 2.5 Android apps, each in about 4-5 weeks (1, 2, 3).

So while I understand employers need to protect themselves and too many applicants can't program anything, it still feels pretty demeaning to have to log into CoderPad and have someone ask me to write a function to flatten a list while they watch, then get rejected because I had shaky fingers hiding from a current employer at a Starbucks, or because I burned 15 minutes because that was when I got bitten that Ruby puts does something different when you feed it an array or somesuch.

So a personal goal of mine: for gigs after this one, either start my own company, or have built a network (and subsequently leverage it) to keep these shenanigans to a minimum, because they are shenanigans.

Observations

There is an extremely high correlation to anyone who looked up my work before an interview and getting an offer. Anytime someone indicates to me that they read a blog post of mine and/or clicked any of the above links into my work, they almost always extend an offer.

Similarly, there's never been a time when I was allowed to describe ScrabbleCheat and not be offered a job after that. That 6 year-old project was a hell of an investment.

(the above two means that I get a little sad and frustrated when a company I have interest in send me people who don't look into my work or let me show them myself, since the probability of getting an offer after that dips to lower levels).

The most dangerous part (maybe generally, but I can say definitively for me) is the phone screen. By virtue of being on the phone, neither side is able to make themselves too human to the other. My biggest issue with this is that I think phone screens are misapplied: companies try to make them full-blown programming tests rather than, well, simple screens to weed out non-programmers. You're almost always asked to write an extremely artificial problem (usually some standard library function like flatten or an LRU cache) or something with a minor trick in it (interval coalescing in an array of arrays) in some shared coding environment. The candidate has to "think out loud" while they do it, and the interviewer watches them, often bored for most of it.

My favorite treatment of this is the approach Steve Yegge outlined years ago: be specific about a few areas you want to test, then test for a complete vacuum there, everything else is a pass. In his example:

• Can the candidate write syntactically valid code? FizzBuzz is just fine here, or even "write a function that returns the highest number in an array."

• Can the candidate speak intelligently about Object-Oriented Design? Naturally this may not apply to your firm if you're a Haskell shop or something, but then look for other "building blocks," like function composition.

• Does this candidate know the basics of most data structures? Trees, lists, vectors, hashes…

• Does the candidate know about regexes, scripts, and command-line tools?

He adds a section on binary, I think that matters less for most application programmers: other domains will want to check for that.

In short: your main duty is to ensure that you're not sending up a one-trick pony, a cultural wasteland, or someone who can only talk about code at extremely high levels but can't really produce it. After you've established that the person knows enough to write code in a more comfortable environment, check more rigorously for the strength you're looking for during onsites.

Smarter people than me on this topic

• Cate Huston's How I Interview is pretty fabulous, as is her Things You Don't Learn In Technical Interviews. She also wrote this essay for Model View Culture. She's one of my favorite people to blog on tech and the industry, and hiring is no exception.

• I think diversity matters. Most Engineering teams are terrible at it. Carlos Bueno has written wonderfully about it on Inside the Mirrortocracy and Refactoring the Mirrortocracy.

• Ann Harter wrote and expanded on a fabulous series of tweets on how to engineer a tech interview using SCIENCE. Most processes are cargo-culted from what Big Companies do or what we ourselves have been subjected to, without much critical examination; it's especially jarring when tiny startups that build boring apps insist! you hire someone who can write code fit for a space shuttle.
  
  Pssst… past a certain point, the writing of your code is probably not what the success of your business hinges on.

• Peter Seibel, likely inspired by the above bullet point, published a Gist of what he wants in a candidate. If you're looking to hire: on which do you agree? Is your process hitting some/any of those points? How?

• An excellent treatment of mistakes made during phone screens by Jocelyn Goldfein is here.

• I find a lot to like in Dan Luu's Developer hiring and the market for lemons and We only hire the best means we only hire the trendiest.

So… what's next, Pablo?

Why, ClassPass! Thanks for asking, imaginary Pablo!