Code review interview questions test whether you can explain a risk and propose a useful change. Separate a correctness problem from a style preference. A reviewer should be able to show how the change could fail, not merely say that it feels wrong.

The following is fictional pseudocode for a consequential action. It is not a payment integration guide. The purpose is to practice review feedback around retries and uncertain outcomes.

What risk do you see first?

function pay(order):
    try:
        return provider.charge(order)
    catch Timeout:
        return provider.charge(order)

A timeout tells this caller that it did not receive a result in time. It does not prove the provider did nothing. A second charge could duplicate the action unless the provider contract and application design prevent that.

The highest-priority comment should address that risk before naming or indentation. Explain the failure sequence: the first action completes remotely, its response is lost, and the caller repeats it.

How can the comment be specific?

Illustrative review comment: “Could we handle the uncertain first outcome before issuing another charge? A timeout may happen after the provider completes the action. Please check the provider's idempotency contract and add a test for completion with a lost response.”

This comment names the concern, gives a concrete scenario and asks for evidence. It does not insult the author or assert that all providers behave identically. A supported idempotency mechanism must follow that provider's real rules.

What if the author disagrees?

Ask for the relevant contract or existing guarantee. If the application already supplies a stable operation key and the provider deduplicates correctly, update your assessment. Reviewing well includes accepting evidence that removes the concern.

If uncertainty remains, suggest a small test or a focused discussion with the responsible owner. Do not turn a review thread into a competition over who can repeat their opinion longest.

How do you separate required changes from suggestions?

  • Blocking: a verified correctness, security or data-integrity risk.
  • Question: a behavior whose intent or guarantee is unclear.
  • Suggestion: a maintainability improvement worth considering.
  • Preference: a style choice already covered, or not covered, by team conventions.

Use the team's actual review labels rather than inventing a parallel process. When a formatter or lint rule already handles style, let the tool do that work.

What test would you request?

A useful test simulates the uncertain outcome, not just a failure before any remote work begins. Also check a confirmed success, a confirmed rejection and the permitted recovery path. Assert the externally meaningful action count under the stated guarantee.

A mock configured to throw immediately cannot prove the lost-response case. Explain what the fake models and what still needs a provider integration test.

Practice a balanced answer

Review a small change aloud. Give one important comment, one question and one optional improvement. For each, identify the code or contract that supports it. Then ask what evidence would make you change your mind. This keeps the answer practical, respectful and grounded in behavior.

References and next practice

careerservices.fas.harvard.edu — career · developer.mozilla.org — http

Browse interview topics · Practise a question in Interview Challenge · How to Prepare for an Interview