> ## Documentation Index > Fetch the complete documentation index at: https://docs.mergeoa.com/llms.txt > Use this file to discover all available pages before exploring further. # How Merge's Pull Request Review Loop Works in Practice > Understand the four-step PR review loop that powers every Merge assessment, from reading the codebase to iterating on AI-generated revisions. 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 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. 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. 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. 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. See exactly what candidates encounter — from the invite email to the PR review interface. Learn how Merge's AI generates realistic PR revisions that continue the loop automatically.