Question 3Coding
How do you keep quality high when you ship fast at a customer site?
Speed is the job, but broken code at a customer is costly. They want your guardrails.
“Python Engineering: Strong production Python; proficiency in at least one additional language (Go, TypeScript, or Java). Architects robust agentic system components and writes code others can extend.”Senior Engineer, Forward Deployment · T-Mobile
The answerFour steps
- 1
Tests for the parts that touch customer data or money
Say it like this
“The rule I don't break: anything that writes to their data or touches money has tests. The pricing code had 30 tests. The internal admin page had none, on purpose.”
Why it scores
Says where tests go and where they don't. Judgment, not a blanket rule.
- 2
Code review even when it's fast, ideally by someone on the product team
Say it like this
“Every change got a review, even a 15-minute one, and I asked an engineer from our product team to review the integration code, since they'd own it later.”
Why it scores
Review by the future owner. FDE code the product team can't read becomes a problem.
- 3
Feature flags and an easy way to roll back
Say it like this
“New behaviour went out behind a flag. When a pricing change misbehaved on day nine, I switched it off in a minute instead of redeploying.”
Why it scores
A real rollback with a time on it. Flags are what make speed safe.
- 4
Clean up the shortcuts in the next release, and write them down
Say it like this
“I kept a short list of shortcuts in the repo, and we cleared most of it the week after the pilot.”
Why it scores
Treats shortcuts as written-down debt, not something to forget.
StrongAll together
About a minute, out loud. The marked parts are the four steps; hover one to find it above.
On a three-week pilot for a freight company, I shipped most days. The rule I don't break: anything that writes to their data or touches money has tests. The pricing code had 30 tests. The internal admin page had none, on purpose.1 Every change got a review, even a 15-minute one, and I asked an engineer from our product team to review the integration code, since they'd own it later.2 New behaviour went out behind a flag. When a pricing change misbehaved on day nine, I switched it off in a minute instead of redeploying.3 I kept a short list of shortcuts in the repo, and we cleared most of it the week after the pilot.4
WeakThe answer that fails
Sounds fine. Common. Scores low.
“I write unit tests for everything, use CI/CD, and follow best practices like code review and linting, so quality stays high even when we move fast.”
Interviewer's note
“Tests for everything” isn't true on a pilot. No trade-offs, no rollback, nothing specific.
PracticeTwo minutes, then they push back
Your turn
How do you keep quality high when you ship fast at a customer site?
Answer like you're in the room: about two minutes, no notes. Say it out loud, even alone. It feels different from thinking it. Then check your answer against what interviewers score.