05-技术面试核心点

技术面试从来不是一场死记硬背的考试，而是一次解决问题能力的实战演习。面试官寻找的，不是行走的教科书，而是具备工程思维、能够权衡利弊并落地执行的未来同事。

前言：被重塑的面试标尺

步入 2025 年，技术面试的考察维度正在发生深刻的位移。

技术面试权重分布（2025 版）：

pie
    title 技术面试考察维度权重
    "编程基础" : 30
    "系统设计" : 30
    "AI 技术能力" : 20
    "工程实践" : 20

关键洞察：

AI 不再是选修课：在 2020 年，AI 可能只是加分项；但到了 2025 年，它占据了 20% 的权重。不懂 AI 工程化，意味着你自动放弃了五分之一的分数。
从 ” 怎么做 ” 到 ” 为什么 “：面试官不再满足于你 ” 会用 ” 某个框架，而是更看重你为何选择它（Trade-off）以及如何治理它（Engineering）。

本章导航：

graph TD
    A[技术面试] --> B[5.1 编程基础与算法]
    A --> C[5.2 系统设计]
    A --> D[5.3 AI 工程能力]
    A --> E[5.4 工程实践]
    A --> F[5.5 技术深度考察]

    B --> B1[数据结构<br/>代码品味<br/>复杂度分析]
    C --> C1[需求拆解<br/>架构决策<br/>性能优化]
    D --> D1[LLM 应用<br/>RAG/Agent<br/>模型调优]
    E --> E1[CI/CD<br/>可观测性<br/>技术债]
    F --> F1[追问到底<br/>广度扫描<br/>底层原理]

    style B fill:#3498db,stroke:#2980b9
    style C fill:#e74c3c,stroke:#c0392b
    style D fill:#f39c12,stroke:#e67e22
    style E fill:#2ecc71,stroke:#27ae60

5.1 编程基础与算法：不仅是智力题

为什么要考算法？

很多资深工程师会抱怨：” 工作中根本不写反转链表，面试造火箭，入职拧螺丝。” 但在面试官眼中，算法题是最高效的过滤器：

智力与逻辑：这是最公平的思维体操。
代码基本功：能不能写出 Clean Code，边界条件是否严谨。
抗压能力：在白板/共享屏幕的高压下，能否冷静思考。

残酷现实：大厂 100% 必考，中厂 70% 必考。算法是门槛，跨不过去，连展示架构能力的机会都没有。

数据结构深度理解

不要只背 API，要理解底层特性。

mindmap
  root((核心数据结构))
    Linear["线性结构"]
      Array["数组"]
        R_Access["随机访问 O(1)"]
        W_Array["插入删除 O(n)"]
      LinkedList["链表"]
        W_List["插入删除 O(1)"]
        R_List["不支持随机访问"]
      StackQueue["栈与队列"]
        Stack["栈 (LIFO)"]
        Queue["队列 (FIFO)"]
      SkipList["跳表"]
        RedisZSet["Redis ZSet 核心"]
        TimeComplex["时间复杂度 O(log N)"]
    Tree["树形结构"]
      BinaryTree["二叉树"]
        CompleteBT["完全二叉树"]
        BST["二叉搜索树"]
      BalancedTree["平衡树"]
        RBT["红黑树 (Java HashMap)"]
        AVL["AVL树 (严格平衡)"]
      MultiTree["多路查找树"]
        BPlus["B+树 (MySQL 索引)"]
        LSM["LSM树 (RocksDB)"]
      SpecialTree["特殊用途"]
        Heap["堆 (优先队列 TopK)"]
        Trie["Trie (前缀搜索)"]
    Graph["图结构"]
      Storage["存储方式"]
        Matrix["邻接矩阵 (稠密)"]
        List["邻接表 (稀疏)"]
      Algo["核心算法"]
        Traversal["BFS 与 DFS"]
        ShortestPath["Dijkstra 最短路径"]
        Topo["拓扑排序"]
    Hash["哈希结构"]
      HashMap["HashMap"]
        FindOne["查找 O(1)"]
        Conflict["链地址法解决冲突"]
      Dist["分布式与海量"]
        ConsistHash["一致性哈希"]
        Bloom["布隆过滤器 (去重)"]
        BitMap["BitMap (统计)"]

算法设计与优化

核心算法类型：

搜索与遍历：DFS（回溯、排列组合）与 BFS（层序遍历、最短路径）是基础中的基础。
动态规划（DP）：理解状态转移方程是关键。核心在于将大问题拆解为可复用的小问题（背包、子序列）。
贪心算法：局部最优解即全局最优解（区间调度、跳跃游戏）。
二分查找：不仅是查数，更是 ” 在有序/单调空间中快速定位边界 ” 的思想。

代码质量：从 ” 能跑 ” 到 ” 优雅 ”

面试官评审代码的 5 个维度：

