Effective earlier this month, I’ve decided to start rejecting requests for whiteboard coding not actually related to my job. I think you should too, and here’s why:
I think we’ve all faced it. The request to code up and optimize an algorithm on a whiteboard. While these can be fun and once in a while lead to interesting discussions with the interviewer, unless you are an engineer being hired to work on algorithmic work, this is a waste of time.
Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.
— Max Howell (@mxcl) June 10, 2015
I’ll explain why in my experience with Google. Time and again I’d get offered a great role there… and then get interviewed for some completely different role. No matter how dead on my skills are for the job, my technical interview is variably with someone from a totally different team that knows nothing about my job. So they interview me about theirs.
After getting through a few of these interviews at other jobs, I’ve realized that it’s more than annoying–it’s actively harmful to your team. Yes, I said actively harmful. Here’s why:
- Good at simple algorithms does not mean having the skills relevant for the role.
- You’re missing out on time to interview the candidate on real needs.
If you put both of these together, you have two scenarios:
- You have difficulty hiring people with experience appropriate for the job.
- You will hire people who have the wrong experience for the job.
I’m going to put this straight on it’s nose as relates to my own DevOps / SRE roles. Most of the time we don’t want someone who will try to go code up a new data structure algorithm for a small infrastructure management task. When you are managing infrastructure at scale, having a bunch of individual hand-crafted one-off automation implementations isn’t ideal–it’s your worst nightmare. You should be interviewing for someone who:
- Can identify and classify risks around any given implementation
- Knows existing tools and libraries applicable to a given need
- Is aware of and can recommend best practices related to a given scenario
To make it clear, what you want is an automation engineer who can reuse and adapt existing tooling to create as many hand-crafted, one-off instances as necessary without creating a new set of tools for each one.
Yes, the ability to create new tools when the existing tools are insufficient is important. But I’d rather hire someone who understands the ongoing cost and investment of doing that, and can weigh the costs and benefits.