Tech Presentation Interview

Tech Presentation Interview

The tech presentation round is a reverse system design: instead of designing a hypothetical system on a whiteboard, you present a real system YOU built. This tests three things no other round can: genuine depth of understanding, ability to communicate complex ideas under pressure, and authentic ownership versus inherited knowledge.

When to Use

Use for:

• Selecting which project to present from your career
• Structuring a 25-45 minute technical presentation with narrative arc
• Calibrating depth -- which components to go deep on, which to skim
• Preparing whiteboard/virtual-board diagrams with progressive disclosure
• Rehearsing answers to hostile follow-up questions
• Adapting presentation to different audience compositions (researchers, engineers, managers)

NOT for:

• Designing a system you haven't built (use ml-system-design-interview)
• Writing your resume or extracting career stories (use cv-creator or career-biographer)
• Coordinating across multiple interview rounds (use interview-loop-strategist)
• Practicing coding problems or behavioral STAR stories
• Conference talk preparation (different format, different evaluation criteria)

---

Project Selection

The most common failure mode is choosing the wrong project. Use this decision tree:

flowchart TD
    A[List your top 5 projects] --> B{Did YOU make key<br/>technical decisions?}
    B -->|No, I inherited it| SKIP[Skip this project]
    B -->|Yes| C{Can you explain<br/>alternatives you rejected?}
    C -->|No, I just used<br/>what was standard| SKIP
    C -->|Yes, I evaluated<br/>tradeoffs| D{Are there interesting<br/>failure modes or<br/>unexpected challenges?}
    D -->|It went smoothly| WEAK[Weak choice --<br/>no drama = no depth]
    D -->|Yes, things broke<br/>or surprised us| E{Can you fill 30+ min<br/>of technical depth<br/>on 2-3 components?}
    E -->|No, it was<br/>straightforward| WEAK
    E -->|Yes| F{Is it relevant to<br/>the target role?}
    F -->|Not really| BACKUP[Keep as backup --<br/>use if nothing<br/>better qualifies]
    F -->|Yes, strong match| PICK[Strong candidate --<br/>select this project]

Selection Criteria Scorecard

Rate each candidate project 1-5:

Threshold: Total score > 60 = strong choice. 40-60 = acceptable if nothing better. < 40 = find another project.

---

Narrative Arc Framework

Every great presentation follows this structure. Deviations lose the audience.

flowchart LR
    CTX["Context<br/&gt;2 min"] --> PROB["Problem<br/&gt;3 min"]
    PROB --> WHY["Approach & Why<br/&gt;5 min"]
    WHY --> ARCH["Architecture Deep Dive<br/&gt;10 min"]
    ARCH --> RES["Results & Impact<br/&gt;3 min"]
    RES --> CHANGE["What I Would Change<br/&gt;2 min"]
    CHANGE --> QA["Q&A<br/&gt;15+ min"]

Phase Details

1. Context (2 min) -- Set the stage. Who was the user? What was the business? Why did this matter?

• One sentence on the company/team
• One sentence on the user problem
• One sentence on the scale (requests/sec, data volume, user count)
• Do NOT start with "I built a service that..." -- start with the PROBLEM

2. Problem (3 min) -- What made this HARD? Not what you built, but why it was non-trivial.

• Constraints that created tension (latency vs accuracy, cost vs reliability)
• Why existing solutions didn't work
• What would happen if you got it wrong (consequences = stakes)

3. Approach & Why (5 min) -- Decision-making process, not just the decision.

• 2-3 alternatives you considered and WHY you rejected each
• The key insight or constraint that drove your choice
• What you were optimizing for (and what you knowingly sacrificed)

4. Architecture Deep Dive (10 min) -- Go deep on 2-3 components. NOT a tour of every box.

• Start with 3-box overview on whiteboard (see references/whiteboard-diagrams.md)
• Pick 2-3 technically interesting components to zoom into
• For each deep component: what it does, why it's designed that way, what breaks if you change it
• Progressive disclosure: add detail only when relevant or asked

5. Results & Impact (3 min) -- Quantified outcomes.

