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]."