Describe the latency requirements section and how you would derive its numbers.

How to answer this, stage by stage

Six moves. The trap here is naming one number that sounds confident and hides seven different jobs inside it.

Let's learn

Here's what happens when a single confident number in a PRD meets the one night it was never tested against.

Say Sideline Cut, an app that watches a live match and turns a big moment into a clip a fan can post before the next kickoff, promises a clip inside "10 seconds" of the moment happening. That's the whole latency requirement, one line, one number, written before launch.

On an ordinary Tuesday fixture, that number holds fine. Traffic is light, one clip renders at a time, the broadcast cuts to its own replay quickly, and the app's clip lands around 9 or 10 seconds after the goal. Nobody questions the line. It works, so nobody opens it up to see what's actually inside it.

Then a derby comes along, the two biggest clubs in the league, Cliffgate FC against Northmoor United, watched by ten times the usual crowd. Every big moment now triggers a highlight, sometimes three inside a minute. The render stage, which usually handles one clip at a time, is suddenly queuing four. The broadcast's own production truck, busy with its own big night, takes longer to cut to a replay angle. The clip that used to land at 10 seconds now lands at 24.

Here's the turn. Fourteen extra seconds is not really the problem. The real problem is that nobody can say why. The PRD's one line, "clip ready in 10 seconds," never said which of the seven jobs inside that promise was allowed to be slow and which one wasn't. So when the derby broke the number, the on-call engineer didn't know whether to look at the render queue, the broadcast feed, or the caption model. He had to check all seven, live, while a sponsor's real-time promo was counting down.

Here's what that costs at its worst. Sideline Cut had promised a betting partner clips inside 20 seconds for marquee matches, part of a live odds-boost promo running during the derby. At 24 seconds, the app was already outside that line, and nobody in the room could say with confidence which stage to trim first, because the PRD had never separated them.

The choice I would take back. Writing the requirement as one merged number, "10 seconds," instead of seven owned stages added together. That was fine before launch, when only quiet matches existed to test it against. It stopped being fine the first night traffic and the broadcast's own pace both moved at once.

What I would leave alone. Sideline Cut also builds a weekly "team of the week" reel, assembled and emailed out on Monday morning. Nobody is refreshing their phone waiting for that one. It could take four minutes and nobody would notice. Speed only matters where somebody is holding a moment while they wait.

The lesson. A number with no parts is a guess wearing a deadline's clothes. The fix was never a faster pipeline. It was writing down which ten seconds we were actually promising.

Now here is the same thing as a story

The short version is above. Read on if you want to feel why a spreadsheet cell almost cost a sponsor deal.

Farai Chikwava has been the product lead on Sideline Cut's clip pipeline since it was three engineers and a whiteboard. She wrote the very first version of the latency requirement herself, back when the whole feature was: watch the feed, spot the moment, cut a clip, ship it. "Ten seconds" felt honest at the time, because ten seconds was roughly what it took, and nobody had reason to ask what was inside that number.

For most of a season, that line in the PRD did its job quietly. Ordinary matches, ordinary traffic, clips landing around 9 or 10 seconds after the whistle. Farai would glance at the dashboard once a week, see the average sitting where it should, and move on to the next thing on her list.

Seven jobs hiding inside one number. On a quiet night, none of them fought each other for room.

The derby between Cliffgate FC and Northmoor United landed on a Saturday in March. Ten times the normal crowd, on the app and in the stands. Farai wasn't even on call. She was watching the match at home, phone in hand like every other fan, when the clip of the opening goal still hadn't shown up in her feed a full twenty seconds after she'd already seen the replay on television.

She refreshed. Still nothing. Then it landed, 24 seconds after the goal, well past the 20-second line the team had promised a sponsor for a live odds-boost promo running that exact match.

Casimir Okoro was the engineer on call that night. He got the same alert Farai did, a queue depth warning on the render service, four clips deep and climbing. He had about ninety seconds to decide what to do before the next big moment made it worse. He didn't know, at a glance, whether the slow part was the render queue, the broadcast feed being slower to show its own replay angle, or something in the caption step. The PRD had one number in it. It didn't say which of seven jobs was allowed to be the slow one tonight.

He guessed right. He paused two lower-priority renders manually, by hand, watching the queue the whole time, and the next clip landed at 19 seconds, just inside the sponsor's line. It worked. It also worked because Casimir happened to be good at his job and paying close attention on a Saturday night, not because the spec had told him what to do.

Monday morning, Farai pulled up the original PRD line, the one she'd written herself more than a year earlier. One sentence: "clips are delivered within 10 seconds." No stages. No owner per stage. No note that the feed buffer was ever going to be at the mercy of how fast a broadcast truck decided to cut to a replay, on a night that truck was also busier than usual.

She rewrote it as seven owned stages, a range from 9 to 16 seconds depending on match load, and one flagged line: the feed buffer, not the render queue Casimir had spent his Saturday night watching, was the stage most likely to blow the budget, because it's the one stage Sideline Cut has never controlled.

