11.1 技术面试的英语挑战
技术面试是程序员英语的"奥林匹克级"场景:
- 5 个轮次,每轮 45-60 分钟,全英文。
- 同时多任务:写代码 + 解释思路 + 听问题 + 心算复杂度。
- 第一印象决定大半:面试官在前 5 分钟形成 80% 的判断。
- 无法 ChatGPT:临场说不出来就是说不出来。
但好消息是:技术面试的英语极度可预测。同样的几十个问题反复出现,同样的几十个套路反复用。背熟脚本 + 多场练习 = 显著进步。
11.2 "Tell me about yourself" 的程序员版
这是 80% 面试的开场。一份好答案应该 60-90 秒,包含 5 个组件:
1. 当前角色 + 公司 + 类型 (10s)
"I'm a backend engineer at <Company>, a fintech that <tagline>."
2. 核心技术栈 + 系统规模 (15s)
"I work mostly on the payments service — Go microservices
handling 5M transactions per day, deployed on Kubernetes
across three regions."
3. 一个 highlight 项目 (20s)
"Most recently, I led the migration from MySQL to TiDB. We
were hitting write hotspot issues at peak — the migration
cut p99 write latency from 280ms to 35ms and let us drop
our sharding logic. I owned the design, the rollout plan,
and ran the cutover."
4. 为什么对这个职位感兴趣 (10s)
"What excites me about <Target Company> is <specific reason
based on research>. I've been particularly interested in
<their tech blog post / open source project>."
5. 收尾,把球抛回 (5s)
"Happy to dig into any of those — where would you like to
start?"
关键句型可替换
# 当前角色
"I'm currently a senior engineer at ..."
"I lead a team of 5 working on ..."
"My current role is ..."
"For the past N years I've been at ..."
# Highlight 转入
"The project I'm most proud of recently is ..."
"One thing I've been heads-down on lately ..."
"A highlight from this past year was ..."
# 表达兴趣
"What draws me to this role is ..."
"I'm particularly excited about ..."
"What I'd love to learn more about is ..."
# 收尾
"Happy to expand on any of these."
"That's the short version — happy to go deeper on any part."
"Where would you like me to elaborate?"
11.3 System Design 面试
System Design 是高级岗位最重要的轮次。它考的不是知识——是你的沟通结构。一份好的 System Design 答题分 5 阶段:
阶段 1:Clarify (5 min)
# 标准开场
"Before I dive in, let me make sure I understand the problem.
You'd like me to design X. A few questions to scope this:"
# 范围问题
"What's the expected scale? DAU? Peak QPS?"
"Read-heavy or write-heavy?"
"Are we optimizing for latency or throughput?"
"What's the geographic distribution?"
"Any specific consistency requirements (strong / eventual)?"
# 功能问题
"What are the must-have features vs nice-to-haves?"
"Should I assume mobile, web, or both?"
"Is there a SLA target — 99.9? 99.99?"
# 约束问题
"Any tech stack constraints? Existing infra to integrate with?"
"What's the budget timeline?"
阶段 2:Estimate (5 min)
# 量级估算
"Let's do some back-of-envelope math.
If we have 100M DAU and each user posts 1 photo per day on
average, that's 100M writes/day = ~1200/s sustained, with peaks
of ~5x = 6000/s.
Each photo at 500 KB = 50 TB/day storage, or about 18 PB/year.
Reads typically dominate — assume 100:1 read:write, so ~120k
read QPS.
Bandwidth: at peak read, 120k × 500 KB ≈ 60 GB/s, which we'll
need a CDN for."
阶段 3:High-level (10 min)
# 画框图,从入口到存储
"At a high level, the path is:
Client → CDN → Load Balancer → API Gateway → App Servers →
Cache (Redis) → DB (Postgres + S3 for blobs)
Let me walk through each layer..."
"For the core service, I'm thinking ..."
"There are three main subsystems:
1. Upload service (handles photo POST)
2. Feed service (returns user's timeline)
3. Search service (fulltext on captions)
Let me start with the simplest one and build up."
阶段 4:Deep Dive (15 min)
# 让面试官引导深挖
"Where would you like me to go deeper? Database schema, the
caching strategy, or the upload pipeline?"
# 自己选一个 deep dive
"I'd like to dig into the feed generation since that's where
the interesting tradeoffs are. There are three approaches:
fan-out on write, fan-out on read, and a hybrid."
# 详细推理
"Fan-out on write: when user A posts, we push to all of A's
followers' inbox. Fast read, but for celebs with 10M followers
each post triggers 10M writes. Doesn't scale.
Fan-out on read: at read time, query all followed users'
recent posts and merge. Slow read, but write is O(1).
Hybrid: fan-out on write for normal users, fan-out on read
for celebs. Most production systems converge on this."
阶段 5:Tradeoffs & Wrap (5 min)
# 自我审视
"Let me play devil's advocate against my own design."
# 总结 tradeoff
"The main tradeoffs in this design:
- Chose Postgres over Cassandra: stronger consistency,
but harder horizontal scaling above 10TB.
- Chose Kafka over SQS: lower latency and replay capability,
but more ops overhead.
- Hybrid fan-out: handles celebs but adds complexity in
the merge logic."
# 没说的部分
"Things I haven't covered: monitoring, security, deployment.
Happy to go into any of those if we have time."
System Design 高频术语
# 性能
latency, throughput, QPS, RPS, p50/p95/p99,
bandwidth, IOPS, response time
# 扩展性
horizontal scale, vertical scale,
sharding, partitioning, replication,
load balancing, auto-scaling
# 可用性
uptime, SLA / SLO / SLI,
failover, redundancy, fault tolerance,
multi-region, active-active, active-passive
# 一致性
strong consistency, eventual consistency,
read-your-writes, monotonic reads,
linearizability, serializability
# CAP 相关
CAP theorem, PACELC,
consistency vs availability tradeoff
# 缓存
cache hit rate, cache miss, cache eviction,
LRU, LFU, TTL, cache stampede,
read-through, write-through, write-behind
# 数据库
ACID, BASE, OLTP, OLAP,
indexing, query planner, B-tree, hash index,
denormalization, materialized view,
N+1 query, hot partition
# 队列
message queue, pub/sub, fan-out,
at-least-once, at-most-once, exactly-once delivery,
dead letter queue, backpressure
# 微服务
service mesh, API gateway, circuit breaker,
bulkhead, retry with backoff,
distributed tracing, idempotency key
11.4 Coding 面试:Think-Aloud 句型
Coding 面试 50% 看代码,50% 看你 think-aloud(边想边说)。沉默写代码会被打低分——即使代码完全正确。
开场:Clarify Requirements
"Let me make sure I understand the problem.
The input is <X>, the output is <Y>, and the constraint is <Z>.
Is that right?"
"Quick clarifications:
- Can the input be empty?
- Can it have duplicates?
- Is the array sorted?
- What's the size constraint? n ≤ 10^4 or 10^9?"
"Could I work through a small example first to make sure I have
the spec right?"
分析阶段
# 提出多种思路
"My first instinct is brute force: for each pair, check ... That's
O(n²). Let me see if I can do better.
Could I sort first? If sorted, then ... O(n log n).
Or with a hash set, I can check existence in O(1), giving overall
O(n) at the cost of O(n) space.
Want me to start with the O(n) hash approach?"
# 选择并解释
"I'll go with the hash approach. The tradeoff: more space, but
O(n) time vs O(n²)."
编码阶段
# 边写边解释
"Starting with the function signature ..."
"I'll create a hash set to track seen values ..."
"For each element, I'll check if its complement is already in
the set ..."
# 遇到选择点
"I'm considering whether to use a Set or a Map here.
Set is enough since we only need membership; let me go with Set."
# 测试运行
"Let me trace through with the example to make sure this is
correct.
nums = [2, 7, 11, 15], target = 9.
First iteration: i=0, complement=7. Set is empty, add 2.
Second iteration: i=1, complement=2. 2 is in set. Return [0, 1].
Looks right."
错误恢复
# 发现 bug
"Hmm, this fails for the duplicate case. Let me trace through ...
Yeah, I see the issue. The set should be populated *after* the
check, not before. Let me fix that."
"I think there's an edge case with the empty input. Let me add
a guard at the top."
# 不知道时
"I'm drawing a blank on the exact API for that. The semantic I
want is <X> — could be `Map.entries()` or similar in JS. Let me
keep going with this pseudocode-ish version and we can fix the
syntax."
复杂度分析
"Let me analyze the complexity.
Time: O(n). We do one pass through the array, each operation is
O(1) for hash set ops.
Space: O(n) in the worst case where we add all elements before
finding a match.
Could we do better? Lower bound is Ω(n) since we have to read
each element. So O(n) is optimal for time. Space could be O(1)
if we sorted first, but that pushes time to O(n log n).
Tradeoff."
follow-up
# 主动提
"Some natural follow-ups: what if we wanted all pairs, not
just one? What if the input was a stream and didn't fit in memory?"
# 被问 follow-up
"Good question. Let me think for a second ...
For a stream, we couldn't keep all elements. We'd need ...
[approach + tradeoff]."
11.5 Behavioral 面试:STAR 法则程序员版
STAR = Situation / Task / Action / Result。每个回答 90-120 秒,结构如下:
S - Situation (15s)
"When I was at <company>, we had <context>."
T - Task (15s)
"My responsibility was <specific outcome>."
A - Action (60s) ← 重点,占大部分时间
"First I <X>, because <Y>.
Then I <X>, because <Y>.
The key decision was <X>."
R - Result (15s)
"As a result, <quantified outcome>.
I learned <reflection>."
常见 Behavioral 题型
| 题型 | 典型问法 | 选什么例子 |
|---|---|---|
| 冲突 | Tell me about a disagreement with a coworker. | 技术分歧 + 协商化解 |
| 失败 | Tell me about a time you failed. | 真实失败 + 学到什么 |
| 领导 | Tell me about leading a project. | 设计 + 协调 + 交付 |
| 影响力 | How did you convince others? | 用数据 / 原型 / 让步 |
| 反馈 | Tell me about hard feedback you got. | 真实反馈 + 改进 |
| 救火 | Tell me about a production incident. | 响应 + 修复 + postmortem |
| 歧义 | Tell me about an unclear problem. | 澄清 + 自驱 + 落地 |
| 优先级 | How do you prioritize? | 具体决策 + 取舍 |
STAR 实例:production incident
S: "Last quarter, we were rolling out a new caching layer to our
payments service. About two hours after the rollout, p99 latency
started climbing — from 80ms baseline to 800ms."
T: "I was the on-call engineer that night. My job was to stabilize
and root-cause."
A: "First step was to confirm impact — I checked dashboards: error
rates were normal but latency was sustained. So users were
completing payments but slowly. I made the call to roll back
within 5 minutes — better to lose new feature than degrade UX.
After rollback, latency returned to baseline within 30 seconds.
Then I dug into root cause. Looking at metrics, the cache hit
rate was *too low* — 12% instead of expected 85%. Turned out
our key generation was including a millisecond timestamp,
so every request was a unique key — basically a non-cache.
I fixed the bug, added a unit test that asserts cache key
stability across timestamps, and re-rolled the next morning
with a 1% canary."
R: "P99 dropped from 80ms to 18ms after the fix landed. The
incident lasted about 90 minutes total. The biggest learning
for me was that I'd been overconfident in the cache layer
before rollout — should have verified hit rate in staging
before going to prod."
11.6 反问环节:5 个高质量问题
"Do you have any questions for us?" 是面试的最后一个评估点。问得好可以挽回前面的失误。
对 hiring manager 问
"What does success look like for someone in this role at the
6-month mark? At the 1-year mark?"
"What are the biggest challenges the team is facing right now?"
"How does the team make technical decisions — RFC, design doc,
or organic discussion?"
"What's the on-call setup like? Frequency, expectations?"
对未来同事问
"What do you wish you had known before joining?"
"Walk me through what a typical day or week looks like for you."
"What's the engineering culture? More 'move fast' or 'measure twice'?"
"How does the team handle disagreements — especially across
seniority levels?"
对资深 / 总监问
"What's the biggest technical debt the org is carrying right now,
and what's the plan?"
"Where do you see the team / product in 18 months?"
"What's something you tried in the last year that didn't work?"
什么不要问
# 这些信息官网都有
"What does your company do?"
"How big is the team?"
# 这些显得你很功利
"How quickly can I get promoted?"
"Can I work fully remote?" ← 应该面试前问 recruiter
# 这些显得你紧张
"How did I do?" ← 等结果就好
11.7 Salary Negotiation
谈薪是非母语者最吃亏的环节,因为礼貌过度容易让 HR 觉得你"不会要"。
口头话术 — 收到 offer 后的第一回应
# Bad — 立即接受
"Thank you so much! I accept!"
# Good — 表达兴奋但不立即接受
"Thank you, I really appreciate the offer. The role and team
sound fantastic. Would you mind sending over the written offer
so I can review the details? I'd like to take a few days to
think it through."
邮件 - counter offer 模板
Subject: Following up on the offer
Hi <Recruiter>,
Thank you again for sending over the offer for the <role>
position. I'm genuinely excited about the team and the chance
to work on <specific project>.
I've been thinking carefully about the package, and I wanted to
share a few thoughts. Based on my research and the conversations
I've had with other companies for similar roles, the market for
<role + level> in <location> tends to be in the <range> range
for total comp.
Given my experience with <specific skill> and the impact I
delivered at <previous company> (e.g., <quantified result>),
I'd love to see if there's room to bring the base closer to
<target> and / or increase the equity component.
I want to be clear that I'm very interested in joining, and I'm
looking forward to figuring this out together.
Thanks!
<Your Name>
谈薪关键句型
# 表达兴趣 (必备前置)
"I want to be clear that I'm very interested in this role."
"This is my top choice."
# 提数字
"I was hoping we could get to <X>."
"My target range was <X to Y>."
"Based on competing offers, I'm seeing <X>."
# 软化
"Is there flexibility on <component>?"
"Would there be room to revisit <component>?"
"What's the typical band for this level?"
# 让步
"I could meet you at <X> if <sign-on / equity / vesting> could
move."
"I'm flexible on <component> if <other> can be improved."
11.8 100 个面试高频技术词汇
性能 / 规模(25 个)
scalability, throughput, latency, response time,
QPS / RPS, concurrent connections, bandwidth,
percentile (p50/p95/p99), tail latency,
hot path, cold path, hot key, hot partition,
cache hit rate, cache miss, eviction,
backpressure, degradation, saturation,
sharding, partitioning, replication,
load balancing, auto-scaling, capacity planning
分布式(25 个)
distributed system, microservice, monolith,
service mesh, sidecar, API gateway,
consistency, availability, partition tolerance,
strong / eventual / read-your-writes consistency,
linearizability, serializability,
quorum, leader election, consensus, Raft, Paxos,
2PC, saga pattern, idempotency,
at-least-once / at-most-once / exactly-once,
message broker, event sourcing, CQRS,
eventual consistency window, drift
数据存储(20 个)
OLTP, OLAP, ETL, ELT,
relational, document, key-value, time-series,
graph database, vector database,
ACID, BASE, transaction, isolation level,
read committed, repeatable read, serializable,
B-tree, LSM tree, hash index, bloom filter,
denormalization, materialized view, query plan,
N+1 problem
可靠性 / 安全(15 个)
availability, durability, reliability,
SLA, SLO, SLI, error budget,
circuit breaker, retry with backoff, jitter,
rate limit, quota, throttle,
authentication, authorization, RBAC,
encryption at rest / in transit, TLS,
threat model, attack surface
开发 / 部署(15 个)
CI / CD, blue-green deployment, canary,
feature flag, rollback, postmortem,
monitoring, observability, alerting,
metrics, logs, traces (the three pillars),
SRE, on-call, runbook,
toil, automation, infrastructure as code
11.9 面试前的 30 天训练计划
- Week 1: 准备 self-introduction(5 个版本:30s / 60s / 90s / 2min / 5min),录音听自己。
- Week 2: 写 10 个 STAR 故事(覆盖冲突 / 失败 / 领导 / 影响 / 反馈 / 救火 / 歧义 / 优先级),每个练 3 遍。
- Week 3: 做 5 道 LeetCode 题用英语 think-aloud,全程录音。
- Week 4: 做 3 道 System Design 题,每题完整 45 分钟模拟。和朋友 / pramp.com / interviewing.io 上的人做 mock。
// rule
"You can't fake fluency under pressure. You can only practice it." 面试英语不是临时抱佛脚——是 30 天每天 1 小时的肌肉训练。
11.10 本章小结
- Tell me about yourself:5 段式 60-90 秒,角色 / 技术栈 / highlight / 兴趣 / 收尾。
- System Design 5 阶段:Clarify / Estimate / High-level / Deep dive / Tradeoffs。
- Coding:think-aloud 必须,分析 / 选择 / 编码 / 测试 / 复杂度 / follow-up。
- Behavioral STAR:S/T 各 15s,A 60s,R 15s。准备 10 个故事覆盖核心题型。
- 反问:6 个月成功标准、技术决策流程、on-call、文化、debt。不问百度可知。
- 谈薪:表达兴趣 + 提数字 + 软化语气 + 互让。
- 词汇:100 个高频技术词覆盖 80% 面试场景。
- 30 天训练计划:每周一个主题,每天 1 小时。
下一章是本课程最后一章——AI 时代如何让英语能力 + AI 工具产生 1 + 1 > 2 的效果。