软件工程面试中的代码需要能工作，过程也需要能被理解。准备时练习澄清要求、解释方案、实现、测试和讨论取舍，才能把刷题积累转成现场表现。面试官看到的不只是最后答案，也包括你怎样处理不确定信息和发现错误。
先核对这次技术面试的范围
实习、毕业生和有经验岗位可能采用不同流程。前端、后端、数据平台和嵌入式岗位也不会只考同一组知识。先读岗位职责与邀请说明，确认语言、工具、题型、是否需要项目讨论，以及是否有预先准备材料。
Microsoft 的技术面试指南强调问题解决、设计、编码和测试等方面。它为本文提供一个官方能力参照，但其中具体流程不能外推到所有公司，实际安排仍以招聘方说明为准。
准备表可以分为基础编码、常用数据结构、测试、项目解释和岗位相关知识。每一项找一个能够独立完成的小任务。不要把看过某套题库等同于掌握，也不要把高级术语数量当成准备质量。
开始写之前怎样澄清要求
拿到题目以后，先用自己的话复述输入和预期输出，再确认会改变实现的条件。数据规模、是否需要保留顺序、能否修改原输入、如何处理重复和空输入，都可能影响方案。
提问应当服务于选择，不必把所有可能边界一次性问完。可以先提出最关键的两个问题，说明为什么它们重要。如果面试官让你作假设，就明确记录假设并继续，不要因为缺少完全详细的说明而停住。
例如要求去重，必须知道“重复”如何定义，是完全相同的标识符，还是忽略大小写后的相同值。不同定义对应不同结果。直接开始写代码，可能会非常流畅地完成一个没有被要求的功能。
一个基础练习的完整要求
下面是本文设计的基础教学练习，不是任何公司的招聘真题或难度标准。输入是一列字符串标识符，输出第一次出现的每个标识符，并保持原来的先后顺序。大小写敏感，空字符串允许出现且也按普通字符串去重，不修改输入列表。
例如输入 A12、B07、A12、C03、B07，输出应当是 A12、B07、C03。这里标识符只是演示值，不代表真实用户或订单。题目已经把输入限定为字符串列表，不处理外部请求解析等额外场景。
先手工走一次：看到 A12 时保留，看到 B07 时保留，第二次 A12 已出现则跳过，看到 C03 保留，第二次 B07 跳过。这个过程给出了一个直接的实现思路。
先解释最简单的正确方案
最直观的办法是维护一个结果列表，每次检查当前元素是否已经在结果里。它容易解释，但对很长的输入，反复在列表中查找可能比较慢。可以先说明这个方案为什么正确，再考虑怎样改善查找。
改进方法是同时维护一个集合记录已经见过的值，以及一个列表保存输出顺序。集合用于检查是否出现，列表用于保留首次出现的顺序。两个结构各承担一个明确职责，不需要依赖集合遍历顺序。
在通常的哈希集合查找假设下，处理长度为 n 的输入平均需要线性时间，额外空间与不同值的数量有关。说明这是平均复杂度比简单喊出一个复杂度符号更准确，也体现你知道所用结构的假设。
代码应该与解释保持一致
下面的 Python 示例只实现刚才约定的字符串列表任务。它没有自动转换大小写，也没有删除空字符串，因为这些行为不在题目要求中。
def stable_unique(items: list[str]) -> list[str]:
seen: set[str] = set()
result: list[str] = []
for item in items:
if item not in seen:
seen.add(item)
result.append(item)
return result
讲解时可以边写边说明当前要完成的步骤，不必逐字符朗读。变量名要帮助读者理解角色，函数不要加入与题目无关的功能。写完以后，回到最初示例确认输出是否符合要求，再检查边界。
这段代码已按正文中的输入约定运行测试。真实项目如果接收不可信的外部数据，还需要在对应边界做类型和格式处理；不要把一个教学函数当成完整接口实现。
测试要覆盖不同理由
| 输入情景 | 示例 | 预期行为 | 检查目的 |
|---|---|---|---|
| 空列表 | 空输入 | 返回空列表 | 不依赖至少一个元素 |
| 全部不同 | A、B、C | 顺序不变 | 不遗漏正常数据 |
| 连续重复 | A、A、B | A、B | 重复只保留第一次 |
| 间隔重复 | A、B、A | A、B | 不只检查相邻元素 |
| 大小写不同 | A、a、A | A、a | 遵守大小写敏感定义 |
| 空字符串 | 空串、A、空串 | 空串、A | 不擅自改变有效输入 |
| 输入保持 | 先保存原列表 | 原列表不变 | 遵守不修改输入的要求 |
这些测试并不是越多越好地重复同一件事，而是每个都对应一个可能的错误。测试失败时先解释实际结果与预期的区别，再定位原因，修正之后重新运行相关用例。
在现场没有执行环境时，也可以手工跟踪一两个代表性输入，并说明还会检查哪些边界。不要在明明可以运行时，只看一眼就说应该正确。完成的标准应包含输出检查。
需求变化以后怎样调整
如果面试官要求忽略大小写，需要先确认输出保留第一次出现的原始形式，还是统一转换后的形式。这是产品语义，不只是把某一行代码换成小写处理。确认以后再选择用于判重的键和用于输出的值。
如果输入变成记录对象，则要问根据哪个字段去重。同一个姓名不一定代表同一个人，同一个订单号的多条记录也可能是状态历史。不能把字符串练习中的判断方式直接搬到真实业务数据上。
如果数据规模很大，还可以讨论是否流式处理、是否能容纳所有不同值、是否可以依赖外部存储。但不必在一个小题还没有正确实现时，就把系统扩展到复杂架构。先解决已知要求，再讨论规模带来的新约束。
遇到卡顿时怎样继续交流
卡住以后可以先说清楚目前确认了什么、哪个部分仍然不确定。拿一个小输入手工走一遍，往往能够发现需要维护的状态。完全沉默很久会让对方难以了解你的思路，但不断自言自语也不等于有效沟通。
如果已经有一个正确但不够快的方案，可以先说明并实现，再分析瓶颈。面试官可能给提示，收到后确认自己理解的含义，并解释准备怎样调整。接受帮助并继续推进，也是解决问题过程的一部分。
发现自己走错方向时，直接说明新发现，不需要掩饰。比如原来假设可以改变顺序，后来确认需要保留顺序，就解释为什么原方案不合适。清楚修正比强行维护错误方案更有价值。
项目追问需要准备哪些层次
技术面试不只包含现场题目。简历上的项目往往会引出需求、架构、实现、测试和结果追问。为每个主要项目准备一页说明：谁使用、解决什么问题、你负责什么、为什么选该方案，以及最重要的限制。
工程决策通常有取舍。选择简单存储是因为规模小和交付时间有限，选择某个框架可能因为团队已有经验。没有必要把每个决定都描述成技术最优，解释当时约束与后续演进条件更真实。
如果项目是课程或个人练习，准确说明规模。做过本地原型，不等于维护过高并发生产服务；用过某个服务，不等于理解其全部实现。可以讲清亲手完成的部分，同时承认没有验证的范围。
用一次故障讲出工程判断
选择一个你实际发现并修复的问题，说明最初现象、如何缩小范围、找到的原因、采取的修改和验证结果。不要只说“调试了很久，最后解决”。面试官更需要知道你如何排除可能性。
例如页面显示重复记录，可以先确认数据本身是否重复，再检查请求是否重复触发、合并逻辑是否有问题。修复以后用能够重现问题的输入再检查，并观察其他正常情况是否受到影响。这样的顺序能展示问题定位能力。
涉及他人系统、客户数据或安全细节时，只分享允许公开的范围。可以抽象描述技术关系，不需要拿出内部日志和账号信息。项目深度来自判断过程，不依赖泄露敏感材料。
系统设计准备要匹配岗位层级
毕业生和实习申请的要求可能与资深工程师不同。先看官方职责和邀请材料，确认是否需要讨论系统设计。准备时从一个清楚的使用场景开始，说明输入、输出、数据、接口和主要约束。
不要一上来堆缓存、消息队列和多个数据库。先问为什么需要它们，解决什么问题，又增加什么复杂度。一个能够解释的简单方案，通常比很多互相连接但无法说明关系的组件更适合讨论。
当规模、可靠性或延迟要求改变时，再讨论需要增加的机制。把假设写清楚，例如目前只考虑单地区、读多写少或有限数据量。改变假设后愿意重新评估方案，是设计交流的重要部分。
怎样安排一周技术练习
每天选择一个明确任务：一道基础题的完整过程、一组边界测试、一段项目解释或一次模拟沟通。不要把一天全部用于阅读答案，然后认为完成了很多题。至少保留一部分时间独立写、运行和解释。
可以把练习记录分成三类错误：理解题意、实现逻辑和表达不清。理解问题需要多做澄清与手算，实现问题需要追踪状态和测试，表达问题需要练习用短句说明选择。不同错误不应都靠增加题目数量解决。
每周选一题从头再做，确认离开原答案仍然能完成。再请同学改变一个要求，看自己能否调整。最终希望获得的是可以迁移到新问题的能力，而不是只记住某个固定解法。
正式面试前的检查
确认编程语言和环境可用，了解是否允许查文档、使用补全或其他工具。正式环节的外部协助规则以雇主说明为准，不能使用隐藏答案或由他人代为完成。
准备纸笔或其他允许的记录方式，方便列假设和小样例。远程面试还需要测试音频、屏幕共享与网络。不要在面试开始后才发现无法打开指定编码工具，必要的技术测试应提前完成。
最后复习自己提交的简历，确认每个技术词和项目都能解释。现场题完成后记得检查输出，项目讲完后记得说明限制。把准确、清楚和验证落实到每个小动作，才会形成稳定的工程表现。
解释复杂度时说清比较对象
本例的改进来自避免反复在结果列表中进行线性查找。讨论时间时，需要说明输入有多长、不同值有多少，以及集合操作采用通常的平均查找假设。不要把某次电脑运行更快的观察直接当成理论复杂度证明。
空间也应说明保存了什么。结果列表是输出，集合用于记录已经见过的值；不同的题目可能把输出空间与额外工作空间分别计算。面试官使用哪种口径时，可以明确确认，避免只报一个符号却讨论的是不同概念。
从一题延伸到可迁移的能力
练完去重以后，可以换成统计首次出现位置、保留最后一次记录或找出重复项。每次先重新确认输出要求，再决定原方案哪部分可以保留。相近题目并不一定只需要改一行，尤其是顺序和重复定义变化时。
保留每次修改前的样例和预期结果，观察新方案是否破坏原来仍然成立的条件。这个过程能够训练你把需求变化、实现和验证连接起来，比只记住一个熟悉模板更接近软件开发中的实际工作。
继续安排下一步
如果已选定目标企业，继续核对具体岗位的申请条件，同时用自己的项目支撑技术讨论和个人贡献说明。
常见问题（FAQ）
技术面试必须一直说话吗
不需要。关键节点说明假设、方案和发现的问题即可，也可以简短说明自己需要一点时间思考。持续无重点地说话并不能替代清楚思路。
先写一个慢但正确的方案可以吗
通常可以先说明正确方案和复杂度，再讨论优化，但应结合题目规模与面试要求。不要明知不满足硬限制仍把方案称为完成。
代码运行一次成功是否就能结束
还应检查具有不同目的的边界和要求，例如空输入、重复、顺序以及是否修改原数据。测试要对应可能的错误，而不是重复运行同一个例子。
课程项目可以用于技术面试吗
可以。准确说明课程场景、个人贡献、实现和验证，不把原型或模拟项目描述成未经证实的生产经验。
- Technical Interviewing· Microsoft Careers
- Python Set Types· Python Software Foundation
结合目标岗位、现有经历和申请阶段，向 STEM Career 顾问咨询简历、面试及海外与回国求职准备。