What Leetcode doesn't teach you (from a Google interviewer with 10 YOE)
I'm an L5 Google SWE in the US who has conducted over 200 technical interviews, and I just wanted to share a couple of high-level insights. Sorry for the clickbaity title, but there are some skills that are really important for actual job interviews with Google that you won't learn if all you do is Leetcode.
I am by no means saying Leetcode isn't useful prep. But you do have to keep the differences between Leetcode and real interviews in mind. So here are the three big ones.
- There is a real interviewer who you have to explain yourself to.
This might be obvious, but it's an important point. I see a lot of candidates who seem decently strong, but can't verbally explain their thought process or their reasons for the data structures and algorithms they're using.
That's a problem for two big reasons. First, a human interviewer is grading you on how you solve problems, not the number of test cases you clear or the exact wall time your solution takes to run.
And second, the interviewer doesn't want you to spin your wheels, wasting time. If you start to go down the wrong path, the interviewer will nudge you back in the right direction. This isn't out of kindness - they have a limited amount of time to assess your skills, and watching you go down the wrong path doesn't provide very much signal. And how well you respond to hints is a signal in itself.
- The question may be underspecified.
You can't interact with a Leetcode problem. All the info you need, including all the constraints on the inputs, must be there in the question description. Otherwise, you wouldn't be able to solve it.
That's not always true in a Google interview! You might be given a problem that leaves things out on purpose. In cases like that, you'll need to ask questions. Even if the problem the interviewer gives you doesn't have any missing information, it doesn't hurt to ask questions to clarify your assumptions and understanding of the problem.
I have asked questions in the past that are designed to catch people who make assumptions without checking them. I might give an example input with an array of single-digit numbers, but I never said the inputs had to be less than 10, for example.
- There's no IDE.
This depends on the company where you're interviewing, but at Google, you're doing all your interviews in what is basically a Google doc. There's syntax highlighting, but that's it.
That means you can't run your code to check if it works. You have to find and fix your own bugs before you tell the interviewer you're done!
Failure to do this is hands-down the single biggest mistake I see candidates make. My advice is to "run" your code by hand on a (small) test input or two. Don't fudge it. Re-read every line of code as you encounter it, and pretend you're seeing it for the first time as you follow the instructions.
I used to ask a question about finding friends-of-friends for users in a social network. And the most common mistake people made on that question was forgetting that, technically, every user is their own friend's friend. Almost everyone overlooked that at first, but candidates who stepped through their code properly noticed the bug right away. They'd fix it without needing any help. Other candidates would just… assume their code knew better than to include the user as their own friend-of-a-friend, because *they* knew that. That's why you really have to be careful about this!
Anyway, I hope this is helpful to somebody. I'm writing from a Google perspective, but I'm sure it's not the only company this applies to. Good luck!
P.S. When you do a job interview with Google, you sign an NDA promising not to reveal the interview questions you're asked. Take this seriously. You can be put on a permanent ban list, have your job offer rescinded, and even get fired for leaking questions.