And stop letting great candidates slip through the cracks
A few years ago I interviewed at Google in New York. The role was Senior Software Engineer. I failed.
Admittedly I was pretty confident in my abilities and hardly prepared. My CS knowledge was rusty, and I hadn’t used the phrase “algorithmic complexity” in over a decade. My first interviewer was incredibly terse, never smiled and seemed about as interested in the prospect of me joining the company as he did about root canal. After struggling through that first hour, I knew I was in for rough afternoon.
I’d really given it my all that day over six long hours and they’d summarily rejected me. I got a 50/50 split. Three of my interviewers gave me a yes, three no. I was never told which, but I could mostly guess. I held onto my pride by alternating between sour grapes, and the reality of how close I’d come to professional validation.
The process felt incredibly dehumanizing, and I’m not alone. The interviewers knew almost nothing of me, other than how I solved complex puzzles. They stripped me of my personality — both my vices and my virtues — and reduced me to test score. And, I came out wanting. The whole ordeal left me jaded. In an industry devoid of standards, passing a Google interview is one of the few benchmarks regularly relied upon. If this is the pinnacle of engineering interviews, and am I just not good enough?
These days, I’m in a privileged position, making hiring decisions at MongoDB. I owe it to my peers, my team and the company to ensure everyone joining our ranks is a value-add; we want to be inspired by their energy, curiosity and fresh perspective. Yet we still need some meaningful way to calibrate their abilities to the role we’re looking to fill.
And it’s in this calibration, that mistakes are often made. I’ve seen this keenly from the other side, both in my own experiences, and in those of my wife Annika.
Over the last 12 months, Annika has transitioned from sales & marketing into a programming career. She recently finished up at Grace Hopper Academy, and has been working tirelessly to score her first programming gig.
When she first told me of her intentions, I — like many of my peers — assumed that finding an entry-level job would be a walk in the park. If you are under that delusion let me tell you right now, while there is a dearth of mid-level and senior engineers, there is a huge number of talented developers bursting out of intensive bootcamps, hungry for their first job. And, the industry knows it.
Through her experience, I’ve been privy to a number of obscure interviewing strategies by companies trying to determine whether or not they want to make the investment in a fresh graduate with less than a year of training. Instead of looking at her prior experience before programming — managing teams and balancing demanding client workloads — sadly they just ask her the same tired questions. And some engineers truly believe that this kind of standardization is the best way to address inequality in tech? Look at the data, it doesn’t back it up.
Surely there is a better way.
Breaking your go-to formula
Let me ask you a question: How do you determine if a candidate passes or fails one of your interviews?
You might ask them an algorithmic puzzle, a platform specific problem, a systems design question, etc. The sorts of things we all interview on, but rarely do day-to-day. What do you use to calibrate their responses, other than your own internal prejudices about how you would solve those problems yourself?
It gives them a chance to walk out with their pride intact and actionable feedback they can apply.
Have you ever tried… being upfront at the beginning of the interview as to what you’re looking for?
Some candidates get thrown by heading down the wrong path in an interview. Perhaps the way the problem was described caused them to latch onto a specific implementation, or maybe they are just having an off day. By outlining your criteria upfront, you’re setting expectations clearly, and giving them the curtesy of how best to present themselves to your scrutiny.
As a corollary, what about following up at the end of an interview as to where the candidate excelled and where they might need improvement? In either case, it gives them a chance to walk out with their pride intact and actionable feedback they can apply.
We’ve tried both in interviews, and the responses have been very strong. With the former, candidates are aware throughout the session what we’re looking for — rather than trying to guess our expectations. And the latter, while it’s admittedly more precarious to comment on weaknesses, every candidate we’ve treated this way has said they found our immediate feedback incredibly refreshing.
So instead of walking into the room with a known problem in your mind, why not find a problem online that neither of you know and solve it together?
Have you ever tried… collaborating in the interview?
If teamwork is a big part of the job, wouldn’t you want to know how well you could work with the candidate to achieve a common goal? Pairing is a great way to share knowledge and solve problems with teamwork; but it’s not perfect for everyone. Especially when you ask the candidate to pair on a codebase familiar to you but not them.
To collaborate effectively, we need to simulate a level playing field between the interviewer and the candidate. This eliminates (some) ego from the conversation (impossible to remove it all), and focus on how well the two work together. It also gives the candidate a taste for what it might be like to work in your engineering department.
So instead of walking into the room with a known problem in your mind, why not find a problem online that neither of you know and try to solve it together? We’ve tried this once or twice, and it is more stressful for the interviewer, but it’s worth trying. Another alternative is to walk through an open source codebase together that both interviewer and candidate are familiar with, but have never read.
A good indicator of curiosity and interest is evident when you ask someone to explain their passion to you, and why they care so deeply about it.
Have you ever tried… asking the candidate to teach you something new?
One technique to determine a candidate’s depth of knowledge on a topic, is to ask them to teach it to you. After all, by teaching, we learn.
After asking them directly about their strengths, we invite them to educate us on one of these areas, and why the technology resonates so strongly with them. What about Rust makes you so interested? Why do you prefer Scala over Java 8? What does C++ 14 offer over 11? How does a neural network use geometry to classify input?
A good indicator of curiosity and interest is evident when you ask someone to explain their passion to you, and why they care so deeply about it. As an interviewer, you get an insight into something new, and their ability at conveying a complex topic to a peer.
Everything being equal, your team represent true positives. They all should pass any interview you can throw at them.
Have you ever tried… interviewing your own team?
Your team present a unique group of individuals. Everything being equal, your team represent true positives. They all should pass any interview you can throw at them.
Every month, my team at MongoDB host puzzle nights. We work through algorithmic and lateral-thinking problems together. Instead of working on our own, we’ve found it helpful to discuss the problem out loud in a room. We learn how each of us problem-solve and how invariably, some perform better some days than others.
A few of the team have even used these exact problems in interviews weeks later. It isn’t quite a level playing field, but the interviewer can still empathize with what it was like to solve the challenge themselves, and how others in their team approached it.
Critical creativity
Interviewing isn’t everybody’s favorite past-time, and I’ve been guilty of a conducting a half-hearted interview more than once in my past. Yet, the decisions we make in those rooms directly impact the culture and excellence of our companies. Short of changing jobs, it’s the best way of being exposed to new ideas, energies and innovation.
Many of us engineers have a handful of questions we love to ask. Questions that we’ve seen a bevy of answers to and trust the heuristics we’ve honed over the years to help us calibrate the strength of the candidate. Yet how often do we assert the strength of these heuristics against our actual peers? How often do we look back at candidates who failed and wonder if perhaps, in our hubris we made a mistake?
Interviewing is an icky problem because people are icky. They’re fascinating, complex and multifaceted. If we gave our interviewing techniques even an ounce of the creativity that we reserve for our regular work, perhaps we could widen the pool of talent that we welcome in. Think of how many great people, otherwise hidden, might shine through.