What do interviewers evaluate in Run Toward the Fire questions?

Interviewers listen for signals like: When you saw the ownerless problem, did you move toward it by default - or file it away and route around? Did you take ownership visibly (telling, not asking-and-waiting), rather than either seeking permission slowly or acting in the shadows?

gitGood.dev

StripeAdvanced Premium

High-Agency Ownership - Run Toward the Fire (Stripe Culture)

Stripe prizes engineers who move toward the ugliest unowned problem without being asked - and stay until it's actually fixed. Interviewers test for agency, not heroics.

About this theme

Stripe's culture writing is full of agency language: optimism paired with urgency, 'we haven't won yet,' and the recruiting-page archetype of people who run toward the fire rather than away from it. In an infrastructure company where the product moves money, fires are not hypothetical - a subtle reconciliation bug or a decaying webhook queue is someone's revenue - and the org can't function if problems have to be assigned before anyone touches them. The trait being screened is high agency: when you see something broken, ambiguous, or ownerless, your default is to move toward it, take responsibility for the outcome, and pull in the right people - rather than filing a ticket into the void, waiting for an owner to be declared, or quietly routing around it. The interview probes distinguish agency from two look-alikes. The first is heroics: the firefighter who parachutes in, patches the symptom, collects the credit, and leaves the root cause and the cleanup for others - interviewers ask what happened after the fire specifically to catch this. The second is chaos: high agency without judgment means grabbing problems that weren't yours to grab, bypassing owners who existed, or burning out on every alarm equally. Strong answers show a deliberate arc - saw the smoke, verified nobody owned it, took ownership visibly, fixed the cause and not just the symptom, then did the unglamorous ending (the backfill, the postmortem, the monitoring, the handoff) that makes the fire not recur. The very strongest show the fire was outside the candidate's job description, and that they told people they were taking it rather than asking permission slowly or acting invisibly.

What interviewers are evaluating

→When you saw the ownerless problem, did you move toward it by default - or file it away and route around?
→Did you take ownership visibly (telling, not asking-and-waiting), rather than either seeking permission slowly or acting in the shadows?
→Did you fix the cause or just the symptom - and did you do the unglamorous ending (backfill, postmortem, monitoring, handoff)?
→Did you check for an existing owner and pull in the right people, or bulldoze past them?
→Was it actually outside your lane - agency inside your assigned scope is just doing your job?
→Do you pick fires with judgment, or does every alarm get equal adrenaline?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a time you took on a problem nobody owned.
?Describe running toward a fire - a production issue or mess others were avoiding. What did you do?
?Tell me about the most broken thing you've encountered at a job. What did you do about it?
?Describe a time you acted without waiting for permission. How did you decide that was right?
?Tell me about a fire you fixed where the fix didn't stick - or what you did to make sure it stuck.
?Give an example of raising your hand for something ambiguous and thankless.
?Tell me about a time you decided NOT to jump on a problem. Why?

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: adopting the webhook queue nobody owned

Prompt: "Tell me about a time you took on a problem nobody owned."