Cliffgate and Northmoor played again six weeks later. Render had its own reserved capacity for marquee nights by then, and the sponsor deal had been renegotiated around the feed buffer's real slack instead of a number nobody had checked. The worst clip that night landed at 15.6 seconds. Inside the line. Casimir didn't have to guess, live, which of seven jobs to touch, because the spec had already told him which one was allowed to be slow.

The part she'd go back and tell herself: I wrote down how fast it should be. I never wrote down what it was actually made of.

BOUND, run on Sideline Cut's ten-second promise

This is a sizing question hiding inside a spec-writing question, so BOUND fits and FLIPS doesn't. Nobody's habit snapped here. A number that was honest at launch quietly stopped covering the case it was actually going to be tested against.

The range against a feeling a fan already has. Both bounds sit near a wait people already tolerate for a TV replay.

B, break it down. Total clip time is the sum of seven real jobs: feed buffer, highlight scoring, clip trim, caption generation, render and encode, rights check, and the push to the app. Not one number standing in for all seven.
O, own the numbers. Each stage's low and high comes from what it actually does: 4.0 to 6.8 seconds for the buffer, because it waits on the broadcast's own replay angle; 2.0 to 4.0 seconds for render and encode, because that's where queue depth bites under load; smaller, tighter ranges for the rest.
U, use a range. 9.0 seconds on a quiet match, 16.0 on the derby with every stage under load. A single number can't cover both, and pretending it can is exactly what broke on Farai's Saturday.
N, nail the sanity check. A stadium's own replay truck already puts an instant replay on the big screen in about 10 to 15 seconds. A clip landing inside that window doesn't feel slow to a fan who's already used to that wait. Past 20 seconds, the moment's gone, and the clip reads as leftovers, which is exactly why the sponsor's line was set at 20.
D, direction. The feed buffer swings the total the most, 2.8 seconds of swing against 2.0 for render and 0.8 for the app push. And it's the one stage the team doesn't own: it's set by how fast the broadcast's own production truck decides to cut to a replay. Speeding up render, the part engineering actually controls, helps, but it was never the stage most likely to blow the promise.

And if you want to be sure it really works, try it somewhere else

Larkfield Surgical Systems builds an overhead-camera system that counts every instrument and sponge on the tray before an incision closes, and alerts the team if the count doesn't match the pre-op list. It slows down the same way, built from a completely different set of parts.

B, break it down. Total alert time is tray image capture and stabilization, plus the detection model counting each item, plus a cross-check against the pre-op manifest, plus rendering the alert to the OR display and pager. Four stages, not one flat number.
O, own the numbers. Capture runs 1.5 to 4.1 seconds, because a cluttered tray on a long, complex case needs more repositioning before the camera holds still. Detection runs 0.8 to 1.5 seconds. The manifest check and the alert render add another 0.6 to 1.4 combined.
U, use a range. 3.0 seconds on a simple procedure with a tidy tray, 7.0 on a complex one with dozens of instruments spread across a cluttered field.
N, nail the sanity check. Marit Ellingsen, Larkfield's eval lead, checked the number against something already happening in every OR: the scrub nurse's own verbal instrument count, a standard step that already takes 5 to 8 seconds before anyone closes. An alert landing inside that window is invisible, folded into a pause that was already there.
D, direction. Here it isn't an outside dependency that swings the budget, like Sideline Cut's broadcast truck. It's how cluttered the tray gets. Capture and stabilization swings 2.6 seconds on its own, more than every other stage combined, because a busy field takes longer to hold still for a clean read, whatever the model underneath does.

The old decision Larkfield would take back is a different shape from Farai's. Where Sideline Cut had merged seven stages into one guessed number, Larkfield had picked one flat default, "alert within 5 seconds," and applied it to every procedure type. That default was right for a simple case and quietly wrong for a complex one, the same way a single confident number is always right for the case it was measured against and wrong for the one it wasn't.

Swap the trigger and it still runs.
Speed: an interviewer asks how fast you'd ship a usable latency spec before Sideline Cut's playoff week. Same seven-stage equation, shipped first with the caption stage skipped, an overlay template instead of AI-written text, tightened once there's time to add it back.
Cost: engineering caps how many GPUs stay reserved for the render stage. Same equation, solved backwards: at that fixed budget, the highest total the team can promise rises from 16.0 seconds toward 19, so the sponsor's 20-second line has to be renegotiated to match what the budget can actually prove.
The model got better: a faster highlight-scoring model cuts that one stage's time in half. The total's high end barely moves, from 16.0 toward 15.4, because scoring was never the stage swinging the budget. Speeding up a stage that isn't the sensitive one buys almost nothing.

Where people run it wrong.
They write one round number in the PRD because it reads clean, then have no way to say which stage to check when the promise breaks under real load.
They test the happy path only and forget the request that skips a stage or adds one, so the number is right for the one case they measured and wrong for the busiest night of the year.
They chase the stage that's easiest to speed up, usually the one fully inside their own system, instead of the stage that actually swings the total most, which is often the one they don't control at all.

How to use it live. Say the equation out loud before naming a single number: list the real stages, then say you'll come back with a low and a high once each one has an owned assumption. That buys a few seconds to think, and tells the interviewer a real number is coming, not a guess dressed up as one.

Flashcards (click a card to flip it)

Check yourself Score: 0 / 0