• Before/after metrics (latency, throughput, accuracy, cost, developer hours)
• Business impact (revenue, users, customer satisfaction)
• Team impact (adoption, developer experience, operational burden)

6. What I Would Change (2 min) -- The most important 2 minutes.

• 1-2 specific technical decisions you'd reverse with hindsight
• Why you made the original decision (it was rational at the time)
• What you learned that changed your thinking
• This section builds more credibility than all your wins combined

7. Q&A (15+ min) -- Where the real evaluation happens.

• See "Handling Deep Follow-Ups" section below

---

Depth Calibration

The cardinal sin is covering everything at surface level. Pick 2-3 layers to go DEEP.

Rule of thumb: Go deep on the parts where YOU made a non-obvious decision. Skim the parts where you used an industry-standard tool in the standard way.

---

Handling Deep Follow-Ups

The Q&A is where interviewers separate builders from bystanders. Prepare for these patterns:

"Tell me more about X"

• This is an invitation, not a trap. Go one level deeper on implementation.
• Structure: "The key challenge with X was [constraint]. We solved it by [approach] because [reason]. The tricky part was [non-obvious detail]."
• If you genuinely don't remember a detail: "I'd need to check the specifics, but the design principle was [principle] and the implementation followed [pattern]."

"Why didn't you use [alternative]?"

• Never dismiss the alternative. Acknowledge its strengths first.
• Structure: "We considered [alternative]. It's strong for [use case]. We chose [our approach] because in our context, [specific constraint] made [alternative] less suitable. Specifically, [concrete reason with numbers if possible]."
• If you hadn't considered it: "That's a good option I hadn't evaluated at the time. Based on what I know now, the key tradeoff would be [tradeoff]. I think for our constraints, [assessment]."

"That seems over-engineered"

• Don't get defensive. Restate the constraint that justified the complexity.
• Structure: "I understand that reaction. The complexity was driven by [specific requirement]. Without [the complex part], we would have hit [concrete failure mode]. That said, if [requirement] changes, I'd simplify by [specific simplification]."

"What would you do differently?"

• NEVER say "nothing." This is the most important question.
• Prepare 2-3 specific technical changes with reasoning.
• Structure: "Knowing what I know now, I'd change [specific decision]. At the time, [why it was rational]. Since then, [what changed -- new tooling, learned lesson, scale changed]. The new approach would be [specific alternative]."

"What's the failure mode?"

• Describe actual failures that happened, not hypotheticals.
• Structure: "The primary failure mode is [X]. We hit it [frequency]. When it happens, [impact]. Our mitigation is [approach]. The residual risk is [what's still unprotected]."

---

Audience Calibration

Adjust depth based on who's in the room:

---

Anti-Patterns

Demo Reel

Novice: Presents all wins, no failures or trade-offs. Every decision was optimal. The system performed beautifully from day one. Metrics only go up and to the right. Expert: Proactively discusses what didn't work, what surprised them, and what they'd change. Treats failures as evidence of genuine engagement, not embarrassment. Shares specific metrics for both successes AND shortcomings. Detection: When asked "what would you do differently?" the answer is vague ("maybe better testing") or unconvincing ("honestly, I'm pretty happy with how it turned out"). No failure stories surface organically during the presentation.

Team Credit Confusion

Novice: Uses "we" for everything. "We designed the architecture." "We chose Kafka." "We solved the latency problem." Unclear what THEY specifically did versus what the team did collectively versus what a teammate owned entirely. Expert: Clear ownership markers throughout: "I led the design of the serving layer, collaborated with our data team on the pipeline, and my teammate Sarah owned the model training infrastructure. Let me focus on the serving layer since that was my primary contribution." Uses "I" for decisions they drove, "we" for genuine collaboration, and names teammates for their contributions. Detection: Under follow-up questioning, cannot explain specific technical decisions in detail. When asked "why Kafka over RabbitMQ?", answers with "that was the team's decision" or gives a generic textbook comparison rather than the specific evaluation they ran.

Architectural Tourism

