Home / Tools / STAR answer checker / Tell me about a time you solved a difficult problem

Behavioral question

Tell me about a time you solved a difficult problem

Difficult should be visible: unclear cause, high cost of being wrong, or several failed attempts. They want your narrowing move. A genius leap with no steps sounds rehearsed and is hard to follow up on.

Check this example, then replace it

The box starts with one STAR answer. Read the scores, then delete it and paste a story from your own work. Scoring stays in the browser.

Question (optional) Your answer In October 2024 checkout latency spiked to 1.8 seconds for about 12% of sessions, and the obvious database graph was flat. I was responsible for finding the cause before the weekend sale. I split traffic by region, wrote a log line around the tax call, and saw that one region’s tax vendor was adding 1.2 seconds. I then cached that vendor’s rates for 10 minutes and added a timeout so a slow vendor could not hold the request. The result was p95 latency down from 1.8 seconds to 420 milliseconds, and the weekend sale ran with the timeout firing 30 times instead of stalling carts. The vendor later confirmed a partial outage. I wrote the region split and the timeout into the incident doc so the next spike started from that cut, not from the flat database graph.

Check answer Tighten with AI

85/100

Strong

About 56 seconds spoken · 141 words. Spoken time uses 150 words per minute.

Situation78

Task64

Action94

Result92

Feedback

• This has a clear STAR shape. Only keep numbers you can defend out loud.

Which sentence is which

In October 2024 checkout latency spiked to 1.8 seconds for about 12% of sessions, and the obvious database graph was flat. Situation I was responsible for finding the cause before the weekend sale. Task I split traffic by region, wrote a log line around the tax call, and saw that one region’s tax vendor was adding 1.2 seconds. Action I then cached that vendor’s rates for 10 minutes and added a timeout so a slow vendor could not hold the request. Action The result was p95 latency down from 1.8 seconds to 420 milliseconds, and the weekend sale ran with the timeout firing 30 times instead of stalling carts. Result The vendor later confirmed a partial outage. Unclear I wrote the region split and the timeout into the incident doc so the next spike started from that cut, not from the flat database graph. Action

Tightened draft

Copy

In October 2024 checkout latency spiked to 1.8 seconds for about 12% of sessions, and the obvious database graph was flat. I was responsible for finding the cause before the weekend sale. I split traffic by region, wrote a log line around the tax call, and saw that one region’s tax vendor was adding 1.2 seconds. I then cached that vendor’s rates for 10 minutes and added a timeout so a slow vendor could not hold the request. I wrote the region split and the timeout into the incident doc so the next spike started from that cut, not from the flat database graph. The result was p95 latency down from 1.8 seconds to 420 milliseconds, and the weekend sale ran with the timeout firing 30 times instead of stalling carts. The vendor later confirmed a partial outage.

Why this example holds up

The narrowing (split by region, one log line) is the part they can hire. The cache and the timeout are the actions. The milliseconds are the result.

How to answer “Tell me about a time you solved a difficult problem” with STAR

1. Situation. Set the scene in one or two sentences: when it was and what was already wrong. For example: In October 2024 checkout latency spiked to 1.8 seconds for about 12% of sessions, and the obvious database graph was flat.
2. Task. Say what you personally owned. For example: I was responsible for finding the cause before the weekend sale.
3. Action. Say what you did, in order, with I. For example: I split traffic by region, wrote a log line around the tax call, and saw that one region’s tax vendor was adding 1.2 seconds.
4. Result. End on the change, with a number you can defend. For example: The result was p95 latency down from 1.8 seconds to 420 milliseconds, and the weekend sale ran with the timeout firing 30 times instead of stalling carts.

Mistakes on this question

• A problem that was hard only because it was large. Size is not difficulty.
• Jumping to the fix with no dead end. One failed check makes the story credible.
• A result with no baseline. “It got faster” is not a result.

How to practice it

Tell the dead end in one sentence. Then the narrowing. Interviewers remember the narrowing.

FAQ

Can this be a non-technical problem?

Yes. A pricing dispute, a hiring loop, or a migration plan can be difficult. Keep the same shape: what you ruled out, what you tried, what moved.

How deep should I go on the technical detail?

One mechanism is enough unless they ask. Latency, a vendor, a cache. Save the trace for the follow-up.

Related questions

• Tell me about a time you had to learn something quickly
• Tell me about a time you dealt with ambiguity
• Tell me about a time you improved a process

Back to the STAR answer checker