Correct code is the start of a senior coding interview

Separate algorithmic coding from platform coding

Algorithmic interviews emphasize decomposition, invariants, complexity, and edge cases. Platform coding tasks look more like a small repository: multiple files, an existing contract, tests, logs, and constraints on what may change. They overlap, but they do not measure exactly the same work.

Preparing only in a single-file editor leaves a gap. Realistic platform tasks require navigation, reading before editing, understanding ownership, and preserving behavior outside the visible happy path.

Strong candidates create a contract before they code

• Restate the input, output, and invalid-input behavior.
• Work through one ordinary case and one boundary case.
• Name the invariant or state transition the solution relies on.
• Choose the implementation only after the complexity target is clear.

This does not require a long speech. Thirty focused seconds can prevent ten minutes of implementing the wrong contract.

Examples are not a test strategy

Sample cases confirm that the interface is understood. They rarely prove correctness. Add cases that attack the chosen approach: empty input, duplicated values, maximum size, invalid state transitions, race conditions, partial failures, or repeated retries.

test('retries do not duplicate the side effect', async () => {
  await deliverWithRetry(message);
  expect(provider.send).toHaveBeenCalledTimes(1);
});

Narrate decisions, not keystrokes

“Now I create a map” gives the interviewer no evidence. “I need constant-time lookup of the previous prefix, so I will store the earliest index for each sum” exposes the reasoning and gives the interviewer a useful point to challenge.

When you change direction, say why. Correction is not failure. Silent thrashing is harder to evaluate than a clear statement that an assumption was wrong and the invariant must change.

Platform tasks reward controlled change

1. Inspect the entry point, contract, and relevant tests.
2. Reproduce the failure before editing.
3. Localize the cause and state what evidence supports it.
4. Make the smallest change that restores the contract.
5. Run focused tests, then the broader suite.
6. Explain residual risks and any follow-up work.

The best solution is not always the shortest patch. It is the smallest change whose behavior you can defend.

What changes at senior level

• You expose ambiguity early instead of coding around it.
• You choose an appropriate design, not the most elaborate one.
• You connect tests to production failure modes.
• You preserve observability and debuggability.
• You communicate trade-offs without losing implementation momentum.

These signals should be scored explicitly. A vague impression of confidence is not a reliable evaluation standard.

A practice loop that improves transfer

1. Solve once with guidance and record the missed decision.
2. Re-solve a related task without guidance within the interview timebox.
3. Compare code, tests, and explanation against the rubric.
4. Repeat the weak behavior on a different topic until it appears unprompted.

Topic variety matters. If every task is a prefix-sum variant, improvement may be pattern recognition rather than better problem solving.