Also, part of the point of a Google style interview is to keep pushing you to the point where your ability fails, then push in another direction to the point your ability fails. That way, they get an idea of the dimensions of your skillset. The vast majority of the people I recommended hiring didn't answer the questions perfectly.
Or, someone could not quite put enough thought into the integer encoding for Protocol Buffers. The encoding actually used is that the first bit of every byte is a flag for if there's a next byte, for a maximum of 10 bytes. The only advantage to this over encoding the length of the integer as the number of leading ones in the first byte (like UTF-8) is if they want the option to have the option later of a forward-compatible encoding for longer integer types, without just supporting multi-precision integers as byte arrays. If you slide all of those flag bits to the first byte, you don't have any more or any fewer flag bits, so it takes as much space, but you can use a jump table and the ability to use native 8-byte and 4-byte simple loads instead of many more masking operations and conditional branches. Giving up on anything longer than int64_t means that the maximum encoding length becomes 9 bytes instead of 10.
One day, the speed of the indexing system just dropped in half. It turns out that someone wrote a job that used machine learning to generate a bunch of regexes for some signal. They were recompiling the regexes for every page in the index. Google really needs most of their engineers that will naturally spot this kind of thing in code reviews, because if every engineer on the indexing team made a mistake like that once a year, the indexing system would always run at half speed, sometimes even 1/3 or 1/4 speed.
The indexing system uses as much electricity as a small town. The tiniest of improvements can mean thousands of dollars per year in savings.