Skip to content

Live walkthrough and improving the MR

Present by counted impact, fix by value per minute: spend the call's minutes where they remove the most harm.

Predict first

Before you read: predict

MR !3421 releases ECON-201's results. Your review left five comments, in file order:

src/results/release.ts l.3   nitpick: `acceptsSubmission` would say what this checks.
src/results/release.ts l.4   issue (blocking): a candidate with extra time is refused at the standard end time.
src/results/release.ts l.7   nitpick: `passedIds` would read better than `passed`.
src/results/release.ts l.8   issue (blocking): the pass list sent to the exam registry stops at 1,000 rows.
src/results/release.ts l.12  issue (blocking): a score of 49.5% or more but under 50% is shown as a fail; the rule rounds to the nearest whole percent.

The last sitting's logs, for 2,400 candidates: 36 candidates with extra time were still answering at the standard end time, 19 scored at least 49.5% but under 50%, and 1,630 passed. The interviewer gives you ten minutes and asks you to walk them through your review.

Which finding do you present first?

Pick one

The 30-second version

In the call, don't read your comments top to bottom. Count what each blocking finding does to people on a real day's traffic, present the top two or three in about a minute each, and leave the rest written. Then fix the one that removes the most harm per minute and still fits, test first.

Present by counted impact, fix by value per minute: spend the call's minutes where they remove the most harm.

How it works

Step 1 of 12

Two parts. GitLab's 90-minute call: you walk the interviewer through your review, then write code that improves the merge request. [S1]

Analogy: A circus rigging inspector at the half-hour call before the evening show

At the big top In the call
she walks the trapeze rig in the order it is built and writes every fault on her sheet your review: comments in file order
ten minutes with the ringmaster: the unwired shackle pin and the torn net first, not the scuffed ladder paint top findings by impact, not file order (steps 2, 5)
"the rest is on my sheet" the rest stays written (step 7)
wiring the pin takes five minutes and removes the worst risk; re-lacing the net takes two hours value per minute, and it must fit (steps 9, 10)
the net panel booked for the morning a fix described and agreed as a follow-up (step 10)
she tugs the pin and watches it turn before wiring it, then tugs again red first, then green (steps 11, 12)

In real terms: say the counts first, spend the fix minutes where each removes the most, and show the test fail before it passes.

Breaks down when: rigging faults are rated by a safety code, and one unsafe item stops the act. An MR's impact is counted on your own traffic model, and the interviewer can give you better numbers (step 8).

Contrasting case: an asynchronous review with no call. The author reads every comment in their own time, so order costs nothing, and the labels do the ranking (mr-severity-tagged-comments).

Examples, run for real

4.1 ExamHall EXH-3120: ten minutes to present, thirty to fix

EXH-3120: a practice call on MR !3420, which submits an ECON-201 attempt and writes its receipt. The review holds fourteen comments, three of them blocking: a receipt reading "NaN%" for a candidate who answered nothing (2nd in file order), an older answer replayed after a reconnect overwriting a newer one (4th), and a second click on Submit (12th):

// src/sitting/submit.ts (after the MR)
import type { AttemptStore, Sitting } from '../infra/types';

export async function submit(store: AttemptStore, sitting: Sitting, attemptId: string) {
  if (!(await store.isOpen(attemptId))) return { status: 'closed' as const };
  const answers = await store.draft(attemptId);
  await store.clearDraft(attemptId);
  const score = answers.filter((a) => a.choice === sitting.keys[a.questionId]).length;
  await store.save(attemptId, score);
  return { status: 'submitted' as const, score };
}
4.1 impact on the last sitting (2,400 candidates): replay after reconnect 90 · second Submit click 48 · NaN% receipt 6 · each wrong on the MR, right with its fix
4.1 the second click as merged: saved score 0 where the draft holds 7 right (0 -> 7)
4.1 walkthrough in file order, a minute a comment, stopped at 10:00: blocking heard 2 of 3 (NaN% receipt at 2:00, replay after reconnect at 4:00) · never said: second Submit click
4.1 walkthrough by impact: replay after reconnect at 1:00 · second Submit click at 2:00 · NaN% receipt at 3:00 · the other 11 summarised by 4:00
4.1 live fix, 30 minutes: NaN% receipt 6 in 3 min (2.0 a minute) · replay after reconnect 90 in 45 min (does not fit) · second Submit click 48 in 15 min (3.2 a minute)
4.1 chosen: second Submit click, then NaN% receipt (18 of 30 minutes) · replay after reconnect described and agreed as a follow-up
4.1 test first, "a second Submit while the first clears the draft keeps 7": on the MR saved 0 · red
4.1 line 4 with claim() instead of isOpen(): saved 7 · green · suite before 1 passed, 1 failed, after 2 passed

