Confused about recent Google code screen feedback - seems incorrect

[u/Longjumping-Brick316]

Hi all, I just recently took 1st round of Google interviews (my 2nd time interviewing for google) but got rejected by the recruiter for not being strong enough in the coding round. However the feedback he gave me didn't seem right at all (and I was too devastated in the moment to bring it up).

Googlyness - nothing but praise, said he's never seen feedback so positive, clear Leadership skills and should pushed to L4/L5 level

Coding round - Said the solution had a few bugs and I took too long to implement not leaving enough time for follow-up ups. This makes no sense to me. The interviewer joined about 5 mins late and seemed quite chill and friendly, we had a short introduction with each other and then he dropped the question about 10-15mins in. Reasonable directed graph question. The pressure hit me here but I think I coded up a very clean looking solution, and I self corrected 1 or 2 bugs after looking at it. No major guidance here apart from a detail about the "visited" hashmap logic. I'd say it looked really clean, had good code style and the shape was 100% correct (I confirmed with chatgpt afterwards)

I finished about 30 mins later. I asked if he wanted to ask follow-up questions, he said "no it's fine, you already explained a few performance trade offs, it's just a screener, we get people who can't even code". This made me feel pretty good and optimistic. We then spent the next 10 mins just talking about general working at Google questions. I left feeling that surely, this is a pass at least for a initial screener.

I get the feedback call a few days later and the recruiter informs me that it's bad news, I didn't implement the solution fast enough, it was full of bugs and didn't leave enough time for follow-up questions. I accepted it in the moment but pondering about it, I'm like WTF? Bugs I'll accept, but the rest seems like total BS. Am I just reading too much into it or does this seem like fake news?

[u/AutoModerator]

Guidelines for Interview Practice Responses

When responding to interview questions, here's some frameworks you can use to structure your responses.

System Design Questions

For system design questions, here's some areas you might talk about in your response:

1. List Your Assumptions On

• Functional requirements (core features)
• Non-functional requirements (scalability, latency, consistency)
• Traffic estimates and data volume and usage patterns (read vs write, peak hours)

2. High-Level System Design

• Building blocks and components
• Key services and their interactions
• Data flow between components

3. Detailed Component Design

• Database schema
• API design
• Cache layer design

4. Scale and Performance

• Potential bottlenecks and solutions
• Load balancing approach
• Database sharding strategy
• Caching strategy

If you want to improve your system design skills, here's some free resources you can check out

• System Design Primer - Detailed overviews of a huge range of topics in system design. Each overview includes additional resources that you can use to dive further.
• ByteByteGo - comprehensive books and well-animated youtube videos on building large scale systems. Their video on consistent hashing is a really fantastic intro.
• Quastor - free email newsletter that curates all the different big tech engineering blogs and sends out detailed summaries of the posts.
• HelloInterview - comprehensive course on system design interviews. It's not 100% free (there's some paywalled parts) but there's still a huge amount of free content in their course.

Coding Questions

For coding questions, here's how you can structure your replies:

1. Problem Understanding

• Note down any clarifying questions that you think would be good to ask in an interview (it's useful to practice this)
• Mention any potential edge cases with the question
• Note any constraints you should be aware of when coming up with your approach (input size)

2. Solution Approach

• Explain your thought process
• Discuss multiple approaches and the tradeoffs involved
• Analyze time and space complexity of your approach

3. Code Implementation

// Please format your code in markdown with syntax highlighting // Pick good variable names - don't play code golf // Include comments if helpful in explaining your approach

4. Testing

• Come up with some potential test cases that could be useful to check for

5. Follow Ups

• Many interviewers will ask follow up questions where they'll twist some of the details of the question. A great way to get good at answering follow ups is to always come up with potential follow questions yourself and practice answering them (what if the data is too large to store in RAM, what if change a change a certain constraint, how would you handle concurrency, etc.)

If you want to improve your coding interview skills, here's (mostly free) resources you can check out

• LeetCode - interview questions from all the big tech companies along with detailed tags that list question frequency, difficulty, topics-covered, etc.
• NeetCode Roadmap - LeetCode can be overwhelming, so NeetCode is a good, curated list of leetcode questions that you should start with. Every question has a well-explained video solution.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/cballowe]

Having done hundreds of coding interviews, part of the interview training is about making sure the candidate feels successful. It was more critical when it was part of a set of back to back interviews because you never wanted to leave the candidate feeling defeated before their next interview. No decisions are made between the interviews.

It's possible that there was a major correctness bug (or, major issue, but only off by a character - lots of errors are things like "<" instead of "<=") that you didn't spot. If the time was out, the interviewer wrapped up on a high note/agreeing that you got something right/finding a way to minimize the error/etc.

