Google L4 Interview Experience

Positive. The interviewer was enthusiastic and collaborative. The interview felt more like a discussion than a questioning. I was able to voice my thoughts well due to the collaborative nature of the interview, come up with an optimal approach, and then code it up quite quickly. At the end as a followup interviewer asked if there are other optimisations possible, and as I was trying to find it out, time ran out. (PS: I still do not know what optimisation is possible on my approach :P). I received a positive feedback, with a note that I was not able to reach the most optimal solution but the solution was optimal enough as the BigO complexity was the same.Neutral. The interviewer gave the question, and as I was working through my thoughts on the solutions, the interviewer asked questions about my approach. I was able to explain my thoughts and once the interviewer was satisfied, I went ahead to coding. Post my code, interviewer identified some edge cases which were not addressed, which I then addressed in my code as well. Then interviewer asked if I can optimise it even further. Here I was slightly stuck and the interviewer had to give a hint, post which I was able to figure out the most optimal solution, and then code it. I was barely able to finish the code and dry run, with just 1 minute left in my interview time. I had to write code for two different approaches in this round which led to improper time management on my part. Feedback was positive, with a note that debugging and edge case handling was lacking.Very Positive. The interviewer was very enthusiastic and collaborative. Once the question was given, I started with clarifying questions to ensure I understood the question. Some of my clarifying questions were appreciated by the interviewer as identifying the gaps in the question. I came up with an approach and interviewer was satisfied with the approach. I went ahead to coding, and then interviewer asked for dry run with multiple sample inputs. Within this discussion, I corrected some small bugs, and made the code more readable and improved the understandability of the code. I then realised that there is an optimisation possible which would greatly improve the complexity of my solution. I mentioned this to the interviewer, and he said while there is a more optimal approach, he is satisfied with my current approach. In this round, even though I did not code the most optimal approach, due to the highly collaborative and feedback driven round, my experience was positive, and the interviewer also gave a very positive feedback.Neutral. I started with a lot of clarifying questions to make sure I have the right understanding of the problem. I then explained a basic approach, which the interviewer was satisfied with. However, I came up with the solution very quickly and therefore instead of coding the first approach, he asked me the follow up question, and once I gave the approach for that, he asked me to code that approach. I completed the code for that approach. The interviewer went through the code very minutely, and had a lot of questions regarding the code to understand it better. This took a good amount of time. Once he was satisfied with my code, he then asked me the second follow up. This follow-up was challenging for me, and I was unable to come up with a solution for the follow-up in the interview time. I did however come up with the optimal solution on my own right after the interview ended. Therefore this was also an area of my time-management which I could have improved. I took a long time to explain my code and approach for the first follow-up because I did not think there would be another follow-up. My feedback was positive, with a note that my debugging skills are slightly lacking. I am not sure why this feedback note was there as we did not identify or fix any bugs. The dry runs were also all successful. It is possible that I truly missed a bug, but it was never mentioned in the interview itself.