开发者面试指南
你有没有参加过面试，面试官看着坐在桌子对面的你问：“你有什么问题吗？”，你只是看着他说“嗯，我没有问题了”。如果这曾发生在你身上，那么很有可能你对面试体验有很片面的看法。
可以理解，作为候选者你只关注一个结果：获得一个 Offer。但是不要忘记面试不是单向的。你应该关注面试这家公司就如同他们关注面试你一样。
但是你应该问他们什么呢？
许多开发者都曾问过我这个问题。在过去的15年中，我曾为7家公司工作（包括两个实习职位和在一个创业团队工作的6个月），我也面试过数十家其他的公司。最终我决定写下我在面试中问过的问题，希望能够给其他人提供一点帮助。
旁注：在我们每周的开发者建议广播软技能中会覆盖这一主题和许多其他的主题。欢迎订阅！
我的目标是持续更新这篇文章。如果你有建议，请通过 Twitter 告诉我，我会将其加入供大家受益。
你将和谁交谈？
在面试中，你通常会遇到三种角色。这些角色会是一个人或者多个人，取决于公司的大小：
- 软件工程师
- 工程师经理（技术 leader，中级经理，总监）
- 高层领导（VP， CTO， CEO， 部门经理）
对每一个角色我都有不同的问题，我将在下面一一列出来。注意我有时会重复用同一个问题问不同的角色然后看看他们的回答有何不同。
这是一篇很长的文章，所以它的意义更多是作为参考，而不需要通篇细读。如果我今天要去参加面试，我会带着这篇文章并在面试期间参考一下。
这些问题中的多数都没有一个“正确”或者“错误”的答案。它们是用来帮助你了解这家公司、以及其文化、流程和组织。它们通常也作为交谈的开始，这在你面试中出现大脑短路时非常有用。
作为礼貌，我常常在面试一开始就告诉面试官我希望有一点时间来提问。这有助于他们合理安排时间。通常，他们会在面试的最后让我提问，所以注意面试的时间安排，也让他们提前意识到你的意图。问完每一个问题，停顿一下，问一下面试官你是否可以继续提问以及面试还剩余多长时间。
软件工程师的问题
1、每天你怎么知道需要做什么事情？
这个问题的目的是确认功能缺失。我希望从2-3名工程师哪里获得答案。如果公司的领导说他们遵循特定的流程，但是工程师却不谈这个流程，那是一个功能缺失的迹象。如果从不同的工程师那里得到不同的答案，那是另一个功能缺失的迹象。
在一个高质量的团队中，这个问题我所得到的回答是一致的。每一个开发者都知道这个流程，并且这个流程足够轻量级到对工程师提供帮助而不是压制他们。
好的回答示例（还有许多其他的）：“我们会制定 N-星期的 sprint，在每一个 sprint 中工程师会提交一系列的功能和 bug 修复最终交付。每一天我们会相互汇报进度。我们有一位出色的产品经理负责和客户交涉，以保证我们优先开发功能和修复 bug。”
不好的回答示例（还有很多其他的回答）：“我到办公室然后看看哪里需要救火。大多数时候我都被紧急情况中断。”
注意我没有提到 “Scrum” 或者其他特定的方法。相比实际的日常开发怎么完成，我对公司在他们的过程中所使用的标签没什么兴趣。
2、你用什么来做版本管理？
好的工具是好的团队的一个指示。如果一个团队在使用一个古老的版本控制系统，他们也许还在使用一堆其他过时的工具。而且，他们可能不重视良好工具投资所获得的效率提升。
紧接着一个很好的问题是关于工作流。你使用分支吗？你喜欢使用 rebasing 还是 merging（git 术语）？这些问题会告诉你他们所选的工具有多么专业，这将会告诉你很多他们的熟练程度，反过来告诉你如果你接受这项工作，将会有什么期待。例如，你将是“本地的 git 专家” 还是你将向名副其实的 Linus Torvalds 学习？
这个问题可以引发一场通用工具的讨论，这通常会给你一些好的见解。
3、在这里工作你喜欢的是什么？
好的回答：我从我的工作中获得许多满足。
好的回答：在工作中我们有很多乐趣。
好的回答：我喜欢和真正聪明、友好的合作者一起工作。
好的回答：管理尊重工程师。
好的回答越多越好。我不必获得以上全部回答来给公司打高分。请记住，有些人不是自然而然的“装腔作势”，所以在这里你可能不会获得精彩的反应，这可能是正常的。
但是如果我听到了类似以下的回答，并且没什么好的回答，我会担心：
不好的回答：它付我工资。
不好的回答：我不需要很努力的工作。
不好的回答：这里交付没有太大压力。
不好的回答：即使我犯了大的错误也不要紧。
不好的回答：（沉默）
不要以为是我想象的这些回答。我在真实的面试中听到过这些回答。
我不会听到这些不好的回答就自动将这家公司看成不好的公司，但是如果只有这些回答，我通常不会考虑这里。
4、你写单元测试吗？
在通过一个团队的单元测试实践对他们做出结论时要很小心。如果在我问道单元测试时一个团队非常兴奋，这通常是一个好的迹象。另一方面，如果他们不能解释为什么要使用单元测试，或者说单元测试的缺陷时，这是盲羊教条的一个迹象。如果他们提供一些不好的理由来解释为什么不写单元测试，如“我们没有时间”，那对我而言是一个不好的信号。
如果工程师告诉我他们会写单元测试，并且他们尝试告诉我单元测试的考量，比如需要多长时间来运行单元测试，他们有多少测试用例，以及代码覆盖率等，那对我是非常有吸引力的。这告诉我他们有很好的工具，并且他们知道怎么使用这些工具。另一方面，如果他们相信100%的代码覆盖率就能保证代码中没有 bug，我表示怀疑。
我想提前知道在这家公司我是否会在一套庞大、陈旧、无法测试的代码上工作。这将帮助我管理自己的预期，并且决定是否接受这份工作。
后续问题：
- 你喜欢单元测试还是集成测试？
- 你们有验收测试吗？
- 你使用什么（哪些）测试框架？你喜欢吗？
- 你的单元测试需要耗费多长时间？
5、你使用持续集成吗？
我所知道的最好的软件开发团队使用 Jenkins， Travis， Buildbot 等工具。如果这个团队没有持续集成，我尝试了解他们是否熟悉这个概念。如果他们不熟悉这个概念，以我的经验这是一个不好的迹象。使用持续集成意味着这个团队也许信奉自动化，以我的经验这通常是一个很好的迹象。
对于有的团队，这自然会引导到持续发布的讨论，这是一个和持续集成相关但是又不同的概念。如果是一个 web 开发者职位，我希望这个团队至少听说过持续发布，强的团队应该使用持续发布，至少有一部分在使用。
后续问题：
- 当 CI 报告失败时，你们的团队需要多长时间来修复？
- 你喜欢/不喜欢 CI 系统的哪一点？
- 你们的 CI 运行一次需要多长时间？你有让它更快一些吗？
6、你们怎么测量？
这是一个开放问题，主要是看看这个团队是否花精力去测量他们的软件。对于 web 开发团队，答案倾向关注性能，如响应时间、请求吞吐量、用户数量、客户端反应灵敏度等。但是也可以讨论使用不同语言的用户数、浏览器故障、缓存命中率等无数其他的事情。如果一个团队没有花时间去测量，很有可能他们没有根据真实数据来做决定。他们可能已经提前优化。我重视使用真实数据来做决定的团队，尤其是有关性能方面，但是它适用于很多其他方面。
如果面试官知道这些问题中多数答案，那是一个很好的信号说明这是一个优质的团队。如果他们对为什么要关注这些测量没有任何主意，这是一个负面的信号。
再次声明，教条主义同样适用于此。如果一个团队看起来已经锁定了一些不会产出价值或者可操作信息的测量指标，并且不能对此给出满意的解释，这可能是一个警告信号。
后续问题：
7、你们怎么发现并修复 bug？
强队通常都有专用的测试人员，团队的开发人员专注于质量。一个真正的强队有强大的自动测试。有的团队太小而没有专用测试人员或者自动测试，但是并不意味着他们是一个不好的团队。当我问这个问题的时候，我是想感受一下他们的流程。他们是否总是火烧眉毛？他们是否有清晰的流程用于发现 bug 并为 bug 排出优先级。他们是否依赖用户发现 bug。
后续问题：
- 怎么为 bug 排优先级？
- 使用什么 bug 追踪系统？（你讨厌它的哪一点？）
- 你们使用 Excel 来跟踪 bug 吗？（不！！！）
- 在你的 bug 跟踪系统中你有几个 bug？
- 修复一个 bug 你需要多长时间（最少、最多、平均）？
8、你们使用什么合作工具？
以我的经验，优质的团队会使用许多合作工具。他们常常使用聊天服务（Slack，IRC，HipChat，Jabber），代码 Review 服务（Gerrit，GitHub，GitLab，Review Board），当然还有电子邮件。我在寻找每个开发者知道其他开发者在做什么的信号。我不是在寻找疯狂的细节，更多的是想了解一般意识。此外，我喜欢看到集成合作工具。最简单的例子就是当自动编译失败时会自动发送一封邮件。web 开发团队的另一个例子是当严重错误发生时或当关键指标跨越某个阈值时自动错误 log 服务发送通知到团队的聊天室。
9、你们使用什么框架？
我个人偏爱框架两个方面：
- 1、我喜欢现代的东西
- 2、我喜欢新（对我而言）东西
所以如果一个团队在使用 Motif 开发一个 AIX 桌面应用，我可能不会感兴趣。但是可能你会喜欢。这是一个深刻的个人喜好问题，你应该对自己的喜好有一个很好的了解。
不管你个人对框架的喜好是什么，了解他们为什么已经选择了他们的框架非常重要。他们是跟风？他们频繁的更换框架？他们的代码库就是一堆本月框架榜单中的代码堆积？他们一直使用古老的版本？
在为什么这个主题上，我希望了解在选择技术时开发者有多少自由。管理层是否授权技术选择？管理层是否听从开发者？为了了解这些问题，我通常会问“你们是怎么开始在项目中使用框架 X 的？”。如果开发者不知道答案，这也许是一个不好的迹象，也有可能他们在公司的时间不够长还没有参与做这个决定。
我喜欢看到团队为他们使用的开源项目贡献代码。这说明他们不仅能够使用开源代码，同样还足够熟练到为它贡献代码。这是我喜欢共事的开发者。如果公司乐意为开源项目付费，那就更好了。这说明公司理解了成为开源公民意味着什么。
如果团队重新造轮子而不是使用已有的工具来帮助他们开发项目，我会感到紧张不安。这条规则也有例外。例如，当 Facebook 也曾开发他们自己的框架，我不会反对他们那样做的。
10、我们什么时候可以结对？
如果你真的想清楚了解与这个团队共事是什么样子，尝试真正的和他们一起工作。我个人从未这么做过，但是我有一位朋友就这么做了。我觉得这是一个很棒的主意。如果你想了解这个团队的每一件事情，去和他们一起工作半天。这可能需要签署 NDA 协议。如果这个团队愿意考虑这个建议，我觉得是一个很好的迹象。
你可能需要通过管理人员来安排，所以设计这个问题主要是想看看开发者的反应。他们可能会感到震惊，因为他们觉得不值得提到管理层。
11、你的下一个最后期限是什么时候？
（由 Evan Farrer 贡献）
这个问题是希望更多的了解公司实际遵循的开发流程。单从这个问题不会获得非常有用的信息，但是当你添加上这些问题，事情就变得有趣得多：
- 谁来设置最后期限？
- 你的上一个任务在最后期限前完成了吗？如果没有，为什么没有？
高质量的团队会一致同意并承诺最后期限。随意设置最后期限是功能缺失的迹象，或者至少说明工程师在设置最后期限时没有发言权。
12、搭建一个全新的开发环境需要多长时间？
（由 Evan Farrer 贡献）
这个问题帮助判断公司花费了多少精力在开发者体验上。一位新的开发者是需要数小时、数天还是数周才能拥有搭建好环境可用于开发的电脑？这个过程是自动的还是手动的？这将告诉你这个团队在“支持活动”上的高效并不和开发工作直接相关，但是这种高效却有助于他们的开发。团队有认真对待这件事情吗？
有的公司引以为傲的是：他们有开发环境搭建流程，可以快速的让新的开发者在第一天就能提交代码到生产环境。这说明公司很认真的对待为开发者提供无摩擦体验。
问经理的问题
1、您上一次写代码是什么时候？
我喜欢有强技术背景的经理。无意冒犯我的 MBA 朋友，我发现我真正喜欢的经理就是那些已经做过我正在做的事情的人。
2、您是怎么成为经理的？
我喜欢选择成为经理的“经理们”，因为他们是真的乐在其中并且他们天生就是那块料。 而不是被迫处在那个位置。我同样喜欢看到经理们专注于为他们的团队服务。我最喜欢的经理是那些着眼于让团队成员的工作的更舒心，而不是想着“掌控”。他们将自己当成帮助者和团队的守护者。他们有服务的态度，并且他们将“让团队成员工作的更舒心”作为其最重要的工作。
3、您的工程师怎么知道每天该做什么事情？
由于我已经问了工程师同样的问题，我会将他的回答和经理的回答比较看他们是否一致。如果他们的说法不一致，也意味着功能缺失。最糟糕的功能缺失就是没意识到的功能缺失。我相信去确认像这样的悬殊差异并修复它是经理的工作。
4、目前您的团队面临的最大挑战是什么？
他们通常会回答人员短缺。因为这是一个普通而明确的回答（毕竟他们正在招聘），我会继续问他们第二大的挑战是什么。我在寻找进度安排脱节、产品质量问题、和人际关系问题等等红色标记。你会知道这些红色标记当你看见他们的时候。每一个团队都有问题，所以你得到的回到依赖于几个因素：
- 经理对问题的意识
- 经理愿意对你坦诚
- 这个团队问题的严重程度
5、您怎样衡量每一个员工的表现？
熟练的经理人对待这件事情有很好的技巧。最好的经理人在评估团队成员的表现时会很细心的搜集整个团队成员的反馈。糟糕的经理人会根据自己的观察做出判断，而不会咨询团队成员。
6、您会做正式的绩效评估吗？
我喜欢为重视反馈并且帮助团队成员提高的经理人工作。绩效评估会成为令人难受的或积极向上的体验。根据我的观察，我觉得大多数人都将他们看做令人难受的。一个真正出色的经理人当然了解这一点，他会采取一些方式使得绩效考评出色的完成，使你影响深刻并且愿意为其工作。
后续问题：
- 您能分享一次帮助某位员工提高其绩效的经验吗？
- 在考评中是怎么指导他们的？
7、您每年都会加薪吗？
我知道为了和我对公司做出的贡献匹配，会对我的补偿做出调整，我也知道至少每年会做一次官方调查。对于适用的公司，我会询问股权。您会给我股票期权吗？您会每年给我更多的股票期权吗？
有的工程师不习惯问像这样的经济问题。不要这样。工程师通常花很少的时间思考这些问题，但是经理人总是在进行这样的面谈。这些问题对经理人都不会不自在：
- 您怎么预算加薪？
- 您团队去年加薪的平均水平是多少（百分比）？
- 一年后我可以预期多少加薪？最好情况，最差情况？
我不会将这些问题作为签署合同的一部分或者作为未来加薪的保证。我只是想了解公司时怎么运作的。我是必须要求为我加薪还是有标准的流程？
8、我可以将描述公司福利的材料带回家吗？
（由 Evan Farrer 贡献）
我知道大多数人都知道问这个问题，但是为了完整性还是值得一提。大多数公司都会为你准备一堆材料或者一个网站为你描述公司的福利。了解这些非常的重要，因为这通常是你补偿的很大一部分。这也许只适用于美国，我不确定在其他国家有多少公司为了刺激工作会提供医疗保险。
9、您会为您的员工排名吗？
（由 Matt Ryan 贡献）
有的公司会将所有的员工按照最佳到最差的顺序排序，然后强行将一定百分比的员工划入“优秀”、“普通”和“差”的分类，并根据这个分类来决定其加薪和奖金（我没有这样做）。
我从未遇到喜欢这个排名的工程师。这在大公司中尤为常见。他会影响你和水平相当的同事之间的交流，因为你知道某一天你会因为钱和他们竞争。
当我遇到这种情况时，也许不会立即认为这家公司就是一个糟糕的工作场所。在这样的公司里，通常会有一些不公开的可操作空间。问一问面试官他们怎么看待这个系统？有的经理人会非常坦率的说他们不喜欢这个系统，并且有的经理会告诉你他们为了整个团队的利益，会采取一些策略来“对抗”这个系统。如果你遇到了这样的经理人，你可以不用理会这个排名系统。
同时也请记住，不是每一个人都讨厌这个系统。只是我没有遇到过喜欢这个系统的人，并不代表他们就不存在。
后续问题：
- 您真的以为你的员工中的那 X% 是“不好”的？这对你的招聘过程有什么看法？ （这是一个大胆的问题 - 谨慎对待）
- 您应用某种曲线来确定表现最佳的人吗？
- 您使用什么标准来给员工排序？
- 您怎么知道这些指标搜集准确？
- 您怎么知道这些指标能够辨别出表现最佳的人？
为了了解更多的信息，Matt Ryan 对此有一篇非常好的分析文章。
给高层领导的问题
我并不是总是和公司的高层领导交谈，尤其是大公司，但是当我这样做的时候，我把它作为评估公司财务 可行性 的机会。我没有资格做这件事情，但是有一些明显的问题我有时会在面试中发现。此外，我想知道自上而下的文化是什么样的，因为这些信息会告诉我公司怎么看待员工，正面的和负面的都有。
1、你们是怎样创立的？
我在努力了解公司背后的资金。我想了解他们是否由风险投资，私募股权，公共股票或通过自筹的资金创立。 通常我可以在面试前弄清楚这一点，但公司的领导层常常会增加通过 Google 或 CrunchBase 找不到的见解。
2、你们盈利吗？
如果盈利，非常棒！如果尚未盈利，你们计划盈利的目的计划是什么？有的创业公司会有盈利的计划，而其他的公司收购或者 IPO 寻找出路。
后续问题：
- 过去几个季度/年的历史收入。呈增长趋势吗？
- 影响利润率的风险如竞争，意外开销和意外的收入不足等。
- 跑道：在筹集更多资金前，公司可以运营多长时间。
3、您对外包的看法是什么？
我想了解我所申请的这份工作在未来是否可能被外包，或者这个职位变成外包管理工程师。
我这里说的不仅仅是离岸外包。承包商也算。
4、跟我讲讲公司文化吧
这是我用来调和工程师的观点与领导层的观点的另一个问题。 我正在寻找可以作为能障碍迹象的差异。 如果他们节奏一致，这表明了良好的自上而下的沟通。 我想知道高层领导是否与海内外员工脱节。 我也想看看领导层是否坚定的远见并和员工进行了良好的沟通。 我最喜欢为有一个强大的，共同的愿景的公司工作。
一些公司非常重视文化，这可能是件好事。 至少你会清楚公司的价值观。 对于其他公司，你必须通过隐含的，有时候是不言而喻的细微差别来了解。 公司文化是非常重要的。 有政治斗争吗？ 尊重专业吗？尊重诚信吗？强调加班吗？
5、你有什么来保障公司会成功？
这个问题我是在寻找真实的证据，而不仅仅是不实的市场宣传。如果高层领导告诉我一些实际的数据如收入、市场规模和市值，这是一个好的迹象。同样，如果我能通过其他渠道证实这些信息，那就是一个更好的迹象。另一方面，这些数字可能表示非常糟糕，还是在画饼。
6、你们的汇报结构是什么样的？
对我而言，这个问题最好的回答是一个简单的回答。如果能够绘制一个图表来解释汇报结构，我也会很满意。我个人的喜好是是为小型，敏捷的公司工作，组织和交流开销最小。您的个人喜好可能不同，没有关系。不管你的喜好是什么，这个问题都是为了给你提供你所需要的信息，以便做出明智的决定。
结论
面试是双向的。 如果你有幸获得 Offer，请确保你从所需的经验中做出明智的决定。 祝你好运！