维度	权重	考察点
正确性	40%	能否 AC，边界 Case 是否覆盖（空值、负数、溢出）。
效率	30%	时间/空间复杂度是否最优。
可读性	20%	变量命名是否达意，逻辑是否清晰。
健壮性	5%	异常处理，输入校验。
沟通	5%	能否边写边讲，思路是否顺畅。

代码品味对比：

❌ 平庸代码：

def f(a):
    r = []
    for i in range(len(a)):
        if a[i] % 2 == 0:
            r.append(a[i])
    return r

问题：命名无意义（f, a, r），逻辑啰嗦，缺乏类型提示。

✅ 专业代码：

def filter_even_numbers(numbers: List[int]) -> List[int]:
    """
    过滤列表中的偶数
    Time: O(n), Space: O(n)
    """
    if not numbers:
        return []
    return [num for num in numbers if num % 2 == 0]

亮点：命名清晰，类型标注，文档注释，Pythonic 写法，边界检查。

刷题策略与现场技巧

LeetCode 刷题路线：

基础期（2 周）：Top 100 Liked，覆盖数组、链表、树。
进阶期（4 周）：按标签刷，攻克 DP、回溯、图论。
模拟期（2 周）：手写代码（脱离 IDE），限时 30 分钟/题，边写边说。

面试现场黄金流程：

澄清问题（2 分钟）：确认边界（如 ” 数组会有重复吗？"" 空间复杂度有要求吗？”）。
阐述思路（3 分钟）：” 我打算用双指针…时间复杂度是 O(n)“。得到面试官认可后再动笔。
编写代码（15 分钟）：书写规范，边写边解释。
人工测试（5 分钟）：自己跑几个 Case（正常、边界、错误），不要等面试官找 Bug。
复杂度分析（2 分钟）：主动分析时间与空间消耗。

5.2 系统设计：从画图到决策

为什么系统设计这么重要？

算法考察的是编码能力，系统设计考察的是架构能力和技术判断力。职级越高，这部分的权重越重。

需求分析：别急着画图

最严重的错误：面试官刚出题 ” 设计一个短链接系统 “，你马上开始画数据库表结构。正确姿势：先沟通，明确系统边界。

4W1H 分析法：

What（功能）：核心功能是什么？需要做分析统计吗？链接会过期吗？
Who（规模）：QPS 多少？DAU 多少？读写比例？
When（性能）：延迟要求？一致性要求（强一致还是最终一致）？
How（约束）：预算限制？开发周期？

架构设计模式与分布式挑战

1. 架构演进：

从单体到微服务，再到 Serverless，每一步都是为了解决特定规模下的问题，而非为了拆分而拆分。

2. CAP 定理的抉择：

支付系统：选 CP（一致性优先），宁可短时间不可用，也不能账目对不上。
点赞系统：选 AP（可用性优先），数据短暂不一致没关系，但不能让用户点不动。

3. 分布式事务：

放弃 2PC/3PC（性能太差）。
推荐方案：
- TCC：适用于强一致性场景（如支付）。
- 本地消息表/Saga：适用于最终一致性场景（如订单履约），这是高并发下的主流选择。

性能优化思路：分层漏斗

优化不是哪里慢改哪里，要有层次感。

graph TD
    A[性能优化漏斗] --> B[架构层]
    B --> C[应用层]
    C --> D[缓存层]
    D --> E[数据库层]

    B --> B1[负载均衡<br/>读写分离]
    C --> C1[异步处理<br/>批量聚合]
    D --> D1[Redis<br/>本地缓存]
    E --> E1[索引优化<br/>分库分表]

    style D fill:#f39c12,stroke:#e67e22

优化案例：电商订单查询慢（800ms）

数据库层：加联合索引 (user_id, create_time) → 降至 150ms。
缓存层：引入 Redis 缓存热点数据（近 3 天订单）→ 命中后降至 20ms。
架构层：引入分库分表（按 UserID Hash），解决单表数据量过大问题。
应用层：将非核心字段的获取改为异步加载或并行调用。

高可用设计

三板斧：

冗余：没有任何单点（主从复制、多机房部署）。
熔断降级：当非核心服务挂掉时，自动切断，返回默认值，保住核心业务。
限流：令牌桶/漏桶算法，防止流量洪峰冲垮系统。

5.3 AI 工程能力：2025 年的分水岭

5.3.1 LLM 应用开发

基础：调用 API 谁都会。进阶：如何省钱、稳定、防注入。

成本优化的 3 板斧：

缓存（Caching）：对于重复问题，直接查 Redis，成本为 0。
模型路由（Model Routing）：简单任务（如意图分类）给 GPT-3.5/Haiku，复杂任务（如推理）给 GPT-4/Opus。能省 90% 的钱。
Prompt 蒸馏：精简 Prompt，去除废话，减少 Token 消耗。

5.3.2 RAG 系统设计

RAG (Retrieval-Augmented Generation) 是当前最落地的 AI 应用架构。

