# Coding assessments: working checklist

Companion to https://lunaprompts.com/blog/coding-assessment-design-guide

LunaPrompts Editorial. Original illustrative exercise.

## Define the workflow

- Role or campaign:
- Owner:
- Decision this workflow should support:
- Candidate instructions and support route:

## Worked example: Debug duplicate order events

Supply a small function that processes order events and updates a total. Give each event an identifier. State that receiving the same event twice should not count it twice, then provide an implementation that violates that requirement.

Ask the candidate to reproduce the defect, correct it, and show a check that fails before the change and succeeds afterward. This makes the review concrete: the team can inspect the failing input, the implementation, and the test.

For a junior role, a correct local solution and clear explanation may cover the intended scope. For a more experienced role, ask what happens when the process restarts or two workers handle the same event. Make any extra requirement explicit; do not silently score a small in-memory exercise as if the candidate had been asked to build a distributed service.

If AI tools are allowed, examine how the candidate reviews the suggested fix. If they are not allowed, state that before the task. In either case, ask why the implementation prevents the observed failure and what it does not yet guarantee. That discussion connects programming fundamentals to ownership of the result.

## Review checklist

- [ ] Reproduce: A failing input that demonstrates the defect
  Evidence or open question:
- [ ] Repair: A change linked to the cause
  Evidence or open question:
- [ ] Regress: A check that guards against recurrence
  Evidence or open question:
- [ ] Explain: The scope and limits of the solution
  Evidence or open question:

## Working session

Choose an ordinary bug from a sanitized example project. Write the observable failure, the expected behavior, and one follow-up matched to the role level.

## Avoid this mistake

Hidden requirements create noise. Hidden test inputs can check disclosed requirements, but should not introduce a different task after submission.

## Record the next step

- Observed evidence:
- What remains uncertain:
- Person responsible:
- Next action and date:

Keep candidate examples anonymous when sharing this worksheet.