TL;DR: Answer with a thesis, not with enthusiasm. A thesis is a claim about where the hard problem currently is, stated specifically enough to be wrong: that compute is the binding constraint on progress, that the work is utilization and reliability at scale rather than model quality, that serving economics decide which capabilities reach users. Then tie it to one thing you have built, because a thesis with no personal evidence behind it is something you read. Then say why now, which for most people is a real answer about a shift they can point to, such as clusters crossing the size where failures became a design input rather than an exception. Two things sink this answer. Complimenting the company, which every candidate does and which carries no information. And describing the field as exciting, which says nothing about what you would do on a Tuesday. If you are moving in from adjacent work, name the transfer explicitly and the gap honestly, because the interviewer is already estimating both.
How to approach it
Lead with the claim. Support it with one number or one observation you can defend. Connect it to a thing you built or operated, even if that thing was smaller or in a different domain. Then say what you want to work on specifically, at the level of a problem rather than a team name. Ninety seconds is enough, and shorter is better than padded.
A strong answer
A typical situation: a candidate with six years of distributed systems experience, no GPU work, and a genuine interest in the field gets this question in the first fifteen minutes. The answer that fails is "I have been following the space and I am excited about what you are building." The answer that lands starts with a claim about the field and ends with what they built that is relevant.
The shape, with an example of each part filled in:
| Part | Filled in |
|---|---|
| The claim | "The constraint on what labs can do is compute delivered reliably, not compute purchased. A cluster that runs at 60% of its theoretical throughput is a 40% budget cut nobody voted for." |
| The evidence | "Published failure statistics for large training runs put interruptions in the range of one every few hours at sixteen thousand GPUs, which means fault tolerance is a design input, not an operational detail." |
| Your connection | "I spent three years on a storage system where the same thing was true: the interesting problems were all in what happens when a node dies mid-write, and that is the muscle I want to use here." |
| Why now | "Clusters crossed the size where this stopped being an operations problem and became an architecture problem, and that transition is the part I want to be in the room for." |
| What you want | "Specifically, checkpoint and restart paths, and the scheduling that decides what runs when capacity shrinks." |
Note what the connection row does. It does not claim GPU experience the candidate does not have. It names the transferable structure, which is the honest and stronger move, and it invites the interviewer to test it rather than to catch it. Your View on Where AI Infrastructure Is Going covers how to build a thesis that survives a follow-up, including the counterargument you should be able to state.
The "why now" half is the one candidates skip, and it is answerable without a grand narrative:
weak: "AI is transforming everything."
no claim, no date, nothing to disagree with
workable: "the problems I like moved here"
distributed systems people say this about failure at scale
kernel and compiler people say it about the arithmetic actually mattering again
hardware people say it about the memory wall being the design center
SRE people say it about a fleet where a single job spans thousands of machines
strong: the same, plus the thing that changed for YOU
a project where you hit the limit of what you could do without this skill set, or a
measurement you made that surprised you, or a system you operated that started running
GPU workloads and behaved differently
Interviewers at labs sometimes add a mission dimension to this question, and it is worth knowing the difference. Safety and Mission Rounds at the Labs covers what an infrastructure-specific answer to that looks like, which is about access control, audit, evaluation capacity and the ability to roll back, rather than a restatement of published positions.
The reversal condition: if you are interviewing at a hardware vendor or a cloud rather than a lab, the thesis that lands is different. There the interesting claim is usually about economics and utilization rather than about capability: that the industry buys capacity it cannot fill, that the gap between purchased and delivered FLOPs is where the margin is, that serving cost per million tokens decides which products exist. Same structure, different claim, and using the lab version at a neocloud reads as a candidate who did not think about who they were talking to.
What interviewers probe next
- "What would you say is wrong with your thesis?" Have the counterargument ready. A thesis you cannot argue against is one you have not tested.
- "What have you read or built recently in this area?" One specific thing, named. A paper you can summarize in two sentences beats a list.
- "What do you not know yet?" Answer it directly. The gap is visible on your resume, and naming it is worth more than hoping it goes unmentioned.
- "Why this company rather than the others?" Answer with a problem they have that you want, not with praise. Praise is uninformative and every candidate offers it.
Common mistakes
- Complimenting the company instead of making a claim, which is the most common failure in this question by a wide margin.
- A thesis with no personal evidence, which reads as repeating something absorbed from reading.
- Claiming adjacent experience as GPU experience and getting caught on the first technical follow-up.
- Skipping "why now" entirely, so the answer works equally well five years ago.
- Using a lab-shaped answer at a cloud or vendor, where the constraint that matters is economic.
Key takeaways
- Lead with a claim specific enough to be wrong, then the evidence, then your connection to it.
- Name the transferable structure honestly rather than overclaiming GPU experience.
- "Why now" is answerable from your own trajectory; it does not require a thesis about the industry.
- Have the counterargument to your own claim, because that is the first follow-up.
- Adjust the claim to the employer: capability and reliability at a lab, utilization and economics at a cloud or vendor.