Novice: Covers every component at surface level. "And then we had a cache, and a queue, and a database, and a load balancer, and a model server, and a feature store..." Each component gets 1-2 sentences. Runs out of time before reaching anything interesting. The whiteboard looks like a busy subway map. Expert: Draws the 3-box overview, explicitly says "I'm going to focus on two components where the interesting engineering happened," and goes DEEP. Spends 5 minutes on one component explaining the tradeoffs, alternatives considered, failure modes, and what they learned. The interviewer leaves understanding that component thoroughly. Detection: Presentation runs over time. All component descriptions are surface-level. Whiteboard has 15+ boxes with no zoom-in area. When asked to go deeper on any single component, the candidate has nothing beyond what they already said.

---

Rehearsal Protocol

1. Solo run-through (3x minimum): Present to an empty room, timed. Target: 20-25 min for the structured portion, leaving 15-20 min for Q&A. 2. Record yourself: Watch the recording. Note filler words, hand-waving over gaps, and moments where you lose the thread. 3. Peer mock (2x minimum): Present to a technical friend. Have them play hostile questioner. Track which questions you fumble. 4. Q&A stress test: Have someone rapid-fire 10 questions from the hostile questions list. Practice composure under pressure. 5. Timing gate: If your structured presentation exceeds 25 min in rehearsal, cut content. You WILL run longer in the real thing.

---

Reference Files

Project Narrative Template

Use this template to structure a technical presentation from raw project material into a polished, interview-ready narrative. Fill in each section, then rehearse the assembled narrative 3+ times before presenting.

---

Part 1: Project Selection Checklist

Before investing preparation time, confirm this project passes the selection gate.

Ownership Verification

Answer each honestly. If you answer "no" to more than one, pick a different project.

• [ ] I made at least 2 key architectural decisions on this project
• [ ] I can explain WHY we chose approach X over alternatives Y and Z
• [ ] I can describe a specific failure or surprise and how I responded
• [ ] I can quantify the project's impact with real numbers
• [ ] I can fill 30 minutes of technical depth without repeating myself
• [ ] I can clearly separate MY contributions from the team's

Ownership Statement (Write This First)

Complete this sentence: "On this project, I was personally responsible for ________. I collaborated with the team on ________. My teammates owned ________."

This becomes your verbal anchor. When an interviewer asks "who did what?", you deliver this statement naturally.

---

Part 2: Context Frame (2 minutes)

The context frame answers: "Why should I care about this project?" It is NOT a company overview. It is the setup that makes the problem interesting.

Template

[Company/Team] serves [user type] who need to [core job].
At the time, we processed [scale metric] -- [X] requests per second /
[Y] GB of data daily / [Z] active users.

The business constraint was [what made this urgent or important]:
- [Revenue at risk / users impacted / regulatory deadline / competitive threat]

My role was [title/position], reporting to [who], on a team of [size].
I owned [specific scope].

What to INCLUDE

• Scale numbers that ground the problem (not vanity metrics)
• Business stakes -- what happens if this project fails?
• Your specific position and scope

What to EXCLUDE

• Company history or mission statement
• Team org chart beyond your immediate context
• Product features unrelated to your project

---

Part 3: Problem Statement (3 minutes)

The problem statement answers: "What made this HARD?" It is the most underrated section. A well-framed problem makes the audience lean in. A poorly-framed problem makes the solution feel arbitrary.

Template

The core challenge was [tension between competing requirements]:
- We needed [requirement A], which pushed us toward [approach type]
- But we also needed [requirement B], which conflicted because [reason]
- Existing solutions ([name them]) failed because [specific shortcoming]

The constraints were:
1. [Hard constraint: latency < X ms / budget < $Y / must use existing infra]
2. [Hard constraint: regulatory / compatibility / team skill limitations]
3. [Soft constraint: prefer familiar tech / minimize operational burden]

What made this non-trivial was [the key insight or tension]:
- Naive approach: [what most people would try first]
- Why naive fails: [specific failure mode with evidence]
- The real problem: [reframed understanding that leads to the solution]

Problem Framing Patterns

---

Part 4: Approach & Why (5 minutes)

This is NOT "what I built." This is "how I decided what to build." Interviewers care about your decision-making process more than the decision itself.

