技术电面遇到多 Part 编程题怎么办：比写出代码更重要的是推进节奏
技术电面遇到多 Part 编程题怎么办：比写出代码更重要的是推进节奏
现在很多技术电面不再是单纯一道 LeetCode。面试官会给一个业务场景，然后分成多个 part：先实现基础功能，再加统计、去重、时间范围、undo/redo、性能优化或 edge case。
这类题的特点是：每个 part 单独看不难，但时间很容易失控。很多候选人挂掉，不是因为完全不会，而是前面写得太慢、需求没问清、测试没覆盖，导致后面的 follow-up 没机会展示。
多 Part 题的第一目标是建立可扩展骨架
不要一上来写死某个 case。先识别题目后续可能扩展的方向。
例如日志统计题，第一 part 可能只是统计某些 API 的调用次数，后面可能加平均响应时间、中位数、路径归一化、忽略无关 endpoint。
如果你一开始把路径匹配写成很多硬编码 if，后面会很难改。更好的方式是先设计 endpoint pattern：
method + normalized_path → stats其中 normalized_path 把具体 user id 替换成占位符。这样无论后续统计 count、mean、median，都可以挂在同一个 stats object 上。
需求澄清要短，但必须问关键问题
多 Part 题里，澄清不能问太久，但有些问题必须问：
- 输入是否已经排序？
- 时间格式是什么？是否跨天？
- ID 是否可能重复？
- 重复记录要算一次还是多次？
- 不匹配的数据是忽略还是报错？
- 返回格式有没有要求？
- 如果没有结果，返回空对象、0 还是 null？
- 是否要求代码可运行并通过测试？
问这些问题不是拖时间，而是避免后面返工。
去重和时间范围是高频陷阱
很多业务题会出现“unique user”“unique pin”“date range”“time window”这类要求。这里最常见的错误是把 record 数量当成 entity 数量。
例如统计某个 policy 下有多少 unique item 违规，应该用 set 去重，而不是简单 count。
如果题目要求按 date range 查询，还要确认：
- range 是闭区间还是半开区间？
- date 是字符串还是 timestamp？
- 是否需要按时区处理？
- 数据量大时是否需要预处理索引？
基础版本可以线性扫描，follow-up 再讲优化：
少量数据：遍历过滤
大量查询：按日期排序 + 二分
按 policy 查询频繁：policy → sorted records
需要 unique count：维护 set 或 bitmap，但注意内存这样回答会比直接写一个复杂结构更稳。
时间格式转换要封装
会议区间、预约、日程类题经常用 0900 到 1730 这种格式。不要在主逻辑里到处写转换表达式。应该单独写：
toMinutes(time)
durationBetween(start, end)这样有两个好处。第一，主逻辑更清楚。第二，如果 follow-up 加了 break time、跨天、取消最少会议，你只需要改时间工具函数或调度逻辑。
很多候选人会在这种题里因为细节 bug 失分，比如把 time / 100 的整数处理、分钟取模、跨小时比较写错。把转换封装出来并加测试，是很低成本的稳定做法。
先做正确，再做优化
多 Part 面试中，一个常见策略是：
Part 1：用最直观方法快速做对
Part 2：复用已有结构
Part 3：指出瓶颈并增量优化例如社交推荐题，基础版可以先用 hash map 存关系和分数，查询最好朋友时遍历。follow-up 如果问百万好友的明星用户，再考虑预计算 best friend、heap 或缓存。
重要的是你要主动说：
“我先实现 O(f) 的版本保证正确。假设查询非常频繁而更新较少，可以在 transform 阶段预处理每个用户的 top friend，把查询降到 O(1)。如果点赞关系实时更新，则需要维护 heap 或缓存失效策略。”
这说明你知道什么时候该优化，也知道优化会带来维护成本。
遇到没时间写完 follow-up，应该怎么处理
如果最后一个 part 来不及完整实现，不要沉默写到时间结束。更好的做法是：
- 先口述设计。
- 写出核心数据结构。
- 写关键 helper 或伪代码。
- 说明复杂度。
- 点出测试用例。
面试官通常不是只看代码行数，也看你能不能在时间压力下保持结构化推进。
例如：
“这个 follow-up 我会在 add/remove 时维护一个 ingredient count map，并在每次某个 ingredient 数量变化时只重新计算这一项折扣，而不是每次扫描所有 ingredient。这样 add/remove 是 O(number of ingredients in recipe)，get_total 是 O(1)。”
这比最后 5 分钟盲写更有效。
面试中的沟通节奏
多 Part 题的沟通可以按固定节奏：
- “我先确认一下输入和返回。”
- “我会先做一个简单正确版本。”
- “这个数据结构后面也方便支持 range / dedupe / follow-up。”
- “我跑一个小例子。”
- “这里的复杂度是……如果数据量变大，我会……”
不要每写一行都解释，也不要完全不说话。面试官需要知道你在推进。
结尾
多 Part 编程题考察的是工程推进能力。你需要写代码，但更需要控制节奏：问对问题、搭好骨架、快速做对基础版，再把 follow-up 讲清楚。
如果你经常出现“第一 part 做太久”“follow-up 没时间”“题明明会但面试挂了”，建议专门练多 Part mock。训练目标不是刷更多题，而是在有限时间里稳定完成 70% 到 90% 的有效信号。你可以在服务和价格页面查看技术电面 mock 和针对性辅导方式；如果已经有具体面试时间，也可以通过联系我们页面说明目标岗位、面试轮次和准备进度。
