Synthetic sample / No candidate data

See what the reviewer receives.

Choose a role. Trace a finding to the work, inspect what the checks establish, and find a useful follow-up question. All four briefs use fictional examples; they contain no candidate data.

SeeTheWork / Evidence brief

Software engineering

Synthetic sample

The duplicate write is addressed. Monitoring needs a follow-up.

The sample connects a reproduced duplicate write to a change at the persistence boundary and a regression check. The operational monitoring decision remains open. [04]

Diagnoses faults systematically

Strong evidence

[01][02]

Verifies the fix against regressions

Strong evidence

[03]

Explains operational trade-offs

Partial evidence

[04]

All excerpts below are illustrative, including filenames and check results. They explain the review method and contain no real candidate data.

  1. [01]

    Regression test

    Illustrative

    Reproduce the duplicate write.

    tests/test_event_processor.py

    deliver(event_id="evt-014")
    deliver(event_id="evt-014")
    assert count_rows(event_id="evt-014") == 1
    
    # Before the fix: expected 1 row; found 2.
    What it supports
    The test expresses the failure as an observable result: delivering the same event twice must create only one record.
    What remains open
    This excerpt covers repeated delivery. It does not establish behavior under every concurrent workload.
    Back to competency evidence
  2. [02]

    Change excerpt

    Illustrative

    Make retries safe at the write boundary.

    event_processor.py · pseudocode diff

    - retry(() => insert(payload))
    + retry(() => insert_once(event.id, payload))
    
    # insert_once uses a unique event ID at persistence.
    What it supports
    The change places duplicate protection where the record is written, so a retry can reuse the same event identity.
    What remains open
    This simplified excerpt illustrates the approach. A reviewer would inspect the full implementation and transaction behavior.
    Back to competency evidence
  3. [03]

    Check results

    Illustrative

    Verify the change against the task checks.

    Task check summary · illustrative output

    PASS  duplicate delivery
    PASS  retry after timeout
    PASS  valid event
    PASS  invalid payload
    PASS  empty batch
    PASS  ordered batch
    PASS  persistence failure
    PASS  existing behavior
    
    8 / 8 passed
    What it supports
    The sample distinguishes the reproduced failure from the other task checks, making the scope of verification visible.
    What remains open
    Passing these checks supports the scoped task. It does not establish production readiness or overall job performance.
    Back to competency evidence
  4. [04]

    Handoff note

    Illustrative

    Resolve the open question with targeted follow-up.

    Candidate explanation · illustrative excerpt

    “I bounded retries to avoid an endless loop.
    I would monitor retry volume after deployment.”
    
    Not specified: alert threshold or escalation condition.
    What it supports
    The explanation identifies an operational concern, but gives the reviewer insufficient evidence about the monitoring decision.
    What remains open
    Missing detail is a follow-up question. It is not proof that the candidate cannot make the decision.
    Back to competency evidence

How would you choose and monitor the retry threshold in production?

Evidence for human review
Not an automated verdict

What would evidence like this help your team understand about its next hire?