The final timing edit was accepted without a recorded test run afterward. Rechecking that change would make the outcome easier to assess before submission.
Interview completedSeptember 16, 2026
Repair Retry Safety in the HTTP Client
82out of 100
Score breakdown
Points earned in each evaluation category.
Implementation review
AI static reviewA review of your submitted code. Suggested changes and examples have not been executed; this feedback does not change your score.
The retry policy separates request safety from response classification, and the backoff is deterministic with injected jitter. The stopping logic still needs a consistent rule when cancellation and the deadline coincide.
Keep these choices
- The repeatable() helper makes the method and idempotency-key rule easy to inspect independently of the retry loop.
- Injecting jitter into backoff() lets tests check the exact delay without randomness.
What to improve
Cancellation loses a tie with the deadlinesrc/stopping.ts:2–3
From your submission
if (now >= deadline) return 'deadline'; if (cancelAt !== undefined && now >= cancelAt) return 'cancelled';- Why it matters
- When now, deadline, and cancelAt are equal, the first branch returns deadline. The contract gives cancellation precedence at that exact boundary, so the function reports the wrong stopping reason.
- Suggested change
- Compare the stopping timestamps first. Choose the earlier timestamp, prefer cancellation when they are equal, and use that same decision for both transport attempts and backoff sleeps.
- How to verify
- Add deterministic cases for cancelAt before, equal to, and after deadline. For the equal case, assert cancelled and confirm that no new transport attempt starts.
Name the method set for the retry rule it representssrc/policy.ts:1
From your submission
const SAFE = new Set(['GET', 'HEAD', 'OPTIONS', 'PUT', 'DELETE']);- Why it matters
- PUT and DELETE are repeatable under this policy, but they can change server state. Calling the set SAFE blurs that distinction for someone extending the policy.
- Suggested change
- Rename the set to IDEMPOTENT_METHODS or REPEATABLE_METHODS and keep the keyed-request exception in repeatable().
- How to verify
- Keep the method and key matrix passing: an unkeyed POST must remain non-repeatable while the listed methods remain repeatable.
One strong approach
A suggested approach to compare with your solution. Other implementations can satisfy the same requirements.
Treat retrying as a small state machine with one absolute deadline and a shared stopping rule. Keep request classification and delay calculation separate from timing transitions.
- Classify the request and response before deciding whether another attempt is allowed.
- Compute the first stopping timestamp from cancellation and the absolute deadline; use cancellation when the two timestamps tie.
- Check the stopping boundary before starting an attempt and across every wait. Record a delay only after its sleep completes.
- Advance the retry counter only when an attempt starts, and cap transport calls at maxRetries + 1.
- Tradeoffs
- A shared stopping helper adds a small abstraction, but keeps timing rules consistent across attempts and sleeps. Work is linear in the number of attempts, with constant timing state; retaining an attempt history uses linear space.
Illustrative code · not executed
const stoppedAt = Math.min(deadline, cancelAt ?? Infinity);
if (now >= stoppedAt) {
return cancelAt !== undefined && cancelAt <= deadline
? 'cancelled'
: 'deadline';
}What a strong solution does
These are the behaviors the evaluation looked for. Several implementations satisfy them.
- Classify retryability by method, key, and status.
- Track one absolute deadline and cancellation across attempt and sleep phases.
- Use exponential backoff with deterministic injected jitter.
- Bound attempts to maxRetries + 1.
Supplemental AI feedback
Separate from your scoreAn optional AI review of your saved code and session evidence. Your scores come from the recorded tests and scoring rules; this commentary does not change them.
Strengths noted by AI
- Names the retry classification rule before editing the policy module.
- Leaves the transport untouched, so the injected clock stays testable.
Practice opportunities noted by AI
- State the cancellation tie-break explicitly before accepting timing changes.
- Ask for a focused regression case when the assistant proposes changing the retry loop.
AI observations
You challenged the suggestion to retry every method and explained why a POST needs an idempotency key before accepting a replacement patch.
AI interviewer feedback
Feedback on your explanations and technical decisions. This does not change your code score.
Reviewed 9 of 11 candidate answers across the full transcript.
Interview summary
You framed retry safety as a property of the request rather than the response, then held that framing while the assistant argued for a uniform retry loop.
“A 503 tells me the server failed, not that resending is safe. The method and the idempotency key decide that.”
Evidence from your answer
What you explained well
You separated the deadline from the retry budget and explained why both need to be checked before a sleep starts.
“If the sleep would end after the deadline, there is no point starting it. I check the clock first and return the deadline error.”
Evidence from your answer
What to practice
Your answer on cancellation stopped at “whichever comes first” without naming the tie-break the specification requires.
“Cancellation and the deadline both stop the request, so I take the smaller one.”
Evidence from your answer
Interview transcript (4 messages)
Voice answers appear as text. Audio recordings and camera images are not saved.
Which requests in this client are safe to retry, and how do you decide?
A 503 tells me the server failed, not that resending is safe. The method and the idempotency key decide that.
The assistant suggested restarting the timeout per attempt. What happened?
That turns a 2 second budget into 2 seconds per attempt. I kept one absolute deadline and measured the sleeps against it.
Interviewer feedback
Strong instinct on idempotency, and you pushed back on the assistant with a reason rather than a preference. Next time, write the failing test before you accept the timing change.
Practice patterns over time
Compare the latest five observations with the five before them. Counts show the evidence available; a missing earlier period stays blank.
Skills practiced
Average interview score for problems tagged with this skill. These are practice outcomes, not isolated skill assessments.
| Problem skill | Recent | Earlier | Change |
|---|---|---|---|
| Retries | 82/1005 observations | 74/1005 earlier | +8 points |
| Deadlines | 77/1004 observations | 71/1003 earlier | +6 points |
| Idempotency | 80/1002 observations | —No earlier observations | — |
AI mistake responses
Percentage of calibrated mistakes rejected or corrected with verification. Historical outcomes with missing or low confidence are excluded. A rejection alone does not prove its reasoning was correct.
| Mistake type | Recent | Earlier | Change |
|---|---|---|---|
| Retry non-idempotent operation | 80%5 observations | 60%5 earlier | +20 pp |
| Ignore deadline | 67%3 observations | 50%4 earlier | +17 pp |
Recommended problems
Focus your next session on the areas your recent work can strengthen.
Caching
Medium
Expire Entries in the TTL Cache
Keep reads honest when entries expire, capacity is zero, and values are falsy.
ExpiryEvictionBoundaries
Exercises the exact-boundary reasoning your deadline answer skipped.
Reliability
Hard
Hold the Line in the Token Bucket Limiter
Refill fairly under bursts without letting a slow caller starve the queue.
Rate limitingClocksFairness
More practice with a shared clock and one budget across operations.
Get your own interview report
Submit a problem for evaluation to receive scores and specific feedback.