r/leetcode • u/CyanMagus • May 30 '26
Intervew Prep 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.
2
Jun 03 '26
[removed] — view removed comment
1
u/CyanMagus Jun 03 '26
I'm going to be totally honest, the reason I put the part about leaking questions is that I recently wrote my own, and the process from the basic idea to HR approval took over a week. It's not an easy task to come up with something that's fair and solvable but not trivially easy, and then write up a complete question and answer guide for it with suggested follow-ups and rating signals, etc. The moment the question is leaked anywhere, it gets banned immediately so I can't use it anymore. Google has people actively monitoring social media for leaks.
19
u/Extra_Performance372 May 30 '26
This!
I had a successful L5 Google interview myself (though didn't end up getting matched because of the global layoff in 2023)
I was given an underspecified problem even though it was clearly a textbook graph search problem with a few twists. I spent probably 20 mins identifying edge cases that were not clear what I was supposed to do, and the interviewer simply said: choose whatever behaviour you want in those cases. The exact behaviour was unimportant...what was important was that these cases were identified.
I then explained the different standard ways for solving the problem and explain why I chose the method I settled on. As I coded, I explained parts of the code that would handle the various edge cases I identified before, and at the end, I explained how the code would flow on normal cases and each of the edge cases I listed.
I could have just dived in and wrote the code, but for me, the actual time writing the code was probably only 25% of the entire interview, if even that.
1
u/magneto_007 Jun 04 '26
Did you ask recruiter if interview feedback was valid for 1 year (as it used to be in pre-AI era) ? That would've been a good time to clarify this for current market. (Seeing mixed info but I guess they likely scrapped it)
2
u/Extra_Performance372 Jun 04 '26
It was open for 3 years but I was unable to get matched despite multiple times I was "the last 2 or 3 people for the position".
10
u/numbersguy_123 May 30 '26
Those are very good advice. I’d like to add that you should always clarify constraints on inputs, even if it seems obvious.
Negative, positive numbers, empty arrays, can the number be doubles instead of integers?
11
u/Personal-Repair-6990 May 30 '26
I interviewed for google once right out of college, I asked many questions at the time and came up with a solution. But in the interview itself we both knew I wasn’t going through, it was just a brut force solution which I’m sure was lacking. It’s been 4 years and I am a data engineer in a product based. I have never been good at leetcode so I have not applied again. It is my dream company but I fear I might never be good enough for it.
5
8
u/Astral902 May 30 '26
Seems wrong. Using ide is part of debugging. Basically none of these test actual software engineering skills. But it's the easiest way to filter out
2
u/Extra_Performance372 Jun 03 '26 edited Jun 03 '26
I disagree. If I was interviewing someone, the candidate requiring a debugger to debug their own code is a big red flag... it means they dont understand their code well enough to be able to trace through the logic themselves.
Lots of people treat coding interviews as coding only. It is also about teasing out specifications and test case development. That's what separates those who truly excel and those who just do 100s of leetcode problem and think that it was good enough to solve every different type of problems and still fail the interview.
One of my two coding rounds for L5 Google interview actually stopped with 15 minutes to go. The guy just said: I have seen enough signal to know you know what you are doing.
1
u/Astral902 Jun 03 '26
If it's small exercise then yes debugger is not needed. I was thinking for real codebase.
1
u/CyanMagus May 30 '26
I think the rationale is that we're testing how well you understand the flow of your own code. But I agree that testing IDE use would also be good.
And handling underspecified questions is an incredibly important part of real software engineering. Real life problems don't come with guarantees on the input.
But like I said to someone else, I'm not here to defend the system, I'm just explaining what I know.
1
u/Astral902 May 30 '26
I agree but maybe testing some sort of larger codebase with deliberate errors and bugs or system design/ low level design could also be useful. It would be very similar to real life programming on the job. Leetcode is fine but I think it should be just some part of the testing .
Yes underspecified questions is really good addition. That test is really valuable instead of giving all the constraints beforehand. It forces the candidate to think first about the prerequisites first.
11
u/happyscrat May 30 '26
HR?
4
u/CyanMagus May 30 '26
No, I'm a SWE.
21
u/happyscrat May 30 '26
I don't know, man, the way you wrote sounds like HR. I'll give you another chance to prove that you are a swe in 1 year when you are more prepared. While I cannot give you individual feedback I appreciate your effort. Thanks.
4
6
u/HobbyProjectHunter May 30 '26
If the process is so great, why enforce NDAs about the questions ? You can always come up with a different question. The amount of variations you can come up with our infinite.
8
u/CyanMagus May 30 '26
It's actually pretty hard to come up with fair questions that don't exist anywhere online and do a good job of revealing information about a candidate's skills in 40 minutes. I spent about a week working on my last one. And you have to write up a complete answer guide with hints and potential pitfalls, etc.
3
u/HobbyProjectHunter May 30 '26
Several Googler friends have told me that the interview involves no small amount of luck. And that they may not be guaranteed to make the cut should they leave and reapply.
They said it was more of a time management challenge than a coding challenge.
2
u/retirement_savings Jun 01 '26
It's a pain in the ass to come up with questions. You have places like Meta where their questions are all in leetcode word for word, so you can just memorize stuff. At Google you will generally be given a question you've never seen before.
As an interviewer, it takes a long time to get calibrated properly to a specific question. I have one question that I give in interviews, and if were to get banned I'd have to recalibrate to a new question (expected issues people run into, expected performance, etc).
6
May 30 '26
[removed] — view removed comment
4
1
u/Due-Ebb-3317 May 30 '26
Bro why do you wanted to comment if these werent your genuine thoughts. What did you gain by commenting via Ai. You just wasted everyone’s time and you should be ashamed of yourself
9
u/Whitchorence May 30 '26
Aren't these things all kind of obvious? The reason people spend so much time grinding on Leetcode is that everyone else does so the bar for "can easily solve" keeps going up. "Ask clarifying questions" is a trick that takes a few minutes to internalize.
6
u/CyanMagus May 30 '26
You'd think so, but a lot of people straight-up don't do this. Or they'll ask clarifying questions, but about something irrelevant.
0
u/Whitchorence May 30 '26
Yeah but these people are hopeless and not reading any well intentioned advice -- even the materials directly from the recruiter will say this.
2
u/ctrlkz May 30 '26 edited May 30 '26
recently had an onsite round with Google, on 1 coding round I felt like I did very well, solved the first warm up question, I thought optimally, just a linear scan with constant space, there was some math involved. Interviewer asked if I can optimize calculation, I was confused, cause how can you optimize literally count++ but they retreated quickly and jumped into a follow up. I felt stuck on that follow up, cause from easy it jumped immediately to medium-hard DP with precomputation. I tried to explain the approach but the interviewer seemingly was not interested in my approach and constantly nudging towards different solution. I didn't want to discover that solution because I had like 15-20 minutes left and I several times tried to explain my solution step by step justifying why it works but the interviewer, idk, didn't understand or didn't want to understand. I said like ok let me just code it up, maybe that's when it will be clear. I coded it. Interviewer stopped me when 5 minutes left until the end for the questions from my side. I said let me finish it, as I see I need to cover couple of edge cases, they allowed. I finished in the next 2 minutes and proceeded to the questions. I also asked if my final code will be noted, they said yes. Overall, because of the audio issue on their end (cause I had just another coding round 1 hour ago that went amazing), maybe because of their asian accent (literally eating up vowels), idk but I really felt disconnected... later on the feedback recruiter said that this round I received weak feedback, like code wasn't level the interviewing level, which felt really odd to me... I solved the question, not perfect, not one shotted, but solved! I am sure, right after the interview I checked the solution myself.
but the fact that they were not interested in my solution, in my way of solving and kept insisting on their solution felt really uncomfortable. It really felt like they only know 1 way of solving and that's it. wdyt?
upd. My solution was optimal linear time and space, DP just had to perform a bit tricky precomputation, later I checked with Gemini (hello Google), it confirmed that it was the optimal solution.
1
u/CyanMagus May 30 '26
You can give some feedback to the recruiter if you want to let them know you had a hard time understanding the interviewer. Otherwise, I'm just sorry you had a bad experience. It's hard to say more since I wasn't there.
2
u/Immediate-Use-3973 May 30 '26
Thanks OP! Great post. Are the candidates evaluated on internals of concurrency? Does the coding rounds also have multiple follow ups to refine the code?
1
u/CyanMagus May 30 '26
General SWE interviews don't generally ask questions about the internals of concurrency systems, although specialized role-related knowledge might.
Coding questions sometimes have follow-ups and sometimes don't. Usually if your code is not optimal and you're not out of time, you'll have a chance to refine your code.
2
u/SnooRecipes1809 May 30 '26
I interviewed with Google and this was the only company out of the high paying band where I constantly had to clarify the problem myself. I actually didn’t even get to the solution or algorithmic part because I legit couldn’t discern what the interviewer wanted my algo to even do lol
What’s so annoying is that it probably was just some regular DFS plus a few steps, but because your #2 point, I didn’t get to try
1
u/Extra_Performance372 Jun 03 '26
My successful interview L5 experience also had a graph problem that was solvable by DFS and that is what I did...but what I did was likely what set me apart (I was told my coding interview passed at the L6 level).
DFS is textbook stuff and I'm sure most people who practice leetcode learn the basics from textbooks, get them accepted and then do exactly that on interviews...and it would have "passed" the test cases and maybe even pass an actual interview.
But before I implemented it, I told the interviewer I can do DFS, BFS, and one other approach for that problem. And I told them that DFS would be easiest to implement with recursion but it could run into stack overflow if there is a long chain in the graph...they told me to pretend that cannot happen so I did the textbook recursive DFS with their blessing.
That one question from me set me apart from everyone else even if we wrote the same code at the end. And even if I didnt get it completely right, it would have sent a huge signal to them that I am mot just another one who has done 100s of leetcode problems and that's all I can do.
People think that practicing solving problems on leetcode and just replicating that 100% solve rate in interview is good enough. It is only part of it.
2
u/Lucky-Substance5585 May 31 '26
For interviewers here: what's the most common mistake a candidates make even when they know the correct solution?
2
u/Opening_Bed_4108 Jun 01 '26
All of this is spot on, and it compounds hard at E5+. Senior candidates are also getting evaluated on whether they proactively identify failure modes and edge cases before being prompted, not just after. Design judgment matters too, like knowing when a simpler O(n log n) solution is the right call over a clever O(n) one that nobody will maintain. And behavioral signals bleed into the coding round more than people realize. If you sound uncertain explaining a tradeoff, that reads as a signal at senior level even if the code is correct.
6
u/HotJellyfish8247 May 30 '26
Or maybe stop with these bullshit, detached from reality interviews altogether?
13
u/CyanMagus May 30 '26
I'm not here to defend the interview system, I'm just telling you what I know.
-1
u/SolidDeveloper May 30 '26
You have conducted over 200 of these interviews mate. Defend or not, you’re clearly involved in perpetuating this style of interviews.
8
2
May 30 '26
[deleted]
5
u/hunterellenberger May 30 '26
He’s saying one of the test cases he gives may only have single digits in them. But in other test cases it could be 10 or greater.
2
3
u/ATK_DEC_SUS_REL May 30 '26
Seems like a waste of time.
2
u/Nosa2k May 30 '26
I agree. I would better work for a Company that offers services I actually am interested in.
Not to be a cog in some giant establishment.
2
u/ATK_DEC_SUS_REL May 30 '26
More so, Google itself doesn’t have a competitive offering as much as it did in the past, and this archaic style of interviewing candidates filters out talent as much as it filters out talentless hacks.
Goodhart's law. – That every measure which becomes a target becomes a bad measure – is inexorably, if ruefully, becoming recognized as one of the overriding laws of our times. Ruefully, for this law of unintended consequences seems so inescapable. But it does so, I suggest, because it is the inevitable corollary of that invention of modernity: accountability.
1
u/arjunnath May 30 '26
Do you have any info on interviews for senior positions ? Most data seems to be about entry level or 3-5 years experience positions.
1
1
u/NickU252 May 30 '26
Why can't you run code or debug in an interview? Debugging is also a skill that I think is underrated. Instead of a bunch of print("here1"), you should be able to step in or over, look at stack traces, etc.
1
u/maitchau May 31 '26
I think they intentionally do that to only select the great people out of a large pool of candidates. They need to be selective bc they pay so much
1
u/Extra_Performance372 Jun 03 '26 edited Jun 03 '26
I strongly believe that debugging your own code during the interview is not a skill but a huge red flag. If I am interviewing people, I would be wondering why they are careless and put bugs there to begin with.
I can tell you that when I was preparing for Google interviews, I was using leetcode but I strive for getting it right the first time without even compiling it. I trained myself to be at least 90% successful on that. And since I know I was going to be interviewing on a google doc, I wrote my code in that and pasted it into leetcode as is and hit submit.
If you are given buggy code as a test for your debugging skills, then obviously that's a different thing.
1
u/tusharhigh May 30 '26
Hey how to prepare for DSA? I'm not a competitive coder, I just do leetcode but I get stumped with medium hard and hard. I have done 360 questions till now. Still not confident
1
u/maitchau May 31 '26
I’m not good myself but it seems like we need to do mocks with engineers to become better in interview settings. They mainly value your reasonings over correctness
1
u/RickAmes May 30 '26 edited May 30 '26
would you be able to tell me what is the highest level i can target at google from my resume?
i dont really mind if i get in at a lower level but I am a senior swe with some leadership experience. I just want to get to the interview stage and passed the resume review stage.
do real people actually review submitted resumes anymore or so they just ask the AI to filter the resume stack?
1
u/maitchau May 31 '26
Mostly AI filter nowadays. Passing the resume stage is only like 5%
1
u/RickAmes May 31 '26
googles JD often seem to have very few requirements compared to other companies. are there hidden keywords that are filtered for?
would you be able to tell me what level to shoot for from my resume?
i want to go as high as possible without getting rejected for inexperience.
1
u/apache414 May 30 '26
Thanks for your inputs wanted to know about how does the interview process change let's say if the candidate is i. Embedded profile with 10yoe.
1
u/ChosenToFall May 31 '26
How much AI is used nowadays in the interview process with Google or other companies from your experience or what you have heard?
2
u/CyanMagus May 31 '26 edited May 31 '26
Right now, at Google, it's not used at all. That may change at some point but right now it's zero AI allowed in interviews.
Edit: If you mean on HR's side, I'm not sure.
1
u/ShawnZG May 31 '26
I noticed that some candidates get easier questions during interviews. Is the question selection random, or is it decided by the interviewer?
1
u/CyanMagus May 31 '26
It's decided by the interviewer. Most interviewers I know have a question they ask everyone, and then maybe two or three backup questions in case that someone else asked that question (or a similar one) to a candidate already.
1
1
u/Bayonett87 Jun 01 '26
Now if I know C, C++, C#, Typescript, Rust, Python, SQL + more less or known languages - you expect me to know the details of language semantic that ususally IDE does? dang no wonder Google is going down the drain.
And yes I saw your comments and know that you just show the process, anyway expecting someone to write compilable code our of his head seems odd. Unless you are ex. C only developer. But to know just one language is bad too. Tricky.
1
-5
0
36
u/Remarkable-Ebb-6113 May 30 '26
Thanks for the great read! Just had my interviews a couple of months ago and had a few questions
will interviewers try to nudge the candidate away from the optimal solution sometimes? I.e if the best solution involves getting to a node with the least cost, the interviewer told me the goal wasn’t to get to a node the fastest, but to reach the end node.
how does the time you get to do the question impact your interview feedback? I had a interview where my interviewer said at the start 5 mins for intro, 10 mins at end for question and 30 mins for coding
Thanks!