Practice interview follow-up questions. Go beyond the first answer.

The direct answer

Answer the follow-up before retelling the story

Pause, identify what the new question asks, and give a direct answer. Then add the specific evidence or reasoning that supports it. If a constraint changes, say which part of the original answer still holds and which part needs revision.

“Why did you choose that?” needs a decision and an alternative. “How do you know?” needs evidence and its limits. “What if the input doubles?” needs a new analysis. Repeating your opening answer can leave all three unanswered.

1. Answer in one sentence first. “I chose the smaller rollout because we could reverse it before the next workshop.”
2. Supply one piece of support. Name an action, example, invariant, or observable result rather than adding adjectives.
3. State the limit or change. “That check covered one workshop; it does not prove the process works for every event.”

Use these as rehearsal moves, not a rigid script. Clarify an ambiguous question before choosing which evidence to give.

Chain 01 · Ownership and evidence

A workshop handoff that needed repair

Opening prompt. Tell me about a time you improved a process that other people relied on.

Fictional scenario. You coordinated a volunteer workshop with 12 registrants and two facilitators. The registration form and facilitator sheet had different start times. Four registrants emailed for clarification. You corrected both documents, sent one confirmed time to all 12 registrants, and asked each facilitator to acknowledge the final sheet. One registrant still arrived late; you did not learn why.

Your first attempt. Give a 90-second answer that separates your work from the facilitators’ work. Use Situation, Task, Action, and Result (STAR) to organize it, then take the three questions below without restarting the whole story.

Take these follow-ups before opening the answers.

1. What did you personally do?
2. How do you know your change helped?
3. What would you change next time?

Transfer exercise

Replace the workshop with a true event from work, study, volunteering, or a personal project. Write one thing you directly observed and one thing you do not know. Take the follow-up “What was someone else’s contribution?” without making your own role smaller or larger than it was.

If you need an opening story, use the STAR story builder or the behavioral question practice set. Keep private names and confidential details out of your practice notes.

Chain 02 · A changing contract

Find the longest nondecreasing run

Opening prompt. Given a list of integers, return the length of its longest contiguous nondecreasing run. Equal neighboring values belong to the same run. Return 0 for an empty list and leave the input unchanged. For [1, 2, 2, 0, 4], return 3.

Your first attempt. Explain a one-pass approach before coding. Define n as the list length. Assume constant-cost integer comparison. After a correct attempt, take the follow-ups about equality, streaming, and returning positions.

Take these follow-ups before opening the answers.

1. What if the run must be strictly increasing?
2. What if the data arrives in chunks?
3. What if I want the run’s start and end?

def longest_run(values):
    best = current = 0
    previous = None
    for value in values:
        if previous is None or value < previous:
            current = 1
        else:
            current += 1
        best = max(best, current)
        previous = value
    return best

assert longest_run([]) == 0
assert longest_run([5]) == 1
assert longest_run([5, 3, 1]) == 1
assert longest_run([1, 2, 2, 0, 4]) == 3
assert longest_run([-3, -3, -1]) == 3

Transfer exercise

Implement the position-returning variant yourself. Check an empty list, one element, all equal values, a strictly decreasing list, and two equal-length best runs. Then explain why the best-pair update uses a strict comparison. Use the complexity practice drills to rehearse the difference between returning indices and copying values.

Chain 03 · Failure and tradeoffs

A document-preview queue that retries work

Opening prompt. Design a service that turns uploaded documents into previews. A user should see the job’s status and eventually fetch the preview. Assume a durable object store, a jobs database, workers, and a queue that may deliver a job more than once. This is an illustrative practice system, not ClawPad’s architecture.

Your first attempt. Trace an upload through a durable job record, queued processing, stored preview, and completed status. State how an accepted job eventually reaches the queue. One option is to write the job and an outbox record in one database transaction, then have a dispatcher retry sending the outbox record. An outbox is a durable list of messages still to send. Treat duplicate sends as normal.

Take these follow-ups before opening the answers.

1. A worker finishes, then crashes before acknowledging the message. What happens?
2. The user deletes the document while a worker is running. What changes?
3. The queue keeps growing. Do you add more workers?

Transfer exercise

Draw the request path, then mark three crash points: before enqueue, after writing a preview, and after cancellation. For each point, identify the durable fact a retry reads and the update that prevents an invalid completion. Explain one cost of your design, such as extra database writes or delayed cleanup.

Use the system-design practice hub for a longer design exercise, and the diagram walkthrough to rehearse narrating a request and its failure path.

A 25-minute practice session

1. Minutes 0–3. Pick one chain. Read only its scenario and opening prompt. Write down the facts you are allowed to use.
2. Minutes 3–7. Give the opening answer. For coding, use this time to explain and sketch the approach; a full implementation can be a separate session.
3. Minutes 7–16. Have a partner ask the three follow-ups, or read the question lists above the closed disclosures. Use three minutes per question to answer and explain one concrete example.
4. Minutes 16–21. Compare your reasoning with the worked responses. Use the rubric below to choose one repair.
5. Minutes 21–25. Answer the weakest follow-up again with a changed fact, input, or failure condition. Save one sentence describing the improvement.

The time limits and rubric are editorial rehearsal suggestions, not validated hiring scores. A solo reader can answer each visible question before opening the worked responses. Recording is optional; a short written diagnosis also works.

Directness

Did my first sentence answer the new question? Mark independent, needed a prompt, or not yet.

Support

Did I supply a specific action, counterexample, count, or invariant? Record the evidence beside the mark.

Adaptation

Did I explain what the new constraint changes, including tests or failure handling?

Honesty

Did I separate observed facts, hypothetical assumptions, and what I do not know?

Continue with timed coding practice, a structured AI mock session, or another topic in the practice library. Make the first attempt unaided and follow the organizer’s rules in any real assessment.

Sources and editorial method

All prompts, sample answers, scenarios, code, and the rubric were written for this guide. The workshop evidence and system capacity figures are fictional. The Python example and boundary cases were executed locally; a small test set is not a substitute for the invariant explained above.

Amazon SQS’s at-least-once delivery documentation explains that standard queue messages can reappear and recommends processing that tolerates duplicates. It supports the duplicate-delivery premise. The proposed outbox, cancellation, and worker-claim design is our illustrative exercise, not an AWS architecture guarantee.

Reference checked October 12, 2026. These exercises teach practice skills; they do not predict an employer’s questions or hiring decision.

Common questions