Behavioral Interview Questions for AI Infra Engineers

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.

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.

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.

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.

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.

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.

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.

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.

Any engineer can cut cost. The question is whether you measured what it cost you elsewhere, and whether you knew that before you shipped it. The three mechanisms that produce most of the savings, and the metric you have to watch on the way down.

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.

The interesting content is the order things broke in, because that order is a property of the system and it repeats. What breaks first at each scale step, why the control plane usually goes before the data plane, and the thing you would skip if you did it again.

You cannot win this with an opinion, and a flat objection to a purchase reads as an engineer who does not understand the business. The utilization evidence that carries it, the smaller counter-proposal that usually wins, and what to do once the decision goes against you.

Arguing is the losing move and so is capitulating. What moves a vendor case is a reproducer small enough for their engineer to run, counters that isolate their layer from yours, and a bisection that removes your configuration as a variable entirely.

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.

This is a test of whether you have a position you can defend, not of which problem you pick. What makes a thesis defensible, two worked examples with the arithmetic behind them, and the counterargument you have to be able to state before the interviewer does.

The first move is not technical. It is deciding who runs what, because one person serially debugging three incidents is slower than three people in parallel and much slower than one person coordinating. The ordering rule, and the two things that outrank everything else.

The question is about how you handle uncertainty, so a story where you gathered more data until you were sure answers a different question. Reversibility as the thing that sets the bar, the check-in you schedule when you decide, and what to say about the ones that went badly.

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 confident plan built before you know anything is the failure mode, and so is refusing to answer until you have looked. The structure that handles both: a dated shape with the decision points named, one committed win, and the conditions that would change everything after day 30.

How you reported it matters more than how you found it. The internal disclosure that gets a fix instead of a defensive reaction, the four places isolation gaps hide in GPU infrastructure, and the test that keeps the fix from regressing.

Bad news delivered as a problem gets you a meeting. Delivered as a forecast with options, costs and a decision date, it gets a decision. The four-part structure, the projection that has to be defensible, and the mistake of waiting until you are certain.

Four claims that are defensible from arithmetic available today, each with the counterargument that could sink it, and what each one implies about the work. Dated to 2026, because a thesis with no date is not a prediction.