Template for Each Key Decision (Prepare 2-3)

Decision: [What you chose]

Alternatives considered:
1. [Alternative A]: Strong for [use case]. We rejected it because [specific reason
   in our context]. If [constraint] were different, this would have been better.
2. [Alternative B]: Industry standard for [similar problems]. Didn't fit because
   [specific technical mismatch].
3. [Alternative C]: We prototyped this for [duration]. Abandoned because
   [what we learned from the prototype].

What drove the final choice:
- Key constraint: [the one thing that tipped the decision]
- Key insight: [what we understood that others might not]
- What we knowingly sacrificed: [the tradeoff we accepted]

Validation:
- How we tested this decision: [prototype / benchmark / proof of concept]
- When we'd reverse it: [conditions under which this becomes wrong]

Decision Documentation Table

Prepare this for your top 3 decisions:

---

Part 5: Architecture Deep Dive (10 minutes)

The deep dive is where you demonstrate genuine understanding. You will NOT cover the entire system. You will pick 2-3 components and go deep enough that the interviewer says "okay, you clearly built this."

Component Selection

From your system architecture, pick components using this priority:

1. Components where YOU made a non-obvious decision (highest priority) 2. Components that broke or surprised you (high priority) 3. Components at the intersection of multiple concerns (good) 4. Components using interesting algorithms or data structures (good) 5. Standard infrastructure components (skip unless heavily customized)

Deep Dive Template (Per Component)

What it does: [1 sentence functional description]

Why it exists: [What problem does this component solve that couldn't be
solved by a simpler approach?]

How it works (key details only):
- [Internal mechanism 1]: [Why this way, not the obvious way]
- [Internal mechanism 2]: [The tricky part and how you solved it]
- [Performance characteristics]: [Big-O, latency, throughput]

What breaks:
- Failure mode 1: [What triggers it] -> [Impact] -> [Mitigation]
- Failure mode 2: [What triggers it] -> [Impact] -> [Mitigation]

What I learned:
- [Specific lesson from building/operating this component]

Depth Markers (How Interviewers Assess Depth)

Aim for "deep" on your 2-3 chosen components and "surface" on everything else.

---

Part 6: Results & Impact (3 minutes)

Metrics Template

Performance:
- [Metric]: [Before] -> [After] ([improvement %])
- [Metric]: [Before] -> [After] ([improvement %])

Business impact:
- [Revenue / cost / efficiency metric]: [Quantified change]
- [User metric]: [Quantified change]

Operational impact:
- [Reliability]: [Uptime / error rate improvement]
- [Developer experience]: [Deploy time / oncall burden change]
- [Adoption]: [Teams / services / users that adopted your work]

Impact Credibility Rules

• Use absolute numbers AND percentages: "Reduced latency from 340ms to 45ms (87% reduction)" -- the absolute numbers ground the claim.
• Distinguish correlation from causation: "Revenue increased 35% in the quarter after launch" is honest. "Our system drove 35% revenue growth" may not be -- attribution is hard. Be precise about what you can claim.
• Include negative results if they're interesting: "Accuracy improved 12% but training cost increased 3x, which led us to invest in model distillation."
• Scope your impact: "Within the detection pipeline" not "across the company" unless it truly was company-wide.

---

Part 7: What I Would Change (2 minutes)

This is the credibility section. Interviewers trust candidates who can critique their own work.

Template

If I were starting this project today, I would change [number] things:

1. [Decision]: I chose [X] because [rational reason at the time].
   Since then, [what changed -- new tooling, scale shift, team change, lesson learned].
   Today I would choose [Y] because [specific advantage in current context].

2. [Decision]: This was the right call at [scale/team/timeline] we had.
   At our current scale of [larger numbers], the bottleneck is now
   [specific problem]. I would redesign [component] to [specific change].

What I would NOT change:
- [Decision that aged well]: Despite [concern at the time], this has held up
  because [reason]. I'd make the same call again.

Common "What I'd Change" Categories

---

Part 8: Q&A Preparation

10 Likely Questions (Prepare Answers for All)

