Sketching Architecture Live

A quick diagram before any code signals you think at the system level, not just prompt-and-paste. It shows you understand the moving parts before you build them. The diagram is not the deliverable — it's the shared mental model that opens the conversation. The code proves the reasoning.

Not every task needs a diagram. Skip it when: the data flow has one source, one transform, one sink. A single endpoint. A single-file change. A verbal 'input → process → output' is faster and equally informative. Draw when you genuinely can't hold the system in your head — multi-service, multi-agent, or branching data flows.

One box per independently deployable concern or data transformation boundary — typically 2-5. Each box is a component or service. Arrows show data flow. Labels answer: what data moves? In what format? Triggered by what? The thin slice — the smallest end-to-end path — should be visually distinct (bold borders or a highlighted path through the boxes).

Excalidraw: fast and the hand-drawn look signals 'thinking, not presenting.' Miro: good if the interviewer's company uses it. Paper: useful as a personal thinking scratchpad (camera off), then redraw digitally to share. Have the tool open in a separate window before the call starts.

'Let me sketch the main moving parts — I'm seeing about [N] of them.' Draw while talking. Point at boxes as you name them. When done: 'This is the thin slice. If this holds, we add [next layer].' Then close or minimize the drawing tool and start coding.

Aim for roughly 2 minutes. If you're still drawing past 3 minutes, pause and ask yourself: am I thinking or stalling? If thinking, keep going and say so — 'One more minute to map the error paths.' If stalling, switch to code. The architecture sketch is a scaffold, not a blueprint. If the interviewer interrupts with a question, answer it and offer to return to the diagram only if needed.

Drawing instead of building — more than 3-4 minutes on a diagram when you could be coding. Over-engineering the sketch — UML, formal notation, too many boxes. No diagram at all — jumping straight to code on a multi-component problem signals you don't think before you build. Drawing for single-pipeline tasks — a verbal walkthrough is faster and shows the same reasoning.