I had four interview rounds:
Googliness Round: This went well. I’m not sure if it was perfect, but I gave good answers. I can confidently say that it wasn’t bad, and there were no red flags.
Coding Rounds:
For the coding rounds, I asked a lot of questions at the beginning about edge cases, constraints, etc. The interviewers never pointed out any missing edge cases. I thought out loud the entire time, ensuring there was never a moment of silence. I explained everything I was thinking and doing, and they never had any questions about what I was doing or why I was doing it.
Intervals Question:
The interviewer mentioned at the beginning that he would ask just one question. It was an interval-based problem where multiple interval lists had to be merged into one list with certain restrictions (I can't share the exact question). I implemented a working solution. When he asked how to optimize it, I analyzed the bottlenecks out loud and concluded that there was no clear improvement with my approach. He then suggested using a different data structure, like a priority queue, but also mentioned that my approach was correct and looked good. In the last five minutes, he didn’t ask for a dry run or time complexity analysis. Instead, he asked if I had any questions, and we spent the remaining time discussing what it’s like to work at Google.
Dynamic Programming Question:
Can't share details since I couldn't find any similiar question yet. I used dynamic programming to solve it and performed a dry run on the given example. Midway through the dry run, he provided another example and asked me to test it. I suspect he had noticed a bug in my code, but while I was working through the second test case, he stopped me and said it looked good and that we didn’t need to continue testing.
When he asked how to improve the approach, I suggested adding caching, but after discussing it, we realized caching wouldn't be useful since every combination would be explored, and we wouldn’t revisit the same states. He said my approach looked good.
When discussing time and space complexity, I correctly stated the space complexity. However, for time complexity, I mistakenly said n³ instead of n!, simply because I forgot how to pronounce factorial at that moment. He corrected me, and I immediately acknowledged the mistake since I had been thinking of n! in the first place.
At the end of the interview, he asked me to check whether my output matched the problem's requirements. At that point, I realized that while I had correctly computed the minimum cost, the question was actually asking for the ordered list. I explained that at the beginning of the interview, I had asked if the expected result was just the minimum cost, and he had confirmed it. He acknowledged this but clarified that I still needed to return the ordered list. He left me some time to fix it, and I was able to correct the return type before closing the code file.
Shortest Path with Blocked Nodes:
The problem was a shortest path question where certain nodes were blocked. I implemented a BFS-based approach, and the interviewer didn’t ask for a dry run. He then gave me a follow-up: finding the path that minimizes the number of blocked nodes used. He gave me a small hint that distance was no longer the key factor, and I came up with a priority queue approach.
At the end of the interview, he didn’t ask for a dry run or a time/space complexity analysis. When he asked if I had anything to add, I proactively shared my thoughts on the time and space complexity for both solutions. He didn’t correct anything (even if I might have been wrong), and the interview ended.
What do you guys think about my chances? I am really nervous..