1. "Walk me through a request end-to-end." Prepare a 3-minute trace through the system for a single request. Include: entry point, key processing steps, data store interactions, response path. Mention error handling at each step.

2. "What was the hardest bug you encountered?" Pick a real bug. Structure: Symptom -> Investigation -> Root cause -> Fix -> Prevention. The investigation process matters more than the fix.

3. "How did you handle [specific challenge related to your project]?" For each component you go deep on, prepare the "how did you handle [obvious challenge]?" answer.

4. "What happens when [component X] goes down?" For each critical component, know: detection mechanism, impact blast radius, mitigation (circuit breaker, fallback, retry), and recovery procedure.

5. "Why this scale? What changes at 10x?" Know the scaling limits of your current design. Identify the first bottleneck at 10x load and the architectural change required.

6. "How did you test this?" Testing strategy: unit, integration, load, chaos. Be specific about what you tested and what you didn't. Acknowledge gaps honestly.

7. "What would a v2 look like?" Have a specific v2 vision that addresses current limitations. Not a fantasy rewrite -- a grounded evolution.

8. "How did you onboard new team members to this system?" Documentation, runbooks, pair programming, architecture diagrams. This reveals operational maturity.

9. "What's the operational cost?" Know your infrastructure cost (compute, storage, network), developer time for maintenance, and oncall burden. Even rough numbers show operational ownership.

10. "Tell me about a disagreement on the team about a technical decision." Pick a real disagreement. Structure: What was the disagreement, what was each side's argument, how was it resolved, what was the outcome, what did you learn.

---

Worked Example: Real-Time CV/Object Detection Pipeline at Scale

This example shows how a 15-year ML/systems engineer might structure a presentation about a production computer vision pipeline.

Context (2 min)

"I was a senior ML engineer at [Company], where we built autonomous inspection systems for industrial facilities. Our system processed video feeds from 2,000+ cameras across 40 sites, running real-time object detection to identify safety violations, equipment anomalies, and process deviations. We processed approximately 60,000 frames per second aggregate, with a hard constraint of 200ms end-to-end latency from frame capture to alert."

Problem (3 min)

"The core tension was between detection accuracy and edge deployment constraints. Our cameras were connected to edge devices with limited GPU memory -- NVIDIA Jetson units with 8GB shared memory. Research-grade detection models (Detectron2, large YOLOs) delivered 94% mAP but required 12GB VRAM. Models that fit on-device dropped to 78% mAP, which was below our contractual 85% threshold.

The naive approach was cloud inference: stream frames to a central GPU cluster. We prototyped this and hit two walls: (1) bandwidth cost at 60K FPS was $180K/month, and (2) network latency variability (50-400ms) broke our 200ms SLA at the P95.

The real problem wasn't 'make the model smaller.' It was 'redesign the pipeline so the edge device does less work but the overall system still meets accuracy and latency requirements.'"

Approach (5 min)

"We designed a two-tier inference architecture. The edge device runs a lightweight model (custom MobileNet-SSD variant, 82% mAP, 15ms inference) that acts as a first-pass filter. It classifies frames as 'interesting' or 'routine.' Only 'interesting' frames -- about 8% of total volume -- get sent to the cloud tier for high-accuracy inference.

We considered three alternatives: 1. Model distillation only: Distill the large model into a Jetson-compatible student. We prototyped this for 6 weeks. Got to 86% mAP but inference time was 45ms, which left too little headroom for the rest of the pipeline. 2. Temporal subsampling: Process every 5th frame, interpolate detections. Failed because industrial anomalies are often single-frame events (a spark, a pressure gauge spike). 3. Split inference: Run early layers on-edge, send intermediate features to cloud. Bandwidth was still too high for the feature maps (3x worse than just sending JPEG frames).

The two-tier approach won because it decoupled the accuracy problem from the latency problem. Edge handles latency (always responds in 15ms). Cloud handles accuracy (processes 8% of frames at 94% mAP within a relaxed 500ms window). The business logic merges both tiers' results."

Architecture Deep Dive -- Two Components (10 min)

