Observations after another go-round of tech interviewing

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”?

"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.

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 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.

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.

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.