Your Architecture Isn't Fast Until It Has a Number Attached

Every frontend system design interview has a moment where the candidate says "it'll be fast and scalable" and the interviewer's pen does a little dance. Not the good kind of dance. The "zero points, moving on" dance.

"Fast" is not a design. It is a hope with a logo. The candidate who sounds senior never says fast. They say a number, and then they say what they are deleting to hit it. That second part is the whole game.

The performance budget is a negotiation, not a constraint

Most candidates treat performance like a property the architecture magically has. Seniors treat it like a budget they are allowed to spend, which is a completely different mental model. A budget means three things: a number you commit to, a way to measure it, and a list of things you will cut when the meter goes red.

Walk in with that frame and something weird happens. The interviewer stops testing your component diagram and starts negotiating with you. "What if the carousel breaks the budget?" "Then the carousel ships in phase two and the hero section renders in one paint." That back-and-forth IS the interview. The whiteboard is just the receipt.

The non-obvious part: the budget makes you faster, not slower. Candidates without a budget draw fifteen boxes and then defend all of them for twenty minutes. Candidates with a budget delete five of their own boxes in the first ten minutes, unprompted, and the interviewer promotes them for it. Nothing impresses a hiring bar like a candidate who volunteers the amputation.

The 4-line budget card

Here is the entire artifact. Write it in the corner of the whiteboard before you draw anything:

1. Metric. Pick one per surface. LCP for pages, INP for interactions. One.
2. Budget. A number from the world, not your feelings. "2.5s on a mid-range Android over 4G" beats "fast" the way a salary beats "competitive compensation."
3. Current. Your honest estimate after sketching the happy path. You will be wrong. Saying it anyway is the point.
4. Cut list. Two or three things you already know you will sacrifice when the number blows: the carousel, the third-party chat widget, the hero video on mobile.

Then narrate the ledger out loud as you design. "That adds 80KB of JS, my budget has 170KB, the chat widget is now on the cut list." You are showing the interviewer a working engineer thinking in public. That is the highest-scoring sentence shape in the entire round.

A 60-second worked example

Prompt: "Design a social feed that feels instant on a cheap phone."

Budget: LCP 2.5s on 4G, JS payload 170KB.

Happy path estimate: skeleton feed at 1.8s, images lazy, 140KB of JS. Under budget. Good.

Then the interviewer pokes it: "Marketing wants an autoplaying video hero." New estimate: 3.4s, 260KB. Over budget. So you say it out loud: "Video goes to the cut list on mobile. Desktop keeps a muted preview under 100KB. The 2.5s budget survives." You just turned a trap question into a promotion signal in under a minute.

I turned the full 60-question drill set into The Frontend System Design Interview Playbook ($19): https://bittalk.gumroad.com/l/frontend-interview-playbook. Sixty architect-level questions, the frameworks, the trade-offs, the drills.

The closer

The interview is not scored on your diagram. It is scored on the decisions the diagram forced you to make, and whether you made them out loud. A performance budget is just a way to make the decisions visible before anyone asks. Bring the number. Bring the meter. Bring the list of things you are willing to kill. That is what senior sounds like.