-> Anonymous <-
-> October 2015 <-
I'm publishing this anonymously because I have conflicts of interest, and because I think I can serve my purpose without revealing my identity. I'm not going to go to great pains to conceal myself. If you really want to figure out who I am you probably can. I just feel the need to provide myself with plausible deniability. And if you do figure out who I am I would appreciate it if you would respect my desire for anonymity.
I'm a software engineer with an advanced degree and several decades of experience. I am financially independent, but I still work because I enjoy it and because you can never have too much money. At the moment I'm working on a startup, but in the past five years I've applied for four jobs. In two cases I didn't make it past the phone screen, and in the other two I was rejected after a full day-long technical interview.
I also recently completed an interview with the new YC startup Triplebyte (https://triplebyte.com). The contrast between that experience and the four previous ones was so dramatic that I wanted to write about it. In the interests of full disclosure: my relationship with Triplebyte has not yet led to an offer, and in fact since I applied my situation has changed so that I am no longer available. But this situation could change yet again, so my Triplebyte experience could some day still lead to a job offer, and that's a conflict of interest. That's one of the reasons I'm publishing this anonymously.
The TL;DR version is this: the traditional technical interview process is designed to ferret out a candidate's weaknesses whereas the Triplebyte process is designed to find a candidate's strengths. This seems like the Right Thing to me, because in today's world there is no sport in finding someone's weaknesses. No one can possibly master all of the arcana of today's technology landscape, let alone bring that mastery to bear on a problem under pressure and with no tools other than a whiteboard. Under those circumstances, you can make anyone look like an idiot.
The fundamental problem with the traditional technical interview process is that it is based on a chain of inference that seems reasonable but is in fact deeply flawed. That chain goes something like this:
-
Writing code is hard.
-
Because writing code is hard, only smart people can do it.
-
Therefore we want to hire smart people.
-
The best way to find smart people is to design a process that filters out dumb people.
-
The best way to filter out dumb people is to ask them hard questions that we know the answer to and see if they also know (or can figure out) the answer. (Because we, of course, are not dumb.)
Hence phone screens, whiteboard coding, puzzles... And then we are surprised when it turns out that these make terrible predictors of the actual ability to code. Why are they terrible? Because smartness is not a scalar, it is a very-high-dimensional vector, and the basis vector for puzzle-solving-ability is pointing in a very different direction than the coding-ability basis vector.
Coding in today's world and puzzle-solving are just two very, very different skills. No one codes ab initio any more, so coding has more to do with the ability to look things up, read other people's code and documentation, and use tools effectively than the ability to solve problems closed-book. But the dumb-person filter explicitly does not test for the ability to look things up, because of course anyone can look things up, even dumb people.
Worse, what the traditional process really selects for is a willingness to put up with bullshit and an ability to game the system. There is also a significant component of pure luck involved. If you get asked a question that you just happen to know the answer to, you're golden. If you get stuck in a situation where you have to work something out on the fly, you can easily get stuck in a mental wedgie that makes you look like a complete moron.
As someone who occasionally hires coders there is only one thing I care about: can they write -- and debug -- code? Debugging is almost as important a skill as writing the code in the first place, maybe more so. But the traditional process is absolutely horrible at predicting debugging ability, and with good reason: debugging real code means running the code and looking to see what it actually does. That is not possible on a whiteboard. On a whiteboard, you have to mentally compile and "run" the code in your head to see if it works. That is not what coders need to be good at. Running code is what computers are for. We invented them specifically so we wouldn't have to do that sort of work in our heads any more.
All of which makes the Triplebyte process a breath of fresh air. The first step is an on-line quiz, but it's a relevant one: you are shown little snippets of code and asked to find the bugs (or say if there are no bugs). It's multiple-choice, but timed, so it actually has a reasonable chance of predicting an ability that we ought to be caring about.
The second step is a more traditional technical interview, but it is conducted on-line using Google hangouts. You're still writing code, but you're not doing it on a whiteboard, you're doing it on your own machine using your own environment, i.e. under realistic test conditions. Not just realistic, but ideal conditions. You can have everything set up the way you want it. Your performance under those circumstances is a much more plausible predictor of real-world performance. If you can't do well on your own machine, the odds that you'll do well on the job are probably pretty low.
Even better, Triplebyte offers two options for the on-line interview. The first is a traditional format where you are given problems and write code on the spot. The second is a project that you work on off-line for a couple of days before the interview. I chose that option, because I tend to get brain wedgies when someone is looking over my shoulder.
It was an awesome experience. For pretty much the first time in my entire career I was able to show a prospective employer what I could really do when the fetters are removed. I actually ended up writing a working, usable piece of code. (I may end up publishing it so I'm not going to tell you what it was. It doesn't really matter anyway.) I learned some new things. It was fun. How many times do you get to say that about a technical interview?
So I recommend Triplebyte, both as an applicant and a prospective employer. I think they could be the future of technical interviewing. I certainly hope so.
Great writeup. For the phone screen on Google Hangouts, did they have you type the code in a shared document, or were you screen sharing your IDE?