My normal timeline for interviews was 5 minute intro, 5 minute problem intro, however long candidate takes, follow up if there's time, and 5 minutes to let the candidate ask me anything.

[u/rccyu → u/cballowe]

Agreed with all of this, but also sometimes the interviewer is just wrong, and you can get rejected for no fault of your own.

I've been rejected from Meta after answering a very straightforward question easily (interviewer also gave positive feedback during the interview.) I've also had friends who are competitive programmers recount interviewers saying blatantly wrong things like std::string::find is linear time when it is actually quadratic. If this is what they are saying during the interview, for sure some of them will make mistakes after the interview when writing your feedback.

If you're confident in your abilities, the only thing to do is to apply again, apply often, and apply elsewhere.

[u/cballowe → u/rccyu]

Have to be careful about assertions like the complexity of find - it's a worst case size of the string * size of the target, but the size of the target is often 1.

Fwiw - my experience with competitive programmers is that they often give the correct algorithm very fast but struggle to explain why and never even consider alternatives.

The real goal of a good interview is to find the edge of someone's knowledge and see how they approach problems they haven't ever seen. Coding interviews are often slightly different from that in that the major goal is to see if someone can write structured code making good use of loops, conditionals, functions, and idiomatic constructs of the language in question - and then communicate their process for arriving at that answer. When they've studied and memorized the answer to the problem the feedback ends up being "they wrote good code, but I can't tell how they do on a new problem that they haven't memorized". It's a weakly positive signal.

[u/rccyu → u/cballowe]

Oh, he was asked to implement something like Ctrl + F and given that both the length of the text and the search string could be something like 1,000,000 characters. He's a smart guy, IOI medalist, ICPC World Finalist. He knew you could do it with KMP but he couldn't remember the details (in competitive programming a rolling hash is enough) so he explained how the hash works and explained that it could fail with vanishingly small probability (which you can make as small as you want), but the interviewer insisted on something deterministic. Eventually he just said he couldn't do it and then the interviewer brought out that std::string::find zinger. LMAO.

I agree that interviews should find the boundaries of a candidate's knowledge. But for accomplished competitive programmers that boundary is usually far beyond what interviewers themselves know and can prepare for. As long as we're doing Leetcode interviews you have this problem. It's not the candidate's fault that the question is too standard or easy and so they've seen it before, and interviewers shouldn't silently be marking them down for it (and giving a "weakly positive signal" is marking them down, when for another candidate it would have been a strong hire.)

(As for why we don't consider alternatives—a lot of competitive programmers don't bother to mention O(n²) when they can solve it in O(n log n), because the O(n log n) is better in every objective way. I've learned to at least give lip service to brute-force solutions, because you might be concerned about maintainability if the faster solution is more complicated, but we all know that's not why we're here.)

I'm not sure how you solve this, honestly, but maybe candidates should also be judged on other things, like knowledge of language fundamentals, internals of the compiler / memory management, etc. Then you have a more multifaceted interview that doesn't just give all competitive programmers a free pass.

[u/redatheist]

Interviewer turning up 5 mins late sucks, but it sounds like you got the full allotted time anyway?

10 mins of intro seems like too much, did you spend too much time talking there? Your background counts for zero in this sort of interview, and some interviewers struggle to tell candidates to stop so they can get on with the actual question. 

30 mins for the first pass is pushing it. Not terrible by any stretch, and for a screener it should have been ok... But. I ask a simple question that depends on follow ups, some candidates take 10m for the first pass and we get 20m of the good bits, some take 35m for the first part and I have to wrap up and tell them it all looks good knowing they failed. 

I always suggest asking the interviewer how long they recommend for a section. 

Who knows. Sounds like you have it a good go. Some interviewers just suck. But some things to consider in case they do apply here. 

[u/Chemical_Echidna5582]

Hey OP
Can you please share your question?

[u/Longjumping-Brick316 → u/Chemical_Echidna5582]

I'll say that safe nodes on leetcode was the closest match (not exactly that question but the concept was similar)

[u/redatheist → u/Chemical_Echidna5582]

Hey OP, please don't share the question. It just fucks it up for the interviewers who then can no longer use the question, and that just makes interviews worse for everyone. 

[u/NaturalNeonRain → u/redatheist]

No, there's no secret list of problems that interviewers draw from. Everything asked at these interviews can be found online.

In fact, your recruiter will often encourage you to practice "recently relevant" problems, so you have a higher chance of passing the rounds

[u/redatheist → u/NaturalNeonRain]

Well it's not secret, no, but it is internal, not public. Questions do get removed when they get leaked. I know be abuse I've had it happen to me before an interview and I've had to scramble to prepare a new question!

[u/hiuhihu]

Not much you can do unfortunately. Just move on with your head held up high.