tech-presentation-interview

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

技术展示轮是一种reverse system design：不同于在白板上设计假设性系统，你需要展示自己实际搭建过的真实系统。这一轮测试的是其他面试轮次无法覆盖的三个维度：对技术的真实理解深度、压力下复杂想法的沟通能力，以及对项目的真实主导权而非被动继承的知识。

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)

适用场景：

从你的职业生涯中选择要展示的项目
搭建时长25-45分钟、具备叙事逻辑的技术展示内容
校准展示深度——哪些组件需要深入讲解，哪些可以略过
准备白板/虚拟白板绘图，采用渐进式披露方式
演练如何应对尖锐的后续提问
根据不同听众调整展示内容（研究员、工程师、管理者）

不适用场景：

设计你未参与搭建的系统（请使用
```
ml-system-design-interview
```
）
撰写简历或提取职业故事（请使用
```
cv-creator
```
或
```
career-biographer
```
）
协调多轮面试安排（请使用
```
interview-loop-strategist
```
）
练习编程题或行为类STAR故事
准备会议演讲（格式不同，评估标准也不同）

Project Selection

项目选择

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

mermaid

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]

最常见的失败原因是选错了项目。请使用以下决策树：

mermaid

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.

为每个候选项目打1-5分：

评估标准	权重	评估要点
个人主导权	5倍	你做出的决策，而非团队共识或继承的架构
技术复杂度	4倍	非显而易见的权衡、规模挑战、算法深度
值得探讨的故障	4倍	出现过的故障、意外情况、转向决策、经验教训
与目标岗位的相关性	3倍	与目标团队的工作内容重叠度
可量化的影响	2倍	可引用的指标（延迟、吞吐量、营收、准确率）
项目时效性	1倍	越近期越好，但优秀的5年前项目仍优于平淡的近期项目

阈值：总分>60分=优质选择；40-60分=若无更好项目可接受；<40分=更换项目。

Narrative Arc Framework

叙事结构框架

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

mermaid

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

优秀的展示都遵循以下结构，偏离会导致听众注意力流失。

mermaid

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

1. 背景（2分钟）——搭建场景。用户是谁？业务是什么？为什么这个项目重要？

一句话介绍公司/团队
一句话说明用户问题
一句话说明规模（每秒请求数、数据量、用户数）
不要以「我搭建了一个服务...」开头——从问题切入

2. 问题（3分钟）——这个项目的难点是什么？不是你搭建了什么，而是它为什么非比寻常。

制造矛盾的约束条件（延迟vs准确率、成本vs可靠性）
现有解决方案为何无效
失败会导致什么后果（明确风险）

3. 方案与原因（5分钟）——决策过程，而非仅仅是决策结果。

你考虑过的2-3种替代方案，以及为什么放弃它们
驱动你选择的核心洞察或约束条件
你优先优化的目标（以及主动牺牲的部分）

4. 架构深度剖析（10分钟）——深入讲解2-3个组件，而非走马观花介绍每个模块。

在白板上先画3个模块的概览图（参考
```
references/whiteboard-diagrams.md
```
）
挑选2-3个技术上有亮点的组件展开讲解
每个深入讲解的组件：功能是什么、为什么这样设计、修改后会出现什么问题
渐进式披露：仅在相关或被询问时添加细节

5. 结果与影响（3分钟）——可量化的成果。

前后对比指标（延迟、吞吐量、准确率、成本、开发时长）
业务影响（营收、用户量、客户满意度）
团队影响（ adoption、开发者体验、运维负担）

6. 改进方向（2分钟）——最重要的2分钟。

1-2个你事后会推翻的具体技术决策
当时做出该决策的合理性（在当时是理性选择）
哪些认知改变让你现在有不同想法
这部分比所有成果更能建立你的可信度

7. 问答环节（15+分钟）——真正的评估在此阶段进行。

参考下文「应对深度追问」部分

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.

最致命的错误是浅尝辄止地覆盖所有内容。选择2-3个层面深入讲解。

组件类型	略讲（1-2句话）	中等深度（2-3分钟）	深入讲解（5+分钟）
标准基础设施（负载均衡器、CDN）	几乎总是略讲	仅在自定义配置时展开	除非项目核心就是该基础设施
数据存储层	若为标准SQL/NoSQL则略讲	涉及分片、复制或混合架构时展开	若你设计了存储引擎则深入讲解
ML模型架构	若为现成模型则略讲	涉及微调或修改时展开	若为自定义架构或新颖方法则深入讲解
数据管道	若为标准ETL则略讲	涉及实时处理或复杂转换时展开	若你解决了棘手的数据质量问题则深入讲解
API/接口设计	若为标准REST/GraphQL则略讲	涉及复杂版本控制或契约时展开	若协议设计是核心挑战则深入讲解
监控/可观测性	通常略讲	若异常检测是核心则展开	除非项目核心就是该系统

