I’ve never written code, but I just passed a Google system design interview.

README and some disclaimers

Before you read this post, I (Aline Lerner, founder of interviewing.io) wanted to introduce it properly. It’s about something that’s a little bit nuts: a non-engineer passed a Google system design interview! What??! Surely something is misrepresented here, and surely something is overblown.

Here are the facts and some key context:

• interviewing.io is an anonymous mock interview platform.
• We have hundreds of interviewers who are (or have recently been) senior, staff, and principal engineers at FAANG.
• We pay these interviewers to conduct anonymous mock interviews in the styles of their companies, and we instruct them to use at least the same bar that they would use in real life.
• We instruct our interviewers to never use proprietary questions or do anything that would jeopardize their NDAs with these companies.
• The Google interview in this post is a mock interview in the style of Google, conducted by a current or former Googler on our platform (we won’t say anything more about the interviewer to protect their identity, and we’ve also changed their voice). The interviewer didn’t have any context and thought this was a regular mock interview, and we stand behind its realism.
• To corroborate the results, we had a few independent Google interviewers evaluate the interview replay without knowing the context. Most interviewers said the question was realistic. One said that the question was too hard for an L4 candidate. Several said that the interviewer was too lenient, and one said that the candidate squeaked by in part because he made the interviewer believe he was already in process for an L5 role. One said the feedback was on point. We didn’t get consensus… but that somewhat tracks real life, where interviews are messy and outcomes are not deterministic.
• Even if the interviewer was a bit lenient, the fact that a non-engineer could pass or get close to passing a system design interview is nuts. It’s a testament to how teachable this material is, and it’s also a commentary on how these interviews are flawed and can be gamed, with enough effort. We are acutely aware of the shortcomings of the status quo and want to see a revolution in our industry as much as you do.

At the bottom of this post, you can watch the full interview and judge for yourself.

My name is Kevin. I am not and have never been a software engineer. I have never written or tested a single line of code, and I have never even worked as a PM. My tech career started in (don’t hate me!) recruiting. Then moved into career coaching and salary negotiation before I got where I am now: creating content for engineers.

With a fraction of the domain knowledge most engineers have, I passed a Google system design interview. I passed because I learned a LOT about system design interviews before taking this interview. I also learned a few tricks along the way. If these tricks helped me pass, then imagine what you’ll be able to do with them.

How a non-coder learned a LOT about system design interviews

At interviewing.io, part of my job is talking to candidates about the interview process. Many complain about system design interviews. They don’t know how to approach them or how to handle the ambiguity. Here’s what one of our users had to say:

System design interviews are very intimidating. The de facto assumption is that if you have worked for 5+ years, you should have excellent scalable systems experience and if you fail to show that at interviews, you're penalized either by not getting the offer or by getting down leveled significantly. The analogy I can think of is like asking an elephant to fly when the job description is to lift and move heavy things.

At the time, the most popular system design resources were eerily similar. None of them had good solutions for approaching, handling ambiguity in, or demystifying system design interviews. So, we decided to try to make the best system design guide in the world, and I got to lead the project.

First, I talked to some of our highest-rated system design interviewers. Then, we started work on the guide. My role was to facilitate, listen, project manage, write, edit, and repeat.

After months of work, we published A Senior Engineer’s Guide to the System Design Interview on March 2nd, 2023. It did well on Hacker News. If you Google “system design interview”, it’s the #1 result (as of when this post was published).

Why I decided to try doing a system design interview myself

After the guide was released, I met again with some of the contributors. Out of nowhere, one said, “I bet you could pass a system design interview.” The other two agreed. I accepted the challenge and decided I wouldn’t study; I’d just use what I learned from making the guide.

I scheduled a mock system design interview with an interviewer from Google on interviewing.io for a Friday morning. My interviewer wouldn’t know who I was and would only know my years of experience (I said I had 4). The only other thing my interviewer would know about me was that I presumably was about to interview at Google and needed help preparing.

How to book Google system design interviews on interviewing.io

Selected highlights from my system design interview

I’ll walk you through a few clips from the interview that cover three key aspects of my experience: an unconventional idea, something I failed spectacularly at, and a moment I’m proud of.

An unconventional idea

Last year, I went to Harvard Law School’s Advanced Negotiation Workshop. They spend a lot of time (33% of the whole workshop!) drilling into the specifics of how negotiations are often won or lost in the first and last 3 minutes. I approached the first 180 seconds of this system design interview with that in mind, and I knew I had to quickly score some social proof with the interviewer.

The unwritten codes of FAANG interviews taught me one unobvious way to score social proof. Win the competition about who cares less. I’m naturally enthusiastic so I had to trick myself. To find that devil-may-care attitude, I’d repeat a lyric from Green Day in my head: “I don’t care that you don’t care.”