Component 1: Edge Frame Classifier "The edge model needed to be fast, small, and biased toward recall over precision -- missing an interesting frame is worse than sending a boring frame to cloud. We modified MobileNet-SSD's confidence threshold to 0.3 (standard is 0.5), accepting more false positives. We then added a temporal smoothing layer: if 3 consecutive frames are 'interesting,' boost confidence. If an isolated frame triggers, require higher raw confidence (0.6). This reduced false positive cloud sends by 40% while maintaining 97% recall on actual anomalies.

The non-obvious part was calibrating per-camera. Factory floor cameras had different baseline activity than outdoor perimeter cameras. We built a per-camera calibration pipeline that ran the first 24 hours in 'learn mode,' establishing normal activity distribution, then set camera-specific thresholds."

Component 2: Cloud-Edge Result Fusion "When both tiers produce detections for the same timeframe, we need to merge them without double-counting or dropping either tier's unique detections. We implemented a spatial-temporal matching algorithm: detections within 50 pixels and 500ms are considered the same object. Cloud detection takes priority for classification confidence; edge detection takes priority for temporal localization (since it processes every frame).

The hardest bug was clock drift between edge and cloud. Edge devices ran NTP but could drift 200ms over hours. This caused the matcher to either duplicate detections or drop edge-only detections that arrived 'too late.' We solved it with a per-device clock offset estimator that used the cloud inference results as ground truth timestamps."

Results (3 min)

"End-to-end accuracy: 91% mAP (up from 78% edge-only, within 3% of cloud-only 94%). Latency: P50 = 22ms, P95 = 180ms, P99 = 350ms (within 200ms SLA at P95). Bandwidth cost: $14K/month (down from $180K projected for full cloud). Detection coverage: 97% recall on safety-critical events (up from 89% edge-only).

The system processed production traffic for 14 months with 99.7% uptime. Three major incidents, all related to edge hardware failures (GPU thermal throttling in desert installations), not software."

What I Would Change (2 min)

"Two things. First, the per-camera calibration pipeline was too manual. It required 24 hours of 'learn mode' and a human to verify the thresholds. Today I would use an online learning approach that continuously adapts thresholds using cloud inference results as a supervisory signal. We had the data for this but not the engineering time.

Second, I would invest in model versioning infrastructure from day one. We deployed 6 model versions over 14 months, and each deployment was a manual, site-by-site process. I'd build an OTA model update system with canary deployments and automatic rollback. The operational burden of coordinating 2,000 edge devices manually was the single biggest time sink on the team."

Whiteboard Diagrams for Technical Presentations

How to draw effective system architecture diagrams during interview presentations. The whiteboard is not decoration -- it is a communication tool that anchors the conversation, prevents misunderstanding, and gives you a physical reference point when answering follow-up questions.

---

Core Principle: Progressive Disclosure

Never draw the full system at once. Start with 3 boxes and add detail only when the conversation demands it. A diagram with 15 boxes drawn at the start overwhelms the audience and removes your ability to control the narrative.

Three-Phase Drawing Strategy

Phase 1: The 3-Box Overview (draw during Context/Problem)

[Input Source] ---> [Your System] ---> [Output / Consumer]

This is the highest-level abstraction. Examples:

• [Camera Feeds] ---> [Detection Pipeline] ---> [Alert Dashboard]
• [User Query] ---> [Search Engine] ---> [Ranked Results]
• [Raw Events] ---> [Processing Pipeline] ---> [Analytics DB]

Draw this in the first 2 minutes. It grounds the audience. Everything else is a zoom-in.

Phase 2: Expand the Middle Box (draw during Approach & Why)

Break "Your System" into 3-5 internal components. Only the ones you will discuss. Leave out standard infrastructure you plan to skim.

[Input] ---> [Component A] ---> [Component B] ---> [Component C] ---> [Output]
                  |                                      |
                  v                                      v
             [Data Store]                          [Model Store]

Draw this as you explain your approach. Each box appears as you introduce the component.

Phase 3: Zoom Into 2-3 Components (draw during Architecture Deep Dive)

For each deep component, draw a sub-diagram near the relevant box. Use a different region of the whiteboard so the overview stays visible.