经验法则：在你做出非显而易见决策的部分深入讲解；对于你按行业标准方式使用标准工具的部分略讲。

Handling Deep Follow-Ups

应对深度追问

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

问答环节是面试官区分真正搭建者和旁观者的关键。准备好应对以下常见模式：

"Tell me more about X"

「详细讲讲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]."

这是邀请，而非陷阱。深入一层讲解实现细节。
结构：「X的核心挑战是[约束条件]。我们通过[方案]解决，因为[原因]。棘手的部分是[非显而易见的细节]。」
如果你确实不记得某个细节：「我需要查阅具体内容，但设计原则是[原则]，实现遵循[模式]。」

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

永远不要说「没有」。这是最重要的问题。
准备2-3个具体的技术改进及理由。
结构：「基于现在的认知，我会改变[具体决策]。当时，[做出该决策的合理性]。从那以后，[变化的因素——新工具、学到的经验、规模变化]。新方案会是[具体替代方案]。」

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

描述实际发生过的故障，而非假设情况。
结构：「主要故障模式是[X]。我们遇到过[频率]。发生时的影响是[影响]。我们的缓解方案是[方案]。剩余风险是[仍未覆盖的部分]。」

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

根据听众调整展示深度：

听众群体	重点强调	弱化内容
研究员/科学家	新颖方案、评估方法、消融实验	基础设施细节、部署运维
后端/系统工程师	规模、可靠性、性能权衡、故障处理	ML模型内部细节、业务背景
ML工程师	模型架构、训练管道、数据挑战、服务基础设施	业务影响、团队动态
工程经理	决策过程、团队协作、技术风险管理	底层实现细节
混合评审团	先从广度入手，通过问答了解每位评审的深度需求	不要预先针对单一听众优化

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.

新手：所有内容都用「我们」。「我们设计了架构。」「我们选择了Kafka。」「我们解决了延迟问题。」无法明确区分自己的具体贡献、团队集体工作以及队友的独立成果。专家：全程明确标记所有权：「我主导了服务层的设计，与数据团队协作搭建了管道，我的队友Sarah负责模型训练基础设施。让我聚焦于服务层，因为这是我的主要贡献。」用「我」指代自己主导的决策，「我们」指代真正的协作，提及队友的贡献。 识别特征：在追问下无法详细解释具体技术决策。当被问到「为什么选Kafka而不是RabbitMQ？」时，回答「这是团队的决定」或给出通用的教科书式对比，而非自己做的具体评估。

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.

新手：浅尝辄止地覆盖每个组件。「然后我们有缓存、队列、数据库、负载均衡器、模型服务器、特征存储...」每个组件只讲1-2句话。还没讲到有趣的部分就超时了。白板看起来像繁忙的地铁线路图。专家：画出3模块概览图，明确说明「我将聚焦于两个有工程亮点的组件」并深入讲解。花5分钟讲解一个组件的权衡、考虑过的替代方案、故障模式以及学到的经验。面试官离开时能彻底理解该组件。 识别特征：展示超时。所有组件描述都是表面层次。白板有15+个模块，没有重点放大区域。当被要求深入讲解任何单个组件时，候选人没有额外内容可讲。

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.

独自演练（至少3次）：对着空房间展示并计时。目标：结构化部分20-25分钟，预留15-20分钟用于问答。
录制自己：观看录像。注意填充词、含糊其辞的部分以及思路中断的时刻。
同伴模拟（至少2次）：给技术朋友展示。让他们扮演尖锐的提问者。记录你答不上来的问题。
问答压力测试：让别人从尖锐问题列表中快速提问10个问题。练习在压力下保持冷静。
时间把控：如果演练中结构化部分超过25分钟，删减内容。实际面试中你会花更长时间。

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

文件	使用场景
`references/project-narrative-template.md`	从零开始搭建项目展示内容；填充叙事结构；准备问答答案；ML管道展示的示例
`references/whiteboard-diagrams.md`	规划展示时的绘图内容；渐进式披露策略；实体和虚拟白板技巧；ML系统常见绘图模式