Situation: At a payments-adjacent company, our outbound webhook system - the thing that told merchant systems 'this order was paid' - had been orphaned by two reorgs. It was degrading slowly rather than dramatically: delivery p99 had crept from 40 seconds to 25 minutes over six months, and merchants had started polling our API as a workaround, which was in turn degrading API latency for everyone. Three teams were affected; none owned it. I was on the checkout team, which didn't own it either. It surfaced in a support escalation I happened to be looped into, where a merchant said they'd stopped trusting our webhooks entirely.
Task: A merchant losing trust in event delivery is a fire in slow motion for an infrastructure company. Someone needed to own it end to end - diagnosis, fix, and a durable answer to 'who owns this system' - and the honest answer was that if I didn't take it, the next reorg would inherit it worse.
Action: I checked the ownership question first - asked my EM and the two adjacent EMs whether anyone had claim on the system; the answer was a round of 'not us.' So I took it visibly rather than quietly: I posted in the shared engineering channel that I was taking point on webhook reliability for the next two weeks, named the merchant-trust symptom, and asked for a pair from the infra team. That message mattered - it flushed out context from an engineer who'd touched the system two years prior and told me about a retry design flaw I'd have taken days to find: failed deliveries requeued at the tail with the same priority as fresh events, so one slow merchant endpoint could clog the queue for everyone. The fix had a fast half and a slow half, and I did both. Fast: I shipped per-destination delivery queues with exponential backoff and a circuit breaker for consistently-failing endpoints - that was four days with the infra pair. Slow and unglamorous: I backfilled six months of missing delivery metrics so we could actually see the system, wrote the runbook that didn't exist, added paging alerts on delivery p99, ran a postmortem-style review on how the system got orphaned, and - the part I'd argue mattered most - drove the ownership question to a real answer, getting the system formally adopted by the infra team with a named owner, with my writeup as the handoff document. I also went back to the escalated merchant personally with what we'd found and fixed.
Result: Delivery p99 went from 25 minutes to under 90 seconds and stayed there; the merchant who'd escalated turned off their polling workaround within a month, and API load from polling dropped measurably. The system has had a named owner since. Six months later the circuit-breaker pattern caught a genuinely down merchant endpoint and isolated it automatically - the fire I'd fixed didn't just stay out, the system now handled that class of fire itself. My manager's feedback that cycle was that the two weeks off-roadmap were the highest-leverage thing anyone on the team did that quarter.

Why this works