[Component B - Detail]
+----------------------------------+
|  Request -> Validation -> Route  |
|       |                    |     |
|       v                    v     |
|  [Cache Check]      [Model Infer]|
|       |                    |     |
|       +-----> Merge <------+     |
|               |                  |
|               v                  |
|          [Response]              |
+----------------------------------+

---

Standard Notation

Use consistent symbols so the audience builds a mental vocabulary.

Labeling Rules

• Every box gets a name (2-4 words max). Not "the service that handles incoming requests and validates them" -- just "API Gateway."
• Arrows get labels for non-obvious flows. user request is obvious. confidence > 0.8 is not -- label it.
• Data stores get the technology name. "PostgreSQL" not "database." "Redis" not "cache." Specificity signals ownership.
• Write data format on arrows when it matters. JSON / 200 req/s or protobuf / 50MB batches. This shows you think about real-world constraints.

---

Color and Shading Strategy

Most interview whiteboard setups provide 3-4 marker colors. Use them intentionally.

Color Assignment (Physical Whiteboard)

If Only Black is Available

Use these differentiation techniques:

• Line weight: Thick borders for your deep-dive components, thin for context
• Fill patterns: Hash marks inside boxes you own, empty for others
• Underline: Underline the component name you're about to discuss
• Asterisk: Mark components with known failure modes

Virtual Whiteboard (tldraw, Excalidraw)

For remote interviews with digital whiteboards:

---

Space Management (Physical Whiteboard)

Board Layout

Divide the whiteboard into regions before you start drawing:

+----------------------------------------------------------+
|                                                          |
|   [OVERVIEW DIAGRAM]              [ZOOM-IN AREA 1]      |
|   (left 60%)                      (upper right 40%)     |
|                                                          |
|                                   [ZOOM-IN AREA 2]      |
|                                   (lower right 40%)     |
|                                                          |
+----------------------------------------------------------+
|   [METRICS / NUMBERS]   (bottom strip, 15% of board)    |
+----------------------------------------------------------+

Space Rules

• Never fill more than 70% of the whiteboard. You need room for Q&A additions.
• Leave the overview visible even as you add zoom-ins. Interviewers will point at the overview and ask about specific components.
• Reserve the bottom strip for metrics, numbers, and quick calculations you do during Q&A.
• Erase zoom-ins when done if you need the space for a different component. The overview should persist for the full session.

Erasing Strategy

