Skip to main content
Merge’s core assessment format is a pull request review loop. Unlike whiteboard questions or algorithmic puzzles, it puts candidates in a workflow that mirrors real day-to-day engineering — reading unfamiliar code, leaving meaningful feedback, and iterating as the author responds.

​
The four steps

1

Read the Codebase

Candidates enter a small, realistic codebase paired with a pull request. The scope is deliberately tight — candidates can understand the context in minutes, not hours. This mirrors how engineers routinely pick up a PR they didn’t author: a quick read of the surrounding code, a scan of the commit history, and enough context to review with confidence.
2

Review the Pull Request

Candidates read through the PR diff and leave inline comments. They evaluate correctness bugs, refactoring opportunities, and security vulnerabilities — the same lens an experienced reviewer brings to any code review. There are no multiple-choice prompts or guided questions; the candidate decides what matters and how to articulate it.
3

AI Publishes a Revision

Merge’s AI reads all candidate comments and opens a fresh PR revision that addresses them. The revision is realistic: it may fix some issues cleanly, partially address others, or introduce new trade-offs for the candidate to evaluate. This is not a simple “fix everything” pass — it responds with the nuance of a real author.
4

Iterate Until Satisfied

The candidate reviews the new revision, leaves further comments, and the cycle continues. The loop ends when the candidate approves the code or the session time expires. Each round of iteration is recorded and scored independently.

​
What the loop measures

The review loop surfaces signal that structured coding exercises rarely capture. You can see how candidates reason about unfamiliar code under time pressure — whether they orient quickly, identify the highest-risk changes, and write feedback that a real author could act on. The loop also reveals prioritization judgment. A candidate who flags twenty minor style nits before catching an off-by-one error in a critical path tells you something different from a candidate who leads with the correctness issue and follows up with refactoring suggestions. The revision stage adds another dimension: iteration quality. Does the candidate re-read the revised diff critically, or do they approve it without scrutiny? Do they notice when the AI introduced a new problem while fixing an old one? Do their comments grow more precise as the session progresses? These patterns reflect how engineers actually behave on high-functioning teams — not whether they can solve a puzzle in isolation.

​
Session duration

Most sessions run approximately 30 minutes. That window is intentional: it’s long enough to form a real opinion about the code, but short enough that candidates must make decisions about what to prioritize. Difficulty and specialization settings affect the complexity of the codebase and PR. A senior-level backend assessment may involve more subtle concurrency trade-offs than an entry-level web assessment, but both run within the same time envelope. You can configure these settings when creating an assessment.

Candidate Experience

See exactly what candidates encounter — from the invite email to the PR review interface.

AI Revisions

Learn how Merge’s AI generates realistic PR revisions that continue the loop automatically.