总体评价
最强的能力是实际工程判断力。通常能快速识别正确的大方向：sliding window、KV + cache、distributed ID、质疑 migration 的理由、RAG/tool calling/validation。对 follow-up 的反应也很好——被挑战后通常能朝更强的答案靠拢。
最大的弱点是把直觉变成显式模型：
- Algorithm：知道 sliding window 但最初无法精确定义 invariant
- System Design：知道正确的组件但表达为零散的想法而非结构化的架构
- Behavioral：最强的事实——“I led the project”——在多轮 follow-up 之后才出现
- AI：知道很多组件但最初没有定义 reliability/evaluation loop
核心结论
最高价值的改进不是“学更多东西”，而是学会通过可重复的结构来回答。
所有面试类型背后都是同一个思维模式：
Define → Design → Prove → Risk → Result
| 类型 | Define | Design | Prove | Risk |
|---|---|---|---|---|
| Algorithm | 定义条件 | 设计算法 | 证明 invariant | Complexity / edge cases |
| System Design | 定义需求 | 设计架构 | 证明可扩展 | Failure / trade-offs |
| Behavioral | 定义问题 | 解释决策 | 证明自己的贡献 | Result / lesson |
| AI | 定义任务 | 设计 agent | 证明可靠性 | Safety / evaluation / cost |
各类型详细框架与示例
1. Algorithm
框架：Clarify → Approach → State/Invariant → Walkthrough → Complexity → Edge Cases
以 Minimum Window Substring 为例：
Clarify
“Before I start, I’d like to clarify two things. Can t contain duplicate characters? And if no valid window exists, should I return an empty string?”
Approach
“I think a sliding window is a good fit because we’re looking for the minimum contiguous substring satisfying a condition.
I’ll use two pointers, left and right. I’ll expand right until the window contains everything required by t. Once the window becomes valid, I’ll move left to shrink it as much as possible.“
State / Invariant
“I’ll maintain two frequency maps: need stores the required frequency of each character in t, and window stores the frequency inside the current window.
I’ll also maintain required, which is the number of distinct characters we need to satisfy, and formed, which is the number currently satisfied.
So the key invariant is: when formed == required, the current window contains everything required by t.“
Walkthrough
“For ADOBECODEBANC and ABC, I move right until I reach C. At that point A, B, and C are all satisfied, so the window is valid.
Then I move left and try to shrink it. Once removing a character makes its frequency lower than required, the window becomes invalid, so I start expanding right again.
Every time the window is valid, I compare its length with the best answer seen so far.“
Complexity
“Both pointers only move forward and each visits every position at most once, so the time complexity is O(n + m). Space complexity is O(k), where k is the number of distinct characters we track.”
Edge Cases
“Finally, I’d consider empty strings, t being longer than s, duplicate characters in t, and the case where no valid window exists.”
关键改进点：以后强迫自己回答 “What condition is always true in my algorithm?” 先定义 invariant，整个算法就清楚了。
2. System Design
框架：Requirements → Scale → API/Data Model → High-level Design → Deep Dive → Failures → Trade-offs
以 Design a URL Shortener 为例：
Requirements
“The system has two main operations: creating a short URL and redirecting a short URL. I’ll assume redirects are public, mappings are immutable, expiration is optional, and availability and redirect latency are important.”
Scale
“We have roughly 1 million new URLs and 100 million redirects per day, so the system is heavily read-oriented — roughly a 100-to-1 read/write ratio. That tells me caching will probably be important.”
API / Data Model
“POST /urls accepts the long URL and optional expiration time and returns a short code. GET /{shortCode} looks up the mapping and returns an HTTP redirect. The core data model is simple: shortCode -> longURL, createdAt, expiresAt. Since access is primarily key-based, a distributed KV store is a natural choice.”
High-Level Design
“Clients go through a load balancer to stateless application servers. The creation path talks to an ID generation service and then persists the mapping. The redirect path first checks a distributed cache. On a cache miss, it reads the KV database and populates the cache.”
Deep Dive
“The interesting problem is generating unique short codes. I would generate a globally unique numeric ID using something like a Snowflake-style generator and Base62-encode it. A Snowflake ID contains timestamp, worker ID, and sequence bits, so multiple machines can generate IDs independently.”
Bottlenecks / Failures
“If the cache goes down, traffic could suddenly hit the database and cause overload. I’d therefore use a distributed cache cluster, replication, and potentially request coalescing or rate limiting to protect the database.”
Trade-offs
“Random IDs versus Snowflake-style IDs. Random IDs make the architecture simpler but require collision handling. Snowflake avoids most collision concerns but requires worker-ID management and exposes some ordering information.”
关键改进点：不要太早进入 Redis/LFU/Base62 等实现细节。先在脑子里固定几个桶：Requirements → Numbers → API → Boxes → One hard problem → Failure → Trade-off。
3. Behavioral
框架：Situation → Challenge → Reasoning/Actions → Ownership → Result → Lesson
以 RDS → KV migration 的真实经历为例：
Situation
“In one of my previous projects, our service experienced several overload incidents caused by slow queries in RDS.”
Challenge
“My manager proposed migrating the metadata database from RDS to a KV store. I initially disagreed because the immediate problem was a slow SQL query. I believed adding the right index would solve the incident with much lower risk.”
Reasoning / Actions
“Instead of simply opposing the migration, I asked my manager what problem we were trying to solve beyond the immediate incident. Through that discussion, I learned that there was a broader architectural reason — our dominant access pattern was key-based, and related systems were already using KV.”
Ownership
“I still believed SQL optimization was sufficient for the immediate incident, but I agreed that KV was a better long-term direction. After we made that decision, I led the migration project. I designed the new architecture, implementation strategy, and zero-downtime migration plan. I also coordinated the production rollout with the SRE team.”
Result
“We completed the migration without service downtime, and the metadata service moved to an architecture that better matched its access pattern.”
Lesson
“The biggest lesson was that a technical disagreement can sometimes come from optimizing for different scopes. I was solving the immediate performance problem, while my manager was also considering long-term architectural consistency. Since then, when I disagree with a technical proposal, I first make sure I understand the broader goal before debating the implementation.”
关键改进点：
- 把 “I led the project” 提前，不要等 interviewer 第三个 follow-up 才发现
- Lesson 要升华到 senior engineer 层面的认知，而不只是“我做了这件事”
4. AI
框架：Requirements → Orchestration → RAG → Tools → Safety → Evaluation → Observability → Cost/Latency
以 Design an AI Customer Support Agent 为例：
Requirements
“I’d separate the agent’s responsibilities into two categories. First, answering informational questions using the company’s knowledge base. Second, performing actions such as checking an order or creating a support ticket. Actions can have different risk levels, so I’ll treat read-only and destructive operations differently.”
Orchestration
“I would put an agent service between the client and the LLM. The agent service manages conversation state and decides which capabilities are available to the model.”
Knowledge / RAG
“Documents are chunked, embedded, and stored in a vector database together with metadata. At query time, we retrieve relevant chunks and provide them to the model as context. I would also ask the model to ground factual answers in the retrieved sources.”
Tools
“For real-time information such as order status, I would not rely on RAG because the data can change. Instead, the model calls an order API through a tool. Tools have explicit schemas and descriptions.”
Safety / Validation
“I would never trust tool arguments generated by the model directly. The agent service validates the structured output against a schema and then applies business validation and authorization. Destructive operations require explicit user confirmation. I would also make mutation APIs idempotent.”
Evaluation
“I’d separately measure retrieval relevance, factual correctness, tool-selection accuracy, tool-argument accuracy, confirmation behavior, and end-to-end task success. I’d also include adversarial cases such as prompt injection.”
Observability
“I would trace the complete agent execution: user request, retrieval results, model decisions, tool calls, latency, and failures.”
Cost / Latency
“Simple classification or routing could use a smaller model, while more difficult reasoning could use a stronger model. I would also cache safe reusable retrieval results.”
关键改进点：回答要表达的不是 “我知道哪些 AI 技术”，而是 “我知道怎么把 AI 做成 production system”。
表达层面的改进
英语表达可以理解，但有时会在说话时修正句子——“API service, no, agent service”，“random character or, no, random string”——这让解释听起来比实际知识水平更缺乏信心。
改进方法：用更短的句子。说一个论点，停顿，然后解释。
例如，不要说：
“To prevent the LLM from hallucinating data, we should ask the LLM not guess and…”
而是说：
“I would not rely on prompting alone. I would use three safeguards. First, factual order information must come from tools. Second, tool arguments must pass schema and business validation. Third, destructive actions require explicit user confirmation.”
下一步行动
- 形成习惯：先定义问题，再给方案，再解释为什么方案成立，然后主动讲风险
- 每种题型练习用框架组织回答，而非只是给出正确的知识点
- 英语表达练习：短句，一个 claim 一个停顿，避免自我修正