In file order the slot ends before the second click, the finding the call goes on to fix. By impact, all three are said in three minutes (steps 2, 5–7). The replay hurts most but cannot reach green in thirty minutes, so it becomes a follow-up; the second click removes the most per minute of the fixes that fit (steps 9, 10). Its test goes red before line 4 changes, then green (steps 11, 12). Why the second click reads an empty draft belongs to mr-async-race-defects.

4.2 Proof domain, ticketing: two candidates, one half hour

A box office's MR changes seat holds. Both candidates found the same three blocking findings; what differs is which fix each makes live:

4.2 impact on a day (seats sold wrong or not at all): two buyers on one seat 120 · "extend hold" lasting 0.6 s 45 · expired holds back on sale at midnight 20 · each wrong on the MR, right with its fix
4.2 candidate 1, biggest first: two buyers on one seat, estimate 50 min > 30 · not green at 30:00 · seats fixed in the call 0
4.2 candidate 2, value per minute: "extend hold" lasting 0.6 s 45 in 3 min (15.0 a minute), then expired holds back on sale at midnight 20 in 12 min (1.7 a minute) · both green by 15:00 · seats fixed 65 · two buyers on one seat described as a follow-up

The first candidate fixed the biggest finding and ended the call with nothing green. The second divided each count by its minutes, made the two fixes that fit, and described the third (steps 9, 10).

Picture it

Concept illustration for this lesson.
An illustration to help it stick. The mechanism is in the sections above.

Try it

Answer first, then check. Nothing is saved.

Question 1 of 8

A box office's MR !3423 changes checkout. Your four blocking comments, in file order:

src/checkout/order.ts l.7   issue (blocking): an order with a promo code is charged no £1.50 booking fee.
src/checkout/order.ts l.8   issue (blocking): the 10% member discount comes off the booking fee too, 15p an order.
src/checkout/order.ts l.13  issue (blocking): an order paid partly by gift card collects only the gift card's balance; the rest is never charged.
src/checkout/order.ts l.18  issue (blocking): pressing Cancel twice refunds the order twice.

Yesterday's traffic: 5,000 orders, each two tickets at £24 plus the £1.50 booking fee (£49.50 before any discount); 800 used a promo code, 1,400 were members' orders, 60 paid £20 of it by gift card, and 30 were cancelled with a double press.

In what order do you present them?

Your order

  1. 1empty
  2. 2empty
  3. 3empty
  4. 4empty

Tap the lines in the order you expect.

Question 2 of 8

After your walkthrough of a payments ledger's MR !3424, 25 minutes are left for the live fix. Your three blocking findings, with the money each posts wrong in a day (counted on yesterday's postings) and your estimate to a green test:

src/ledger/interest.ts l.6   daily interest rounded down, not to the nearest penny   £89.97 a day   5 minutes
src/ledger/reversal.ts l.4   a retried reversal webhook is posted twice              £900 a day     15 minutes
src/ledger/fx.ts l.4         transfers converted at yesterday's rate                 £2,600 a day   60 minutes

Which fix do you make live?

Pick one

Question 3 of 8

A video platform's MR !3425 changes where playback starts. Your three blocking comments, in file order:

src/player/resume.ts l.4   issue (blocking): on the TV app, "Continue watching" starts the next episode instead of resuming this one.
src/player/resume.ts l.8   issue (blocking): on the web player, a page refresh restarts the episode from 0:00.
src/player/resume.ts l.9   issue (blocking): on mobile, switching network restarts the episode from 0:00.

From the logs: 5% of web plays include a refresh, 10% of mobile plays switch network, and 30% of TV plays start from "Continue watching". You planned your walkthrough from the MR description: 100,000 plays a day, 30% on web, 64% on mobile and 6% on TV.

In the call the interviewer says: "This year it's 45% web, 20% mobile, 35% TV." Which finding do you lead with now?

Pick one

Question 4 of 8

A team chat's MR !3426 changes notifications. Your three blocking comments, in file order:

src/notify/notify.ts l.4   issue (blocking): a user whose display name has an emoji is never notified of a mention.
src/notify/notify.ts l.9   issue (blocking): signing in on a second device stops notifications on the first.
src/notify/notify.ts l.15  issue (blocking): a user in more than 200 channels never gets the unread badge.

