Just finished my Google onsite. Something came up in one of the coding rounds, and I want to ask the folks and interviewers here on the forum how they'd read this:
r2, first question: the piano-finger-movement problem (sliding window, similar to finding a monotonic interval / window coverage).
First part: I wrote the code fast, dry-ran the interviewer's three test cases live plus a couple of edge cases, and it all passed. I also walked through the time and space complexity.
Follow-up: I wrote the core logic too. But time ran out and I was just a few lines away from finishing — didn't get to wrap it up. Right before time was called, I verbally walked the interviewer through the sample output, and the answer was correct. The interviewer acknowledged it.
I want to ask: in a situation like this, do interviewers usually lean toward hire or lean hire? How much does getting the right answer save me? The interviewer gave me a hint on this one.
r2, second question: a classic trie problem with a lookup — pretty standard. I spent too much time going back and forth on the brute-force approach, so by the time I started writing the trie solution I was running low on time. The interviewer gave me an extra ten minutes and helped pull me through, and I got it finished. Thanks to him for that.
As for r1: one coding round, and I wrote that one very smoothly. One BQ round — since I passed, I'm assuming that's at least 2 hires. If r2's first question comes out as lean hire and the second comes out as strong hire...
2 hire + lean hire + 1 hire/strong hire — is that combination enough to get an offer, or get sent to committee?
Discussion
Loading comments…