graph LR
    A[Query] --> B[检索 Retrieval]
    B --> C[重排 Rerank]
    C --> D[生成 Generation]

    subgraph 数据处理
    E[文档] --> F[切片 Chunking]
    F --> G[向量化 Embedding]
    G --> H[向量库]
    end

    H -.-> B

核心考点：

Chunking 策略：滑动窗口（Sliding Window）优于固定切分，避免切断上下文。
检索增强：混合检索（向量检索 + 关键词检索）通常比单一检索效果好，能弥补专有名词匹配的短板。
重排序（Reranking）：在粗排检索出的 Top 50 结果中，用精排模型选出 Top 3，这是提升准确率的关键一步（Cost 增加，Accuracy 大增）。

5.3.3 Agent 开发

Agent = LLM + Memory + Planning + Tools

核心模式：ReAct (Reasoning + Acting) LLM 不再只是生成文本，而是：思考 → 选择工具 → 执行工具 → 观察结果 → 再思考。

Tool Calling 实战：不要让 LLM 瞎编，要让它调用确定的 API。

场景：查询天气。
LLM：识别意图 → 生成 JSON { "tool": "get_weather", "args": { "city": "Beijing" } } → 代码执行 API → 返回结果给 LLM → LLM 生成最终回复。

5.3.4 模型选择与评估

开源 vs 闭源：

数据敏感/内网环境：必选开源（Llama 3, Qwen, DeepSeek），自部署。
快速验证/效果优先：首选闭源（GPT-4, Claude 3.5），API 调用。

微调（Fine-tuning）vs RAG：

缺知识（如公司内部文档）：用 RAG。
缺格式/风格/特定任务能力（如法律文书撰写）：用 Fine-tuning。
很多时候，RAG + Few-shot Prompt 已经能解决 90% 的问题。

5.4 工程实践：职业素养的试金石

技术面试不只看代码写得快不快，更看你的工程素养好不好。

CI/CD 与自动化

原则：能自动化的绝不手动。

Pipeline：Lint → Unit Test → Build → Integration Test → Deploy to Staging → E2E Test → Deploy to Prod。
回滚策略：部署脚本必须包含自动健康检查，一旦失败立即回滚。

测试策略

测试金字塔：

单元测试（Unit）：70%。快，便宜，覆盖核心逻辑。
集成测试（Integration）：20%。测试模块间交互。
端到端测试（E2E）：10%。慢，贵，但模拟真实用户路径，保底线。

可观测性（Observability）

三大支柱：

Metrics（指标）：QPS、延迟、错误率。告诉你是什么出了问题。
Logs（日志）：错误堆栈、业务流水。告诉你为什么出问题。
Traces（链路追踪）：全链路调用图。告诉你问题在哪（哪个微服务慢）。

技术债管理

面试回答策略：不要说 ” 我们没有技术债 “（太假），也不要说 ” 技术债太多动不了 “（太乱）。✅ 优秀回答：” 我们遵循童子军原则（留下的营地要比来时更干净）。每个 Sprint 预留 20% 的资源偿还技术债，将重构融入日常开发，而不是堆积到不可收拾。“

5.5 技术深度考察：如何应对 ” 打破砂锅问到底 “

项目深挖框架（5-Why 法）

面试官会揪住你简历上的一个项目，层层剥皮。

graph TD
    A[Layer 1: What] --> B[Layer 2: Why]
    B --> C[Layer 3: How]
    C --> D[Layer 4: Problem]
    D --> E[Layer 5: Evolution]

    style A fill:#3498db,stroke:#2980b9
    style C fill:#e74c3c,stroke:#c0392b
    style E fill:#2ecc71,stroke:#27ae60

实战演练：

Layer 1 (What)：” 这是一个订单系统，日均 10 万单。”
Layer 2 (Why)：” 为什么选 Go 而不是 Java？“——回答：并发优势，资源占用低，团队技术栈匹配。
Layer 3 (How)：” 分布式事务怎么做的？“——回答：基于 RocketMQ 的事务消息实现最终一致性。
Layer 4 (Problem)：” 如果消息消费失败怎么办？“——回答：设计了死信队列和指数退避重试机制，最终人工介入。
Layer 5 (Evolution)：” 现在回头看，哪里可以做得更好？“——回答：当时为了上线快，索引设计有缺陷，导致后期查询慢。如果重来，我会引入 Elasticsearch 做复杂查询。

技术广度：T 型人才的横线

面试官可能会突然问一个跨领域问题，考察你的视野。

后端面 AI：” 你了解 Transformer 的基本原理吗？”
前端面后端：” 你了解 CDN 的回源机制吗？”

策略：保持好奇心，关注行业趋势（Serverless, Rust, Edge Computing）。对于不熟悉的领域，展示出 ” 虽然我没用过，但我读过相关文章，我的理解是…” 的学习态度。

🪴 X·Eden

探索

博客