Yesterday's logs: 250 users have an emoji in their display name; 3,000 second-device sign-in lines came from 400 users; 900 users are in more than 200 channels.

Which finding do you present first?

Pick one

Question 5 of 8

MR !3427 adds a proctor's "+10 minutes" button. Your walkthrough's top finding: two presses before the page updates send two requests with one request id, and the candidate gets twenty minutes; last sitting the console sent 37 such duplicates. The MR's file:

The repo also holds the MR's own test, extend-time.test.ts, and an in-memory memoryTimers(endsAt) in timers.memory.ts with applied and markApplied.

Make the fix live, test first: in one folder, write extend-time.test.ts, a test that fails on the MR's file, and extend-time.ts, your fixed function.

Code for this question
// src/proctor/extend-time.ts (after the MR)import type { TimerStore } from '../infra/types'; export async function extendTime(store: TimerStore, attemptId: string, requestId: string, minutes: number) {  const endsAt = (await store.endsAt(attemptId)) + minutes * 60_000;  await store.setEndsAt(attemptId, endsAt);  return endsAt;}

Question 6 of 8

Before making P5's fix, the interviewer asks you to explain the finding in at most 80 words: open with who it hurts and how many, then give the input that triggers it and the change you will make.

Write what you would say in a text file.

Question 7 of 8

On a video platform's MR !3428 you planned 30 minutes for the live fix, and the download-queue fix fitted best. The walkthrough ran long, and 15 minutes are left. Your four findings, with the plays that go wrong in a day and your estimate to a green test:

src/player/extras.ts l.4    a failed download at the head of the queue blocks the downloads behind it   5,000 plays   20 minutes
src/player/extras.ts l.8    subtitles take the first track, not the profile's language                  1,500 plays   12 minutes
src/player/extras.ts l.12   "Skip credits" jumps 10 seconds, not to the end of the episode              1,100 plays   5 minutes
src/player/extras.ts l.16   the next episode starts when the profile has autoplay off                   700 plays     4 minutes

Which fix do you make first?

Pick one

Question 8 of 8

A team chat's MR !3429 changes how messages are kept. Your three blocking comments, in file order:

src/messages/messages.ts l.4   issue (blocking): an edit saved within a second of sending is lost.
src/messages/messages.ts l.8   issue (blocking): after a reconnect fails, the messages waiting in the outbox are dropped.
src/messages/messages.ts l.12  issue (blocking): a message over 4,000 characters is cut at 4,000.

Yesterday's traffic: 10,000 edits, 1,400 of them saved within a second of sending; 30,000 reconnects, 150 of them failed, with 12 messages waiting on average; 600,000 messages sent, 1,200 of them over 4,000 characters. Incidents filed against each area this year: edits 2, reconnects 0, message length 9.

Which finding do you present first?

Pick one

Go deeper

Pro tip
  1. Keep a one-line card per blocking finding: count, trigger, fix, minutes. Sorting the cards by count gives the walkthrough's order; dividing count by minutes, among those that fit, gives the live fix. When: after the asynchronous review, before the call (steps 2, 9). Verify (RAN, tips.mjs):
    tip cards (count · minutes): NaN% receipt 6 · 3 | replay after reconnect 90 · 45 | second Submit click 48 · 15
tip by count, the walkthrough: replay after reconnect > second Submit click > NaN% receipt
tip by value per minute, fitting 30: second Submit click first · replay after reconnect does not fit
    Status: RAN.
Source

Every key in this lesson is executed; these passages support the teaching steps they are marked on, checked verbatim by quote-check.mjs. Valid as of 2026-10-06.

  • GitLab Handbook, Technical Interviews (the curriculum row's first source), https://handbook.gitlab.com/handbook/hiring/interviewing/technical/ (gitlab-technical-interviews.txt). Quoted: "This technical interview is a 90-minute video call and screen-sharing session with the interviewer(s), where they will ask you to walk them through your review and where you will also write some code to improve the merge request." Supports step 1. Quoted: "You will receive a link to the merge request at least 72 hours before your scheduled call." The review, and so its counts, exist before the call (steps 2, 8).
  • Paul Slaughter, Conventional Comments (the row's second source), https://conventionalcomments.org/ (conventional-comments.txt). Quoted: "nitpick: Nitpicks are trivial preference-based requests. These should be non-blocking by nature." Supports step 7. Quoted: "issue (ux,non-blocking): These buttons should be red, but let's handle this in a follow-up." Supports step 10: a known issue can be agreed for later.

Related lessons

Checked against the tools and docs as of 2026-10-06.