This was in 2020, so all interviews were fully virtual and each lasted 45 minutes. I understand that they were likely inundated with applicants and that 2020 was a difficult year for many, but more than half of the interviewers I spoke with barely bothered to provide basic niceties such as their name, who they were, where they worked, or what they do. This context usually goes a long way toward understanding who they are, their background, how they might view a technical problem, or even how they communicate it. Anyone with a modicum of experience knows that engineers with different backgrounds may be more accustomed to slightly different terminology based on their experience (e.g., "function" vs. "method"). They might also care more about algorithm choice efficiency versus clarity of design and maintainability of code.

Many of my interviewers seemed content with cut-and-pasting a problem and then returning to whatever they were doing, presumably hoping I would just code in silence for the next 40-ish minutes. The usual flow of the technical part of a code-required technical interview goes something like this:

• Brief discussion to verify comprehension of the asked question, assumptions, boundaries, etc.
• Discussion of possible solution(s) and the characteristics/tradeoffs of said solutions
• Coding the solution
• Some review of the code (optional)
• Discussion of follow-on problems/concerns (optional)

The usual tips (not Google-specific) to over-communicate your thought process so the interviewer understands what you're thinking were completely absent for more than half of my interviewers. Despite being on video, it was as if I was talking through a one-way mirror where they couldn't see or hear me. Discussions of multiple possible solutions or tradeoffs were often one-sided with very little feedback. In a word, the entire experience was super awkward. Some of the questions asked were more complicated than trivial textbook CS questions, so it was hard to know how the interviewer wanted to steer me through the question. Simple things like "Should I just choose the implementation which is fastest to write in what's essentially a Google Doc?" or "Are you looking for understanding of something more efficient than just the first brute-force approach that came to mind, so I can write code as quickly as possible?" were left unaddressed. In at least one case, my thought process was, "This seems way too simple; am I just missing something?"

The irony of the situation is that Google even provides YouTube videos demonstrating a sample interview process where there is some back-and-forth about the problem. More than half of my interviewers had really nothing to say other than to encourage me to just get some "working code" written as quickly as I could.

Maybe the entire process is just designed that way, but it's a pretty wild contrast to every other sensible interview process I've ever engaged in.

Net net, I'm pretty sure I nailed the two sessions with people I could actually see myself wanting to work with and failed the ones conducted by anti-social robots who didn't want to be there.

There were all sorts of technical mishaps with their ATS and scheduling, so I'm not sure if there was even a specific job title, but this was for a more senior role. As a point of comparison, I interviewed with Amazon at the Principal Engineer level around the same time. Their process seemed 1000 times more sensible.

I don't remember all of them, but one was to implement an API that can increment or return an unbounded-length number.