Whiteboard Interviews: How to Avoid Them and Improve Your Career
As I mentioned last Friday, I’ve lost track of the number of folks who have shared Michael Lynch’s piece about quitting Google with me. I suppose I should expect that, since I often rail against hiring practices that people associate with Google and similar companies.
Interestingly enough, though, I don’t have anything in particular against Google at all. Nor do I have anything against its contemporaries, all of whom I am coming to think of as Enterprise Silicon Valley, given their legacy of innovation combined with their increasing resemblance more to the IBMs and GMs of the world than the hottest new startups.
I wouldn’t agree to interview at these companies, but that doesn’t mean I don’t like them. I mean, I like Chrome and Gmail and have an Android phone — keep pluggin’ away, guys.
I’ll even go so far as to say I don’t begrudge companies using whiteboard interviews nor do I think that it’s a bad idea for them to do so, in some cases.
But I’ll come back to the nuance of that later, leaving a dangling question of my hypocrisy until I do. In the meantime, I want to share a tweet and a story of my own failure to follow up on messaging.
A Twitter Conversation about Breaking into Software
Amidst my (now often overwhelming, sorry to anyone who tweets at me and I don’t see it) mentions on Twitter, I noticed this one from a few days ago:
— Melissa McEwen (@melissamcewen) March 5, 2018
Melissa channels my take absolutely correctly.
In the part of Developer Hegemony where I explain my take on the path to, well, developer hegemony, I offer that advice.
Simply refuse to do whiteboard interviews.
Define and manage your career in such a way that you don’t need to do them.
The book covers a lot of ground, so I don’t place a ton of detailed emphasis on that point. But I think that I should have followed up with some content that did.
Zoom out and look at the conversation.
Melissa’s tweet comes in response to someone named Daniel asking about resources for breaking into the programming world. He appears to be attempting to synthesize the advice of people in that world, concluding that, no matter what, breaking in requires knowledge of “data structures [and] algos.”
I’ll leave it as a reader exercise to consider whether entry level work banging out forms-over-data web apps requires theoretical computer science experience.
Whiteboard Interviews And Their Cousins, Death, and Taxes
But look at the conversational exchange. Daniel asks about resources for dealing with these sorts of questions. Melissa says, “don’t deal with that kind of stuff,” and Daniel replies with essentially, “yeah, sure, whatever, where do I get more info about algorithms and data structures.”
I empathize with everyone involved.
The real message, writ large across all such conversations is, “yeah, I think everyone agrees that this is awful, but it’s also inevitable.” This puts whiteboard interviews and their cousins, the trivia and algorithm interviews, in the company of death and taxes.
Don’t believe me? Here, read this post. Or google whiteboard interviews in general. The industry consensus, by and large, seems to be that they’re awful, but nobody can possibly stop them. So you might as well “lean into it” and play the game.
And thus far, I’ve played the part of the hardline libertarian raving about all taxation being theft. Or maybe the singularity folks wondering if our generation isn’t finally the one that conquers death. In either case, my advice isn’t practical for a lot of the industry. (Even when it’s fun).
When Thousands Compete, All of You Lose
If you’ve missed it, I’ve lately been working on a series of posts. I call these “developer to consultant,” but they’re really about something deeper. Whether you go independent or stay salaried, they’re about differentiating yourself and starting to matter in the software development industry.
You matter when you have unique expertise. You don’t matter when you play king-of-the-hill against thousands of people with similar, generic app-dev skills.
Even when you win that game, you lose simply because you played. Doing this makes you a commodity, and it makes the market for your skills a race to the bottom on price.
In the freelance world, you feel the pain of this commodification when you compete for “need a CHEAP PHP dev” gigs on Upwork or Elance or whatever. But you feel it more subtly when you apply for gigs at Enterprise Silicon Valley outfits. You feel it in the need to compete to invest more economically worthless hours of your free time in things like “code fights:
“Dude, I’m so getting that GiganTech gig. I spent 100 uncompensated hours practicing sorting algorithms!”
“Pff, that’s nothing, I spent 100 uncompensated hours practicing sorting algorithms and 100 MORE uncompensated hours practicing O-notation!”
It’s a race to the bottom, with both participants mistaking it for a race to the top. They’ll probably write depressing blog posts when they’re done about how ‘valuable’ the experience was, for some economically value-free definition of value.
In Realpolitik Defense of Whiteboard Interviews
Let’s say I’m an Enterprise Silicon Valley outfit.
I have a business problem. Forty thousand people a day want to come work for me. It’s prestigious and we have good food and whatnot. Best and brightest, all that good stuff.
Of those forty thousand people per day, I have to hire about ten percent of them to feed the beast. Even with all of the promotion committees and hiring committees and committees of hiring committees in the world, I can’t give anyone the slightest whiff of individualized attention.
I need something. An algorithm if you will.
I need a way to pare forty thousand down to four thousand. It needs to be:
- Pretty straightforward to implement and intensely scalable, because we’re talking enterprise scale here.
- Homogeneous, so that I don’t get sued.
- Optimized to err on the side of false negatives rather than false positives.
- Legitimately exclusive.
- At least superficially plausible as indicative of future job performance.
- Legibly status-conferring for those that succeed.
Whiteboard interviews check all of these boxes (as do other “stump the chump” schemes, but I’m just referring to them all as whiteboard interviews for easy reference). In other words, whiteboard interviews are savvy policy for Enterprise Silicon Valley.
They’re bad for candidates (whether rejected or hired), and they’re bad for most companies, including ones that thoughtlessly ape Enterprise Silicon Valley. But they’re good for companies looking for high-end, undifferentiated, commodity labor en masse.
If I ran an Enterprise Silicon Valley org’s hiring arm and were a cold-blooded opportunist, this is exactly how I would hire.
What Actually Works When Interviewing?
“Why the whiteboard interviews,” you might ask.
“Why not the more effective (as proved by Google, ironically) job simulation interview?
Or why not just take people’s SAT scores or something, if you want to ‘see how they think’?”
Good questions, hypothetical-you-that’s-actually-me. To answer that, let’s look at the most effective means of predicting future job performance, as discovered in that Google research from Laszlo Bock.
- “The best predictor of how someone will perform in a job is a work sample test (29%).”
- “The second-best predictors of performance are tests of general cognitive ability (26%).”
- “Tied with general tests of cognitive ability are structured interviews (26%).” (These include standardized questions around past job performance and hypothetical future job performance)
- “Normal,” unstructured interviews. (14%)
- Checking references (7%)
- Years of experience (3%)
A few things here. First of all, nothing really works very well as an individual predictor. Job interviews, it turns out, are a wildly ineffective way to scale your operation.
But let’s put that aside and look at the fact that there’s a clear winner: simulate job performance. No whiteboards, no trivia, no cuteness to see if random programmer grunts can randomly channel Enrico Fermi in sweaty moments of pressure.
You just have people do what they’d do during the course of the job, and ask them questions about what they did in the past or what they’d hypothetically do in the future. And give them an aptitude test or something.
I Don’t Care to Belong to any Club that Will Have Me as a Member
So why don’t Enterprise Silicon Valley firms and those emulating them not do the thing that will drive the best possible hiring outcomes? Why rely on contrived structural interviews that deviate from actual job performance, making them, at best, the fourth most effective technique measured?
Well for the mindless emulators, it’s simple. GiganTech does it, so it must be a good idea. But for Gigantech, it’s more complicated.
Recall one of my requirements: “legibly status-conferring for those that succeed.” I threw emphasis in there for an important reason.
Work sample tests don’t confer legible status because everyone’s work is different. Things like SAT tests do that, but they’re not, for most of the public, superficially plausible as predictive of performance (largely because people don’t really realize how ineffective job interviews are), and also because they raise questions of unfair hiring practices.
To hit all six of the points that I mention exactly, you need to get down into the Enterprise Silicon Valley land of quizzes, whiteboards, and games of stump the chump. And it’s more important to confer legible status than it is to hire most effectively.
The race to the bottom. If the interview process stops conferring legible status, you lose irrational competition for those jobs in what is really, truly not an employer’s market. “Acing the interview” and the (relatively worthless) status it confers on you ceases to be a draw, and it gets harder to find decent commodity labor.
Groucho Marx didn’t want to belong anywhere that would have him as a member, since the appeal would then wane. So it goes with Enterprise Silicon Valley, and they know it.
Going Cold Turkey on Whiteboard Interviews
Whew, this figures to be a long post. I haven’t yet gotten to the part about avoiding these interviews. Of course, that part is simple. As I explained in my book, just don’t interview at companies that interview this way and, generally, use their interviews as a status hood ornament.
Well, it’s simple in mechanics anyway. But I meandered my way here for two reasons:
- I’m just terrible at brevity, and
- You need to start viewing this interview tactic for what it really is: market manipulation.
If you’re really going to steer clear of it, you need to find it objectionable. And, you should. It is objectionable, in the same way that companies offering you “our awesome culture” as a benefit are objectionable. They weaponize your desire for mastery, autonomy, and purpose against you.
You probably wouldn’t interview at a company that espoused political views you find objectionable. Or at one known for collateral damage and negative externalities. So just add this interview style as another deal breaker.
And don’t worry about impact on your career.
By the time you enter Enterprise Silicon Valley, you have headcounts in the six figures. “Work with only the best engineers” is an utterly absurd claim with that many people flowing through an organization. And it’s doubly so given the fact that an entire cottage industry exists to do nothing but help people “crack” the interview and uncover the secret to sneaking in when they otherwise couldn’t.
Oh, and if the interviewing company isn’t even actually an Enterprise Silicon Valley company, well, then you really don’t need that job.
Approach Your Job Search Actively
I did this at one point in my career, so I can imagine you might be guilty, too. Your “job search,” inasmuch as you do it, falls into one of two buckets.
- You passively let recruiters court you on behalf of miscellaneous companies you’ve never heard of.
- You flirt with the idea of applying to the famous Enterprise Silicon Valley companies of the world, reasoning that you’ll be set for life if you get in there since everyone will see that you’re a titan of our industry (this isn’t actually true, of course).
Well, the first practical piece of advice that I’d offer, both in terms of avoiding stupid interview processes and, just in general, is to stop working this way. Instead, make out a list of what you’d like to accomplish in your next job and what your requirements and nice to haves are.
Add “no stupid interviews” to your requirements.
And then realize that you can do a lot of research. For instance, check this out: a page dedicated entirely to cataloging companies that don’t play dumb interview games. Add those companies to your list of potential employers. Grow and whittle that list as appropriate, and make sure it’s always an active player in your career management.
Embrace Creative Constraints
Right now, I’m writing this post from an ocean-front condo in San Diego. I don’t live in San Diego. In fact, you could argue that I don’t really live anywhere anymore. That seems like a strange, even implausible arrangement.
But about 5 years ago, I had a fulltime gig as a CIO. And one day, I got tired of not being able to go to a lake cottage that we owned whenever I wanted, instead of just weekends. In fact, I got tired of not being able to go anywhere I wanted, whenever I wanted. So I decided that I would make that true of my life. I imposed a creative constraint on my own life.
Why do I tell you this story? Because a lot of people will tell you that avoiding stupid interviews is impossible. “Just get good on them because it’s inevitable.” Well, I’d venture to say that going from full time meat space job to “go wherever I want whenever I want” within a few years sounds even less probable.
But you’d be surprised at your own creativity when you declare something off the table. Just because a company has some interview process doesn’t mean that you can’t get around it if you really want to. You can find a way.
Heck, you can even find a way into an Enterprise Silicon Valley company that doesn’t involve the stock interview gauntlet. A lot of them disproportionately innovate through acquisition. So you could get yourself a job at a company you heard they were about to acquire. I thought of that as I was typing the last paragraph. Given the years of your own career planning, imagine what you can come up with.
Avoid Commodification of Your Labor
I’ve harped on this point a lot lately, but I’ll say it again. Here are examples of things you might think of as specialties that are really low value commodity labor, even when companies throw Foosball tables and free sandwiches at you.
- I’m really good at .NET.
- I have an extensive understanding of algorithms and data structures.
- If it’s anything on the server side, I can do it.
- I’m a polyglot.
Imagine strolling into a company and announcing any of them. They’ll say, “oh, right, you and every engineer here, too! Here’s a book of trivia questions to study for when one of them interviews you.”
You’re not differentiating yourself from countless, faceless thousands of other programmers companies could hire. And when you don’t differentiate yourself with some kind of actual specialty, the only way you can differentiate yourself is to work more hours than everyone else for the same price or to work the same amount of hours for a cheaper price.
All those Fooseball tables and free sandwiches at Enterprise Silicon Valley shops are designed to make you happy to do the former, and standard salary negotiation helps you do the latter.
Getting better at programming is actually not worth much economically, and, until you figure that out, you’ll find yourself angrily bemused that project managers and other miscellaneous business people are always more important than you and often better paid. “But they can’t even invert a binary tree!”
If you develop a specialty with business value, nobody will bother to interview you. They’ll just call you and offer you a contract. That’s how my life has worked for years now. No reason you can’t do this too.
Change the Narrative in Our Industry
I’ll close this lengthy post by saying something that might surprise you. I’ll ask you to please not rail against whiteboard interviews and such because they’re “not fair.” Almost nothing in the world of pyramid-shaped corporations is fair. Please don’t even rail against them because they’re not effective. Again, almost nothing int the world of pyramid-shaped corporations is effective, either.
“It’s not fair” or “I have 50 Github repos, so I shouldn’t have to do this” misses the point.
The problem with whiteboard interviews is that participation in them is generally bad for your career. It causes you to to work hard for your own devaluation and commodification. So the standard explanation to offer is that you don’t think working in a bureaucratic app dev farm is in your best interests. You want to go somewhere to participate in the business, rather than to be a generic laborer.
I’ve entirely avoided any collectivist talk in the post, because exhorting individuals to chip in and do their part to create a movement really isn’t my style. On this blog, I tend to offer advice that’s good for you, rather than for humanity as a whole or whatever. And that is the context in which I offer you this post as well.
But industry-wide change happens one narrative at a time. I would like to see a future in which software developers run the business of software development, rather than wasting our time on idiotic “code battles,” sites fighting for the title of “best bang for your buck resource for a project manager to plug in somewhere.” And if enough of you reading tell enough your contemporaries that you’re done playing games instead of running our industry, we may just start to change broader narrative.
And, by the way…
By the way, if you liked this post and you're new here, check out this page as a good place to start for more content that you might enjoy. You can also sign up for my mailing list below to check out a free set of chapters from my book.
Want more content like this?
Sign up for my mailing list, and get about 10 posts' worth of content, excerpted from my latest book as a PDF. (Don't worry about signing up again -- the list is smart enough to keep each email only once.)