你有没有过这样经历？
你去参加某公司面试，面试官看着你说，“你还有什么问题吗？”，然后你就只能看着他说，“呃，没有吧…”如果有这样的情况发生，那么你的这次面试很可能就只是一次单方面面试。
作为一个面试者，你理所应当地将全部精力集中到争取拿到offer。在面试时提问，是一个你向面试官表现你的思想深度和你对公司的理解的机会。同时，向面试官提问，也是你在“面试”面试官的过程。
那么，你到底应该问面试官什么问题？
不少正在找工作的软件开发员都问过我这个问题。在过去的15年里，笔者曾就职于7家公司，参加过许多公司的面试，也面试过不少求职者。接下来，我将告诉大家我面试时会问面试者的问题，希望能帮助到其他人。
你将会遇到哪些面试官？
面试官的数量取决于公司的规模，但一般情况下，以下三种职位的人会参与面试：
  • 软件工程师
  • 工程经理（技术主管/中层领导/负责人）
  • 公司领导（副总裁/技术总监/CEO/部门经理）
我通常会向不同面试官提出不同的问题，但有时我会向不同的面试官重复相同的问题，并对比他们的回答。具体的问题示例我将详细列举于下文。
这篇文章篇幅较长，希望大家能够以此作为参考，而不仅仅是通读全文。如果我今天要去参加面试，我说不定会带上这篇文章，看能不能将其运用到我自己的面试过程中。
大多数我要写出的问题都没有正确的答案，它们意在帮助你更好地了解这个企业，包括它的文化、运转过程以及组织架构。同时，这些问题还能够有效地在你大脑突然短路的时候依然能够保持与面试官的交流。
出于礼节，我通常会在面试开始前告诉面试官，我想预留一部分时间进行提问，以便他们能够做好充分准备。通常他们会让我在面试结束后提问，面试者要尊重面试官的时间安排，在面试一开始就告诉他们你的计划。问完每个问题之后，停下来思考一下是否应该继续提问，以及面试官是否还有足够的时间。
在软件工程师面试你时，该提什么问题？
1. 你们是怎么知道自己每天要干什么的？
问这个问题的目的是为了判断公司内是否存在运作障碍。我通常会向两三位工程师提出这个问题，如果公司领导说他们有一套特定的流程，但是这些工程师都说不出这个流程具体是什么的话，这个公司就可能存在运作上的问题；同样，如果不同的工程师给了你不同的答案，这也说明该公司可能存在一定的运作障碍。
一个高质量的团队应该能够给出一个连贯且一致的答案。每一位开发员都了解公司的运作流程，而且对于工程师来说，了解这一套流程不仅不复杂，还对他们的工作有利无害。
以下这个回答（当然这并不是唯一的标准答案），就是该问题的一个很好的回答：
“我们会做一位为期n周的Sprint冲刺，在这几周里，不同的工程师负责自己特定的功能点，以及修补出现的bug，最后拿出成果；每天我们都会基于自己负责的功能点报告自己获得的进展；最后，我们有一位优秀的产品经理负责与客户交流，然后告诉我们哪些功能点和bug应该优先考虑。”
这样的回答（这依然不是唯一的准则）就算是一个糟糕的答案：
“我会到办公室里看到有什么要紧的事去做，毕竟很多时候都会有突发状况自动找上门来。”
注意，我并没有提到Scrum或其他任何特点的方法。我更在乎公司到底怎样具体落实每一件事，而不是他们给他们的工作流程工作方式取得名字。
2. 你们用什么进行版本控制？

好的团队能够运用好的工具。如果一个团队的版本控制系统十分老旧，他们可能还在同时使用其他过时的工具，也不在乎好的系统和工具是否能给他们带来的更高的效率。
接下来还可以问问他们的工作流。是否使用分支？更愿意复位基底还是合并分支？这些问题能够帮助你看清面试官对他们所选用工具的熟悉程度，你可以从中看出他们工作的效率，并以此推断你可能会面临的具体工作。打个比方，你是愿意当鸡头，还是跟着真正有能力的工程师当凤尾？
你可以从工具选择方面开始逐渐深入，通常这个问题能够帮助你洞察这个公司的内部情况。
3. 你喜欢你工作的那些部分？
  • 好回答1：我的工作让我很有成就感
  • 好回答2：我们的工作氛围很有趣
  • 好回答3：我喜欢和这些聪明友善的同事工作
  • 好回答4：管理人员都很尊重工程师
