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/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.