When I interviewed at Google in 2006, one of the interviewers asked me to write code for solving a particular problem. I replied along the lines of "ok I need to think about this, it's not obvious how to solve it" and started thinking. Time ticked away. Five minutes. Ten minutes. Fifteen minutes. The interviewer started reminding me that he needed me to write some code and if there wasn't anything for him to copy dow…
I interviewed with Google once around the same time frame. The position I interviewed for was something along the lines of datacenter operations. I did my interview from a local Google sales office and interviewed with three other employees via video call. This was around the time that Skype was fairly new, but whatever software they were using was clearly internal to Google. Anyway, I ended up talking with 3 enginee…
The question server repair question served 2 purposes:
1) can you identify a minimum bootable state / repeatable failure case? Can you think of obscure corner cases like the metal tray that all the components sit on being the problem?
2) How quickly do you give up and ask for help from humans / other sources.
Both were core to the role. Changes in hardware and firmware often resulted in issues needing to be escalated back to manufacturers / internal platform team. The volume/scale of work also meant that being able to concisely convey what you had observed / tested and hypothesised helped the team identify trends / larger issues that were occuring. Datacenter automation and tooling was very much in its infancy.
Around that time, the org was growing rapidly (doubling in size yearly) so most people ended up doing interviews. Not everyone is cut out to interview so sorry if your experience was sucky.
Side note: I once spent most of an interview slot talking to a candidate about snowboarding. Turned out to be one of the best hires we made (thankfully the other interviewers actually asked some role related questions).