Something I failed spectacularly at

Simply put, I forgot you could cache data on a user’s device. More importantly, they grilled me about caching and I took it personally. I lost sight of the interview. Caught in a story of them as an adversary, I stopped listening. I ignored their follow-up questions and, ironically, their hints.

As Marcellus Wallace said in Pulp Fiction, "Pride only hurts." I didn’t know the answers to their caching questions, and I was too proud to say “I don’t know.” Had I done that, they would’ve shifted gears. But I didn’t, so they assumed I actually did know, then the grilling continued. If I could go back in time, I’d do what our system design guide says to do when you’re not certain, but you have an idea.

Tell the interviewer:

"I don't know, I'm definitely going to look that up right after this interview, but if I had to give my best guess I'd say... [x] and here is why [explanation/thought process]."

A moment I’m proud of

Breaking Google’s record for the number of times “Harry Styles” is repeated in one interview! Just kidding. My actual proud moment was staying calm when the interviewer said something scary. A candidate who gets scared, looks like an outsider. To look like an insider, stay calm.

A common system design question is ‘Design Gmail.’ There are so many different dimensions, no one can design Gmail during an interview. That can’t happen. Whenever people ask you to ‘Design Gmail,’ that's to scare you.

-Former Staff Engineer at Google

The topic of scale came up. And the interviewer said this system should be able to support 800 million active users. That quote from that staff engineer popped into my head, so I–while feigning the most casual tone possible–responded with a neutral “okay.” The word choice and delivery suggest “this is another day at the office for me” which implies “I’m not scared of this.” In my head, what I told myself was “I don’t care that you don’t care.”

The interviewer’s feedback from the interview

At 41:00, you can hear him give me a “Weak/Lean Hire” for L4.

What I learned about system design interviews

Without a firm foundation, tricks lose their magic. You can have all the tricks in the world, but if you don’t know the material, it won’t be enough. That said, just knowing the material isn’t enough either because doing well is also about managing your own psychology. The main mental obstacle is the discomfort of not knowing.

Set yourself up for the least amount of discomfort. Book an anonymous, mock system design interview with engineers from top companies. Keep your skills sharp.

See available times

Unlike engineering problems, design problems are more about not knowing. There are no optimal solutions. Progress is not quantifiable. There are no predetermined outcomes. It’s not enough to sum them up as ambiguous; they test your ability to thrive in ambiguity. Luckily, this can be learned through practice. It is a way to think, communicate, and solve problems. So, the skills you learn are transferable, even from practices that seem unrelated.

Three ways to practice "not knowing"

They are: the "not knowing" game, improv class, and zen koans. Try one for 10 days. If your system design interview skills don’t improve, I’ll buy you a Coke. Share your experience, tell us what we should write about next, and add anything else in the Typeform at the end of this post.

First way: The "not-knowing" game

The way to play is to notice who knows stuff you don’t and then follow that thread. It’s easier with a topic you’re currently passionate about. For me, that’s art. I bring it up and listen for it everywhere. If someone mentions something I didn’t know, that’s a point. If they explain something I didn’t know, that’s double points. And if someone scores enough points: treat them like an old friend and see where it goes.

The other day, a stranger and I began talking at a café. A half hour later, we were in their house looking at their original copy of Dante’s Divine Trilogy which is about hell, purgatory, and heaven. It is hundreds of years old and surprisingly massive. Before this experience which was steeped in "not knowing"–an impromptu visit to a stranger’s house–I hadn’t even heard of this extremely rare art piece. After it, I had turned its pages (and not in a museum!!!).

Second way: Improv class

If unstructured conversation seems like hell, you might prefer an improv class such as clowning. There are two types of clowns: the high status (who “knows”) and the low status (who “doesn’t know”). Low status clowns do illogical things like jump when they’re told to sit. They are the rule breaking dopey sidekicks. When playing one, you tell yourself you have no idea what’s going on, and to be okay with that. This is similar to a meditative practice called “don’t know mind.”

Third way: Meditation

If strangers and clowns are scary, try meditation. Zen koans are a particularly baffling flavor of meditation. One is, “What is the sound of one hand clapping?” Another one is, “What is your original face, before even your parents were born?” Full of paradoxes and non-sequiturs which can’t be figured out with a normal rational everyday way of thinking, zen koans can teach you to thrive in ambiguity by yourself on an app. Shout out to all the introverts out there.

Conclusion

To do well in system design interviews, you need to do two things: first and foremost, you need to learn the material. Then, you need to practice “not knowing” to get better at handling ambiguity. With the ability to thrive in ambiguity, nothing in life is impossible. Without that ability, you might never crack that code, have that adventure, or save the world.

Watch my full system design interview below:

If you have other topics you want us to write about, or feedback on this post, please leave it here.