Pair-Programming and Practical Rounds

## What a work-sample round is A work-sample (or practical) round replaces the blank editor with a real artefact. Instead of asking you to invent an algorithm, the interviewer gives you something that already exists and watches how you operate on it. Four formats cover almost everything you will meet: - **Pair-programming on a live codebase.** You and an interviewer sit in one session on a small but real project and add or change behaviour together. - **Fix-the-bug in a seeded repository.** The interviewer hands you a checked-out repository and one failing test that encodes the bug. Your job is to make that failing case pass without collateral damage. - **Code-review round.** You are given a change someone else wrote — often with one or two defects planted in it — and asked to review it aloud. - **Test-driven work sample.** You are asked to grow a small piece of behaviour with tests leading the code, so the interviewer can watch your feedback loop rather than your final answer. ## Why companies run them Algorithm rounds are cheap to run and easy to compare, but they answer a narrow question: can this person invent a solution to a self-contained problem under time pressure? Most engineering work is not that. It is landing in a codebase you did not write, reproducing something a user reported, changing as little as possible, proving that you did not break the rest, and explaining it to a colleague. A work-sample round asks that question directly, which is why it is common at product companies and scale-ups where the first weeks of the job look exactly like the exercise. The format also tends to be fairer to candidates who work well and think out loud but freeze at a whiteboard, and it is harder to prepare for by memorising patterns — the repository is unfamiliar to everyone. ## What the rubric actually rewards Across all four formats the scored dimensions rhyme: | Dimension | What a strong candidate does | |---|---| | Orientation | Runs the build and the test suite before reading everything; finds the entry point from the failing test | | Evidence | Reproduces the failure and forms a hypothesis from output, not from a guess about what is wrong | | Change size | Makes the smallest change that turns the failing case green; separates cleanup from the fix | | Verification | Re-runs the whole suite, not just the one test; checks the neighbouring cases | | Collaboration | Says what they are doing and why, and takes a correction without losing the thread | ## A concrete picture Imagine a developer-tools vendor that sells a build-analytics service. The round is a 75-minute pairing session with a senior test engineer from the team. She shares a repository you have never seen, points at one failing test, and says the reported symptom is that a nightly rollup occasionally reports the wrong total. There is no puzzle to invent. The whole exercise is: run it, see it fail, read the test to learn the intended behaviour, follow the failure into the code, change a few lines, re-run everything, and describe the follow-up you would open. The most common way to lose this round is to decide the seeded code is badly written and start rewriting it. The candidate who reorganises the module has, at the buzzer, a half-migrated repository, a failing suite and no evidence that they can be trusted with a production defect. The candidate who lands a five-line fix with the suite green and says which structural weakness they would tackle next scores far higher — and has said the same thing about the code, without the wreckage. ## How to prepare Practise on code you did not write. Clone a small open project, pick an open issue, reproduce it, and time yourself from first clone to a green suite. Get comfortable running an unfamiliar build and test command inside the first few minutes, reading a test as a specification, and narrating a hypothesis before you change anything. Rehearse the sentence you will say when time runs short: what is done, what is verified, what you would do next. That habit is worth more than any pattern you could memorise, because it is the same habit the job needs.