你得到的好答案越多越好。也许他们不会回答到以上的每一点，但这并不说明他们对公司评价平平。有些人天生不善表达，所以不一定所有人都会给出很精准的回答，但这并不影响你的判断。
但是如果我听到的好答案并不多，甚至还听到了以下这些回答的时候，我就会开始紧张了：
  • 糟糕的回答1：工资还行
  • 糟糕的回答2：工作量不是很大
  • 糟糕的回答3：工作压力不是特别大
  • 糟糕的回答4：在这里就算犯错了没太大关系
  • 糟糕的回答5：沉默……
这些回答都不是我凭空想出来的，而是我在面试过程听到的真实回答。
不过就算听到这些回答，我也不会立马下结论“这家公司不怎么样”。但是如果所有面试官都给了我这些糟糕的回答的话，我多半就会去另一家公司了。
4. 你们写单元测试吗？

根据单元测试来判断一个工程团队的优秀程度时一定要小心。当我提到单元测试时，如果面试团队显得很激动，这通常是个好现象，但是另一方面，如果他们无法给出他们做单元测试的原因，也说不出单元测试的一些弊端，公司里就有可能存在盲目的教条主义的情况。如果他们不写单元测试的理由也不充分，尤其是“我们没时间做”这样的理由，通常对我也是一个不好的兆头。
如果工程师们安排我写单元测试，并且能够准确告诉我他们的衡量标准，比如运行时间、测试数量、代码覆盖率等，那么我就会因此被他们吸引了。这表现出他们拥有好的工具，并知道如何运用这些工具。但是另一方面，如果他们坚信100%的代码覆盖率就能保证100%的代码正确率的话，我又会对他们产生怀疑了。
我想要提前知道，我是否会在这家公司里面对一个庞大、老旧且未经测试的代码库。这些信息能够帮助我设定自己的具体期望，并做出最后的决定。
你还可以接着问：
  • 你们更愿意使用单元测试还是集成测试？
  • 你们有验收测试吗？
  • 你们用的哪个（或哪些）测试框架？感觉怎么样？
  • 你们的单元测试运行需要多长时间？
5. 你们有持续集成吗？
我所知的所有优秀的软件开发团队都会使用类似Jenkins、Travis和Buildbot这样的工具。如果一个团队没有持续集成，我就会试图去衡量他们对这个概念的熟悉程度。如果他们对持续集成的概念并不熟悉，对我来说这就是一个不好的标志了。拥有一套连续的持续集成系统意味着这个公司多半相信自动化。在我看来，这一点绝对是一个公司优秀与否的体现。
对某些团队来说，这个问题还会最终引起关于持续交付的讨论。虽然后者与持续集成相关，但是在概念上有差别。如果我去应聘的是一个网站开发员的职位，那么我期望这个团队至少听说过CD。其实优秀的团队能够将CD（至少在某些方面）落到实处。
你还可以接着问：
  • 当CI报错时，你们通常需要多久的时间进行修复？
  • 你认为你们的CI系统的优势和劣势分别是什么？
  • 你们的CI系统运行需要多长时间？你们有在尝试缩短这个时间吗？
6. 你们的衡量标准有些什么？
这是一个开放式问题，意在判断这个团队是否在用心衡量他们的软件。对一个网页开发团队来说，他们的回答一般侧重于性能指标，比如服务器响应时间、请求吞吐量、用户数量、客户端响应等。但是这个问题可能会延伸到使用不同语言的用户、浏览器崩溃、缓存命中/故障率及其他一系列问题。如果一个团队不花时间衡量自己的软件，这可能说明他们的决定并不是基于真实的数据，并过早地进行了优化。我尊重那些使用了真实数据，并对数据进行准确衡量后再做出决定的团队，特别是在性能方面，不过不仅仅局限于性能方面。
如果面试官知道这些具体问题的答案，那就表明这是一个高质量的团队。如果他们完全不知道衡量的意义在哪里，那这就是一个不好的暗示了。
再次强调，教条主义也有可能在这个问题中体现。如果这个团队执着于某个无关紧要的指标，又不能向你解释清楚他们这么做的原因，这可能就是一个警告的信号了。
你还可以接着问：
  • 你们最重要的产品指标是什么？
  • 你们会使用那些测量系统？（MixPanel,、statsd等）
7. 你们是如何找到并修复bug的？
一个强有力的团队通常会有一个专门的测试员，然后其他的开发员就专注于保证产品的质量，一个真正优秀的团队往往有着令人印象深刻的自动化测试。但是对于一些规模较小的团队来说，不具备专门的测试员或者自动化测试并不代表他们就是一个糟糕的团队。当我问到这个问题的时候，我都会尝试着去感受他们的工作过程：
  • 他们是不是总是火急火燎的？
  • 他们是不是能够保持理智地查找bug并确定优先修复的bug？
  • 他们是不是要依靠用户来查找bug？
