Completed two rounds of phone screens in the past couple weeks. Wanted to know if anyone can point to any feedback to grow. Unsure where to look other than be more "perfect", never stumble or stutter, and code very, very quickly. I never got stuck, but had some occasional typos and minor bugs I was able to quickly identify and correct.

• My first screen was some derivation of choose top K (100) elements of highest value. Followup, make a class of it.

1. 10-12 minutes of intros and a couple of small behavioral questions (tell me a time when...)
2. Spent maybe 10 minutes to break the problem down, I had some math issues and misinterpreted what it was asking at first, but had my interviewer bought in with my approach.
3. Spent perhaps 10-12 minutes coding, fixing a minor bug on how I was calculating something within my loop (1 minute)
4. He seemed happy with the first part and then with 7-10 minutes left for the followup, he said we can only probably talk about it. Create a class with 3 functions: add new elements, remove, and get top K.
5. I coded most of it out and from the get-go mentioned there were 2 main ways to do it. Using a hash table for easy add and remove lookup, but getting top K will be nlogn. Other way is to keep a heap where we compromise add and remove, but getting top K is linear respective of K's value. We were at time, so he didn't really engage with me at this part (uh-oh)
6. 5 minutes for questions to my interviewer

• My second screen was a derivation of what the cost of going down a path was in a graph. There were a number of contraints to calculate what each path was (nothing too complicated, but there were a number of "distractions" present and the problem was to realize that it was a simple solution)

1. 5-7 minute intros and some behaviorals (why Google and what tech stack and projects have you worked on and what percentage of your day is split between backend software engineering vs CI/CD work)
2. 8-10 minutes doing breakdown of the problem. I had a possible working idea, but interviewer hinted that I could be overthinking it and all the extra work (I thought it was matrix problem, but it was just pretending to be one) may not be necessary so I iterated and went with something much simpler using a hash. Asked if he would like me to think of any more optimization or would he like to see me code. He said it looks very reasonable and let's get something on the board.
3. 10-12 minutes of coding. Forgot to actually increment something in my loop where he caught it immediately after I closed it, so I revisited and added it back in (for small things like this, I try to finish my train of thought before reviewing)
4. Asked if he would like to run through a test sample of our input and he agreed. Spent a little over 5 minutes where I noticed an unused variable and I had a typo in one of my incrementing variables (which he complimented my catches)
5. He said there was a followup where we may just have time to talk about (over 10 minutes left) and that I was given a new input (a 2D array with a reduction factor) that would reduce the cost of the path. This interviewer in particular ate up a lot of time presenting problems from the beginning and even here so probably a good 5-7 minutes explaining what's happening. Given my earlier code structure I figured I could plug it into my loop for a very simple table lookup in my if-else for an O(1) operation. I also noticed that I didn't even necessarily need my hash if we had space constraints and could just use one of the inputs to calculate the path cost on the fly. He compliemented my catch and said this all looks great and that we can wrap up
6. 8 or so minutes for questions (which was actually an interesting conversation given he was there for 6+ years)

I thought a screen's purpose is to see if I was worth an onsite and that perfection, especially from the get-go, isn't what is expected. My first time interviewing for Google and I am actively interviewing so any insight is welcome.