What you need to know
Getting the result you want from Claude Code is usually a short series of refinements. The exam tests four techniques and when each fits.
1. Concrete input and output examples
When a prose description ("normalise the phone numbers") produces inconsistent results, two or three concrete examples remove the ambiguity faster than more prose:
Input: "(020) 7946 0958" -> Output: "+442079460958"
Input: "07700 900123" -> Output: "+447700900123"
Input: "+44 20 7946 0958" -> Output: "+442079460958"The same applies to edge cases: to fix crashes on null values in a migration script, give specific test cases with sample input containing nulls and the expected output.
2. Test-driven iteration
Write the test suite first: expected behaviour, edge cases, and any performance requirement. Then let Claude implement, run the tests, and share the failures to guide the next round. Tests give Claude an objective way to verify its own work, so each iteration converges instead of drifting.
3. The interview pattern
In an unfamiliar domain you may not know what you do not know. Ask Claude to interview you before writing code: it asks about the considerations you might miss (cache invalidation, failure modes, consistency, retention), and the answers become the specification.
4. One message or several?
| Issues | Approach |
|---|---|
| Interacting: a race condition causes a null pointer, which produces a misleading error message | One detailed message describing all of them, because fixing one changes the others |
| Independent: a typo in a config file and an unrelated slow query | Fix them one at a time, so each change is small and easy to verify |
In the exam
Stems describe an inconsistent transformation (examples), an edge case to fix (test cases with input and output), an unfamiliar feature (interview), or several bugs at once (decide whether they interact).
Check your understanding
A description of a date transformation keeps being interpreted differently. What is the most effective next step?
Show answer
Answer: B. Concrete examples pin down the transformation in a way prose does not, and they double as test cases.
You are about to build a caching layer in a domain you do not know well. What should you ask Claude to do first?
Show answer
Answer: D. The interview pattern surfaces considerations you have not anticipated before any code is written.
Three bugs interact: a race condition causes a null pointer, which causes a misleading error. A fourth bug is an unrelated config typo. How do you proceed?
Show answer
Answer: A. Coupled problems need to be fixed together because each fix affects the others. An independent issue is easier to verify on its own.
Apply it: Harbor Lane's audit-log feature
Harbor Lane must add audit logging to api/, a domain nobody on the team knows well. Plan the refinement approach.
- List five interview questions you expect Claude to ask, and why each matters.
- Write three test cases (input and expected output) that pin down the log format.
- Describe the test-driven loop for the implementation.
- Handle a failure: the logs drop entries under load, and timestamps are in local time. Do they go in one message or two?
Show model answer
1. Interview questions
- Which actions must be logged (reads, writes, logins)? Defines scope.
- How long are logs kept, and who may read them? Retention and access.
- Must logs be tamper-evident? Storage design.
- What happens if the log store is down: block the request or queue? Failure mode.
- Is any logged data personal? Masking and privacy.
2. Test cases
| Input | Expected log entry |
|---|---|
| User 42 updates booking 9 | {"actor": 42, "action": "booking.update", "target": 9, "at": "<UTC ISO 8601>"} |
| Anonymous request rejected | {"actor": null, "action": "auth.reject", ...} |
| Payload with a card number | Card number masked to the last four digits |
3. Loop. Commit the tests first; ask Claude to implement until they pass; paste failures back with the test name and output; add a load test once the functional tests pass.
4. Failures. Two messages. Dropped entries under load and local timestamps are independent: one is a concurrency problem, the other a formatting one. Fixing them separately keeps each change verifiable.