• Erase zoom-in detail after discussing it and before drawing the next zoom-in (recycles space)
• NEVER erase the overview diagram (it's the anchor)
• If you make a mistake, erase and redraw. Do not scribble over errors -- it looks worse

---

Common Diagram Patterns

Pattern 1: Request Flow (API / Web Service)

[Client] --> [Load Balancer] --> [API Server] --> [Business Logic]
                                      |                |
                                      v                v
                                 [Auth Service]  [Database]
                                                     |
                                                     v
                                               [Cache Layer]

Use when: Presenting a web service, API, or request-response system. Deep dive targets: Business logic layer, caching strategy, auth mechanism.

Pattern 2: Data Pipeline (ETL / Streaming)

[Sources]     [Ingestion]     [Processing]     [Storage]     [Serving]
  S1 ---+
  S2 ---+--> [Kafka] -----> [Spark/Flink] ---> [Data Lake] --> [Query Engine]
  S3 ---+                       |                                    |
                                v                                    v
                          [Dead Letter]                       [Dashboard]
                          [Queue]

Use when: Presenting data engineering, ETL, analytics, or streaming systems. Deep dive targets: Processing logic, data quality checks, failure handling / DLQ.

Pattern 3: ML Training Loop

[Raw Data] --> [Feature Engineering] --> [Training Pipeline] --> [Model Registry]
                      |                        |                       |
                      v                        v                       v
               [Feature Store]          [Experiment Tracker]    [Model Serving]
                                        (MLflow / W&B)               |
                                                                     v
                                                              [A/B Framework]
                                                                     |
                                                                     v
                                                              [Production Traffic]

Use when: Presenting ML infrastructure, model training, or MLOps work. Deep dive targets: Feature engineering pipeline, training pipeline (data loading, distributed training), model serving (batching, caching, canary deployment).

Pattern 4: ML Serving Architecture

[Request] --> [Feature Lookup] --> [Model Server] --> [Post-Processing] --> [Response]
                   |                     |                    |
                   v                     v                    v
             [Feature Cache]      [Model Cache]        [Business Rules]
             (Redis, 15min TTL)   (in-memory)          (threshold, filter)
                   |
                   v
             [Feature Store]
             (offline computed)

Use when: Presenting production ML inference, recommendation systems, or real-time prediction services. Deep dive targets: Feature lookup latency optimization, model serving (batching strategy, hardware allocation), post-processing rules.

Pattern 5: Two-Tier / Edge-Cloud Architecture

           EDGE (per device)                      CLOUD (centralized)
+-------------------------------+    +-----------------------------------+
| [Sensor] --> [Light Model]    |    | [Heavy Model] --> [Fusion Logic] |
|                |               |--->|       ^                |         |
|                v               |    |       |                v         |
|         [Local Decision]       |    | [Batch Queue]   [Alert System]  |
|                |               |    |                                  |
|                v               |    |                                  |
|         [Local Action]         |    |                                  |
+-------------------------------+    +-----------------------------------+

Use when: Presenting IoT, edge computing, mobile ML, or distributed inference systems. Deep dive targets: Edge model constraints and tradeoffs, cloud-edge communication protocol, result fusion logic.

---

Timing: When to Draw vs When to Talk

Drawing Speed

• Practice drawing your overview diagram until you can do it in under 30 seconds
• Practice drawing each zoom-in diagram until you can do it in under 60 seconds
• If a diagram takes more than 90 seconds to draw, simplify it
• It is better to draw quickly and slightly messy than slowly and perfectly -- momentum matters

---

Physical Whiteboard Tips

Marker Technique

• Hold the marker at a 45-degree angle for consistent line width
• Use the flat side for thick lines (borders), the tip for thin lines (arrows)
• Cap markers when not in use -- dried-out markers ruin presentations
• Bring your own markers if the room's markers might be unreliable

Body Position

• Stand to the side of what you're drawing, not in front of it
• Use your non-writing hand to point at the diagram while explaining
• Face the audience when talking, face the board only when drawing
• Step back periodically so the audience can see the full picture

Recovery Moves

• Wrong box placement? Don't erase and redo -- draw an arrow to the correct location and label it. Shows adaptability.
• Ran out of space? Erase a zoom-in you've finished discussing.
• Messy handwriting? Slow down. Write in block letters. Bigger is better.
• Forgot a component? "Let me add one more piece I should have included" -- then draw it. Honesty > perfection.

---

Virtual Whiteboard Tips

Tool Selection (in order of preference for interviews)

1. Excalidraw (excalidraw.com) -- Hand-drawn aesthetic, collaborative, free, no account needed 2. tldraw (tldraw.com) -- Clean, fast, minimal UI 3. Miro -- If the company provides a Miro board (common for larger companies) 4. Google Jamboard -- Simple but limited (sunsetted in some orgs)

Remote-Specific Techniques

• Pre-draw the 3-box overview 5 minutes before the interview starts. Having the overview ready when you begin saves time and shows preparation.
• Use snap-to-grid if available. Alignment is free professionalism.
• Duplicate, don't redraw. When expanding a component, copy-paste the overview and modify. Faster and preserves layout.
• Share your screen, not the whiteboard tool. Screen sharing gives you control. Collaborative editing can lead to accidental moves.
• Zoom to fit after each major addition so the interviewer sees the full picture.
• Use sticky notes / text boxes for labels rather than the draw tool. More readable on small screens.

Bandwidth Considerations

• If video quality is poor, describe what you're drawing as you draw it: "I'm adding a cache layer between the API server and the database..."
• Offer to paste a text-based diagram in chat if the visual tool isn't working
• Have a backup plan: a pre-made diagram image (PNG) you can screen-share if the collaborative tool fails

---

Common Drawing Mistakes