Gathering and defining requirements is very much a part of the job. It is entirely unsustainable to rely on others to tell you what to implement in Google.

How many interviews involve asking the prospective hire if they know how to gather and define requirements?

This is implicit in a coding interview, though. I, the interviewer, take a couple of sentences to describe a problem. What next? Way too often, rather than ask more questions - gather and define requirements - a candidate will launch straight into solving a problem different from the one I am describing.

Requirements gathering in reality can often require more soft skills or political skills, which doesn’t seem to be the primary focus of these interviews. Which isn’t to say the skills you mention aren’t important.

Most engineers at Google never talk to non-engineers, the requirements gathering comes instead from looking at code, reading design docs and talking to other engineers.

AKA "rush to keyboard" syndrome.

>> Gathering and defining requirements is very much a part of the job. It is entirely unsustainable to rely on others to tell you what to implement in Google.

It's like that everywhere. Nobody comes to you with complete requirements. People/customers come with problems they need solved. Sometimes an outline of a specific solution is specified, but there's always a lot of detail missing.

Not at all. I've been at Google for a bit over two years, and my experience has been at the far other end of the spectrum: a lot of autonomy, gathering requirements, designing & implementing. Also I have a fair amount of agency to see something that would make people's lives better and pitch it as a thing I'd like to work on. If it's less than a day or two of work I can generally just go do it.

How much of interview-style coding is involved in your work? More broadly, would you agree to the OP that interviewing for software developers is broken?

> Also I have a fair amount of agency to see something that would make people's lives better and pitch it as a thing I'd like to work on.

You’re clearly not working on their military-contract Terminator-drone program…

…Unless “better” means “stone cold dead”.

Working at Google. My opinion is my own, etc etc

What you get told is What needs to be accomplished, but not How, if that makes sense.

E.G. IF you choose to accept this challenge, this platform is running at XX% availability and we need to run it at YY% availability. HOW you get to do that, it's up to you.

Some folks don't accept these challenges and they go and find and fix their own interesting problems. But that's harder because you have to get buy-in from managers in order to get resources for that.

There is space and need for everyone.

Google's big enough that no one person could possibly speak confidently for all of engineering in this regard.

For what it's worth, this doesn't match my experience at all. In the area I work in (SRE in technical infrastructure, but the same seems to be true for our dev partners), I see a lot of expectation for bottom up ownership. I could totally understand if somebody with a different mindset and perspective (I'm a manager, so I can see pretty clearly what's valued at evaluation time) arrived at a different conclusion.