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:

Criterion Weight What to evaluate

Personal ownership 5x YOUR decisions, not team consensus or inherited architecture

Technical complexity 4x Non-obvious tradeoffs, scale challenges, algorithmic depth

Interesting failures 4x Things that broke, surprises, pivots, lessons learned

Relevance to role 3x Overlaps with what the target team builds

Quantified impact 2x Metrics you can cite (latency, throughput, revenue, accuracy)

Recency 1x More recent is better, but a great 5-year-old project beats a boring recent one

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.

Component Type Skim (1-2 sentences) Medium (2-3 min) Deep (5+ min)

Standard infra (load balancer, CDN) Almost always skim Only if custom config Never unless this IS the project

Data storage layer If standard SQL/NoSQL If sharding, replication, or hybrid If you designed the storage engine

ML model architecture If off-the-shelf If fine-tuned or modified If custom architecture or novel approach

Data pipeline If standard ETL If real-time or complex transforms If you solved a hard data quality problem

API/interface design If REST/GraphQL standard If complex versioning or contracts If protocol design was the core challenge

Monitoring/observability Usually skim If anomaly detection is core If this IS the system

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:

Audience Emphasize De-emphasize

Researchers / scientists Novel approaches, evaluation methodology, ablation studies Infra details, deployment ops

Backend / systems engineers Scale, reliability, performance tradeoffs, failure handling ML model internals, business context

ML engineers Model architecture, training pipeline, data challenges, serving infra Business impact, team dynamics

Engineering managers Decision-making process, team coordination, technical risk management Low-level implementation details

Mixed panel Start broad, let Q&A reveal where each panelist wants depth Don't pre-optimize for one audience

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

• 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.

• Record yourself: Watch the recording. Note filler words, hand-waving over gaps, and moments where you lose the thread.

• Peer mock (2x minimum): Present to a technical friend. Have them play hostile questioner. Track which questions you fumble.

• Q&A stress test: Have someone rapid-fire 10 questions from the hostile questions list. Practice composure under pressure.

• Timing gate: If your structured presentation exceeds 25 min in rehearsal, cut content. You WILL run longer in the real thing.

Reference Files

File Consult When

references/project-narrative-template.md

Structuring a project presentation from scratch; filling out the narrative arc; preparing Q&A answers; worked example of an ML pipeline presentation

references/whiteboard-diagrams.md

Planning what to draw during the presentation; progressive disclosure strategy; physical and virtual whiteboard tips; common diagram patterns for ML systems