Google Cloud and TPU Behavioral & Ownership interview questions

The interviewer is not checking whether you can say no. They are checking whether your no came with a number, an alternative and a date. The four-part shape that makes this story land, a worked example with the arithmetic a real one carries, and the version that fails.

Saying no is easy and it costs you the relationship. The move that works is to make the queue visible, give the researcher something they control, and offer a smaller thing today. The three mechanisms that turn this from a recurring argument into a system.

Every migration story has the same technical answer and a different social one, and the social one is what is being scored. The sequencing that makes a migration reversible, the rollback that has to be real, and why the status page matters more than the tooling.

Reciting a lab's published positions back to them scores nothing. The infrastructure answer is concrete: who can read the weights, what is logged and for how long, how much capacity evaluations get, and how fast a deployment can be stopped.

Measure the hours before you rank anything, because the task that feels worst is usually not the one that costs most. The ordering rule that keeps automation from causing the outage it was meant to prevent, and why detection always ships before remediation.

A capacity fight is almost never about capacity. It is two teams with different information and no shared number. The move that ends it is publishing utilization both teams can see, and the escalation that works is a written proposal with options rather than a request for a ruling.

Both easy answers fail. Refusing without an alternative makes you the obstacle and guarantees the next person routes around you. Complying makes the check meaningless. The four-step response that holds the line and still gets the researcher moving today.

Most postmortem documents are written, filed and never read again. The three parts that decide whether one changes anything, why action items without a named owner and a date are decoration, and the meeting rule that keeps blamelessness from becoming vagueness.

Taking the keyboard teaches nothing and is the reflex under pressure. The handoff that works, the four questions that make someone's reasoning visible, and the point at which you stop asking questions and take over.

Being right is a small part of this. The move that works is converting an opinion into a document with the tradeoff written out, and then committing fully once the decision is made. The two cases where escalating is correct, and how to do it without a fight.

Not depth, which is where most people push and where the returns flatten. What changes is the size of the problem you are handed, how ambiguous it is when you get it, and whether things happen because you asked rather than because you built them.

The interviewer is checking whether you know what you are trading, because both directions are reasonable and both have a version that ends badly. What each environment actually gives you, and the answer that works when the real reason is compensation.

Most platform tools are built for the platform team's model of the work rather than the work. What makes a tool get adopted, the measurement that proves it helped, and why the fast path for small jobs beats almost anything else you could build.

A war story with no learning in it scores zero, however dramatic. The five beats of an incident narrative, the decision under uncertainty that is the actual subject of the question, and how to tell it when the incident was somebody else's fault.

The answer that fails is a compliment to the company. The answer that lands is a thesis about where the constraint sits, tied to something you have actually done, and it works whether you are coming from distributed systems, kernels, hardware or SRE.

A speedup number with no method behind it is worth nothing, and experienced interviewers stop listening at the number and start asking about the baseline. What makes a performance claim survive scrutiny, and the four ways a real one turns out to be smaller than it looked.

Everyone has this story and most candidates tell a flattering version of it. The bias that produces almost all of these mistakes, the cost you have to be willing to name, and the process change that is the difference between an anecdote and a lesson.

The answer that fails proposes changes in week one. The answer that lands reads the postmortems first, draws the map from the job's point of view, ships one small fix, and ends the month with a list of questions nobody on the team could answer.

Naming three newsletters answers nothing. The answer that works has a filter, a source of ground truth that is not a blog post, and one thing you reproduced yourself, because that is the only evidence that you learn rather than accumulate.