你还可以接着问：
  • 你们是怎样确定哪些bug需要优先解决掉的？
  • 你们使用什么bug追踪器？（它有什么缺点？）
  • 你们会用Excel来查找bug吗？（坚决不会！！）
  • 你们的bug追踪器里有多少bug？
  • 你们通常需要多少时间修复bug？（最小/最大/正常情况的bug）
8. 你们使用什么协作工具？
在我看来，高效率团队都会使用很多协作工具。常见的有聊天工具（如Slack, IRC, HipChat, Jabber）和代码审查工具（如Gerrit, GitHub, GitLab, Review Board)），当然还有老生常谈的电子邮件。我想要从面试官的回答中看出，团队里的每一个开发者都知道彼此正在干什么，并不一定要具体到每一个细节，但至少要有一个基本的意识。同时，我还想看到不同协作工具之间的集成。最简单的例子就是自动构建失败时自动发送的电子邮件，还有就是网页开发团队的自动记错服务，该服务能够在重大错误或是关键指标超过临界值时自动通知团队的聊天室。
9. 你们使用什么框架？
我个人偏向使用两种类型的框架
  • 第一种是新潮的；
  • 第二种是我从未使用过的
所以一个要通过Motif构造一个AIX桌面应用的团队就可能对我没有吸引了了，但说不定你就对这样的框架感兴趣。这是一个相当个人化的问题，你应该要在充分了解个人偏好的基础上再提出这样的问题。
但不论你偏爱的框架是什么，了解这个团队选择框架的理由都是很重要的。是因为趋势驱动吗？他们会不会动不动就更换他们的框架？他们的代码库里有没有那些乱七八糟、东拼西凑的碎片信息？他们是不是还执着于某个过时的框架版本？
至于他们选择他们所用框架的原因，我想要知道开发者在其中到底有多少发言权。是管理层做出最终的决定吗？管理层会听从开发者的意见吗？为了一探究竟，我通常会问“你们是怎么决定在你们的项目中使用某某框架的？”如果开发者无法回答这个问题，那就是个坏兆头了，至少这意味着新员工并没有权利参与制定这类的决定。
我希望团队能够对他们所使用的开源项目做出贡献。这一点能够告诉我，他们不仅仅只是会使用这些项目，他们还对其精通到能够为其做出贡献，这样的开发者才是我希望能与之工作的。如果公司会对他们这样的贡献行为进行一定的投资的话，那就更棒了。这意味着这个公司知道开放源码的真正意义。
如果这个团队是在造轮子，而不是在使用现有的工具来构建他们产品，我就会开始担心了。当然这也有例外，当Facebook在自己构建自己的框架时，我就不会反对他们。
10. 我们什么时候可以组队？
如果你真的想要知道和这个团队工作是怎样的，你可以问问能不能模拟和他们工作一小段时间。我自己从来没做过这样的事，但我有个朋友这么做过（不过谁知道他到底做没做过呢）。我认为这个想法很棒，如果你想要全方面了解这个团队，和他们工作半天看看。他们可能会让你签署保密协议，但如果这个团队愿意考虑你的这个请求，我觉这是一个非常好的预兆。
你可能会和某个管理层的人商量这件事，因此问这个问题更重要的是观察开发者的反应。要是他们被这个提议震惊到不行，那你就没有必要和管理层商量这件事了。
11. 你们的下一个DDL是什么时候？
这个问题意在让你更了解这个公司的具体开发流程。如果你单问这个问题，他们的回答可能并没有什么参考价值，但是如果你接着问以下的问题，可能就会听到一些有趣的回答了。
  • DDL是谁定的？
  • 你在上一次DDL之前完成你的工作任务了吗？如果没有，为什么呢？
高质量的团队会设定统一的DDL，并且团队中的每个成员都能在那之前完成自己的工作。那些随意定下的DDL可能就暗示着公司的运作存在一定问题，至少这意味着工程师没有权利参与具体计划的制定。
12. 布置新的开发环境需要多久？
这个问题能够帮你看清公司在开发者体验方面付出了多少努力。他们会花几个小时？几天？还是几个月为新的开发者设置好他们的电脑，然后开始编程？系统是自动的还是手动的？这个问题能够让你判断出这个团队在 “活动支持”方面的熟练程度，虽然这些活动和编写软件没有直接的关联，但是最终对其是有利的。这个团队有没有认真对待这个问题呢？
有些公司设置新开发环境的速度之快，开发者任职的第一天就能够在新电脑上开始编程了。这表明了这家公司十分重视开发者工作顺利与否。
接下来几天我们将推出“面试中如何向技术主管提问”和“面试中如何向公司管理层提问”，敬请期待。
后台回复“资源”即可下载海量免费学习资源
你可能错过了：
继续阅读
阅读原文