What makes this strong: (1) the full agency arc is present - smoke noticed, ownership verified as vacant, then taken visibly ('I'm taking point') rather than by silent squatting or slow permission-seeking, which is also what surfaced the crucial context; (2) the fix distinguishes symptom from cause and includes the unglamorous ending interviewers probe for - metrics backfill, runbook, alerts, postmortem, and a permanent owner, which is what separates agency from heroics; (3) judgment is visible throughout: a bounded two-week commitment, a pulled-in expert rather than solo bulldozing, and closure with the affected merchant.

WEAK

Weak: the hero who left the ashes

Prompt: "Describe running toward a fire - a production issue or mess others were avoiding. What did you do?"

Situation: Our data export feature went down during a big customer's onboarding week and the team that owned it was dragging their feet on it.
Task: Everyone was being slow and cautious, so I decided to just handle it myself - I'm the kind of person who runs at problems.
Action: I didn't have context on that codebase but I dove in anyway. I found what looked like the problem, pushed a hotfix directly - I skipped their review process because the customer was waiting and their team was too slow - and got the export working again that night. The owning team was annoyed about the process thing and claimed my fix papered over a deeper issue with the job scheduler, but the customer was unblocked, which is what mattered. I moved back to my own work the next day and let them take it from there.
Result: The customer finished onboarding. I heard the export thing broke again a few weeks later, but by then the owning team was on it, so it was in the right hands. I got a shout-out from sales for the save.

Why this is weak

Why weak: (1) this is heroics, not agency - symptom patched, credit collected, exit the next morning, with the recurrence weeks later treated as someone else's problem; the 'what happened after?' follow-up demolishes this story; (2) the problem had an owner, and the candidate bulldozed them - skipping review on an unfamiliar codebase and dismissing the owning team's (correct) warning about the scheduler shows agency without judgment, which fires cause rather than fix; (3) 'I'm the kind of person who runs at problems' is self-description in place of evidence, and the only outcomes cited are a sales shout-out and an unbroken streak of missing the point.

Common pitfalls

×Confusing heroics with agency - patching the symptom, taking the credit, and leaving before the backfill, postmortem, and handoff.
×Grabbing problems that had owners, or bypassing review and process in the name of urgency - agency without judgment reads as chaos.
×Taking ownership invisibly. Quietly squatting on a problem denies others context and denies you help; strong agency announces itself.
×Telling a story that was actually your job. Fires inside your assigned scope demonstrate diligence, not agency.
×No 'did it stick?' evidence - if you can't say what prevented recurrence, interviewers assume nothing did.
×Equal adrenaline for every alarm. Never being able to name a fire you deliberately didn't fight suggests poor judgment, not high agency.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→The killer follow-up is 'what happened after the fire?' - prepare the unglamorous ending (monitoring, runbook, owner, recurrence data) before the interview.
→If asked 'whose job was it?', the strong answer shows you checked - and that the honest answer was 'nobody's,' which is why you took it.
→If asked 'how did people know you'd taken it?', point to the visible claim - the channel post, the incident role, the named commitment.
→If asked 'what if you'd been wrong to jump in?', show the bounded bet: timeboxed commitment, experts pulled in, reversible first moves.
→If asked 'when do you NOT run toward a fire?', have a real example - a fire that had a capable owner, or one that was less important than your commitment. Judgment completes the signal.

Related behavioral themes

Ownership

Amazon LP

Tested at every level, scored harder at senior. Did you take responsibility for outcomes - or just for tasks?

FREE

Bias for Action

Amazon LP

Speed matters. But the principle is reversible-vs-irreversible reasoning, not 'I work fast.' Get this distinction wrong and the answer reads as reckless.

Missed Deadline / Incident

General

The honesty test. Can you own a missed commitment or production incident specifically and without flinching - or do you blame the team, the requirements, or the on-call rotation?

Companies that test this theme

Stripe

Backend Engineer

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →

StripeAdvanced Premium

High-Agency Ownership - Run Toward the Fire (Stripe Culture)

Stripe prizes engineers who move toward the ugliest unowned problem without being asked - and stay until it's actually fixed. Interviewers test for agency, not heroics.

About this theme

What interviewers are evaluating

→When you saw the ownerless problem, did you move toward it by default - or file it away and route around?
→Did you take ownership visibly (telling, not asking-and-waiting), rather than either seeking permission slowly or acting in the shadows?
→Did you fix the cause or just the symptom - and did you do the unglamorous ending (backfill, postmortem, monitoring, handoff)?
→Did you check for an existing owner and pull in the right people, or bulldoze past them?
→Was it actually outside your lane - agency inside your assigned scope is just doing your job?
→Do you pick fires with judgment, or does every alarm get equal adrenaline?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a time you took on a problem nobody owned.
?Describe running toward a fire - a production issue or mess others were avoiding. What did you do?
?Tell me about the most broken thing you've encountered at a job. What did you do about it?
?Describe a time you acted without waiting for permission. How did you decide that was right?
?Tell me about a fire you fixed where the fix didn't stick - or what you did to make sure it stuck.
?Give an example of raising your hand for something ambiguous and thankless.
?Tell me about a time you decided NOT to jump on a problem. Why?

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: adopting the webhook queue nobody owned

Prompt: "Tell me about a time you took on a problem nobody owned."

Situation: At a payments-adjacent company, our outbound webhook system - the thing that told merchant systems 'this order was paid' - had been orphaned by two reorgs. It was degrading slowly rather than dramatically: delivery p99 had crept from 40 seconds to 25 minutes over six months, and merchants had started polling our API as a workaround, which was in turn degrading API latency for everyone. Three teams were affected; none owned it. I was on the checkout team, which didn't own it either. It surfaced in a support escalation I happened to be looped into, where a merchant said they'd stopped trusting our webhooks entirely.
Task: A merchant losing trust in event delivery is a fire in slow motion for an infrastructure company. Someone needed to own it end to end - diagnosis, fix, and a durable answer to 'who owns this system' - and the honest answer was that if I didn't take it, the next reorg would inherit it worse.
Action: I checked the ownership question first - asked my EM and the two adjacent EMs whether anyone had claim on the system; the answer was a round of 'not us.' So I took it visibly rather than quietly: I posted in the shared engineering channel that I was taking point on webhook reliability for the next two weeks, named the merchant-trust symptom, and asked for a pair from the infra team. That message mattered - it flushed out context from an engineer who'd touched the system two years prior and told me about a retry design flaw I'd have taken days to find: failed deliveries requeued at the tail with the same priority as fresh events, so one slow merchant endpoint could clog the queue for everyone. The fix had a fast half and a slow half, and I did both. Fast: I shipped per-destination delivery queues with exponential backoff and a circuit breaker for consistently-failing endpoints - that was four days with the infra pair. Slow and unglamorous: I backfilled six months of missing delivery metrics so we could actually see the system, wrote the runbook that didn't exist, added paging alerts on delivery p99, ran a postmortem-style review on how the system got orphaned, and - the part I'd argue mattered most - drove the ownership question to a real answer, getting the system formally adopted by the infra team with a named owner, with my writeup as the handoff document. I also went back to the escalated merchant personally with what we'd found and fixed.
Result: Delivery p99 went from 25 minutes to under 90 seconds and stayed there; the merchant who'd escalated turned off their polling workaround within a month, and API load from polling dropped measurably. The system has had a named owner since. Six months later the circuit-breaker pattern caught a genuinely down merchant endpoint and isolated it automatically - the fire I'd fixed didn't just stay out, the system now handled that class of fire itself. My manager's feedback that cycle was that the two weeks off-roadmap were the highest-leverage thing anyone on the team did that quarter.

Why this works

WEAK

Weak: the hero who left the ashes

Prompt: "Describe running toward a fire - a production issue or mess others were avoiding. What did you do?"

Situation: Our data export feature went down during a big customer's onboarding week and the team that owned it was dragging their feet on it.
Task: Everyone was being slow and cautious, so I decided to just handle it myself - I'm the kind of person who runs at problems.
Action: I didn't have context on that codebase but I dove in anyway. I found what looked like the problem, pushed a hotfix directly - I skipped their review process because the customer was waiting and their team was too slow - and got the export working again that night. The owning team was annoyed about the process thing and claimed my fix papered over a deeper issue with the job scheduler, but the customer was unblocked, which is what mattered. I moved back to my own work the next day and let them take it from there.
Result: The customer finished onboarding. I heard the export thing broke again a few weeks later, but by then the owning team was on it, so it was in the right hands. I got a shout-out from sales for the save.

Why this is weak

Common pitfalls

×Confusing heroics with agency - patching the symptom, taking the credit, and leaving before the backfill, postmortem, and handoff.
×Grabbing problems that had owners, or bypassing review and process in the name of urgency - agency without judgment reads as chaos.
×Taking ownership invisibly. Quietly squatting on a problem denies others context and denies you help; strong agency announces itself.
×Telling a story that was actually your job. Fires inside your assigned scope demonstrate diligence, not agency.
×No 'did it stick?' evidence - if you can't say what prevented recurrence, interviewers assume nothing did.
×Equal adrenaline for every alarm. Never being able to name a fire you deliberately didn't fight suggests poor judgment, not high agency.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→The killer follow-up is 'what happened after the fire?' - prepare the unglamorous ending (monitoring, runbook, owner, recurrence data) before the interview.
→If asked 'whose job was it?', the strong answer shows you checked - and that the honest answer was 'nobody's,' which is why you took it.
→If asked 'how did people know you'd taken it?', point to the visible claim - the channel post, the incident role, the named commitment.
→If asked 'what if you'd been wrong to jump in?', show the bounded bet: timeboxed commitment, experts pulled in, reversible first moves.
→If asked 'when do you NOT run toward a fire?', have a real example - a fire that had a capable owner, or one that was less important than your commitment. Judgment completes the signal.

Related behavioral themes

Ownership

Amazon LP

Tested at every level, scored harder at senior. Did you take responsibility for outcomes - or just for tasks?

FREE

Bias for Action

Amazon LP

Speed matters. But the principle is reversible-vs-irreversible reasoning, not 'I work fast.' Get this distinction wrong and the answer reads as reckless.

Missed Deadline / Incident

General

The honesty test. Can you own a missed commitment or production incident specifically and without flinching - or do you blame the team, the requirements, or the on-call rotation?

Companies that test this theme

Stripe

Backend Engineer

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →