副标题：如何面试一家公司

你有没有经历过这样的工作面试，面试官看着桌子对面的你，说：“你还有什么问题吗？”你也看着面试官说：“嗯……我觉得没有了”。如果这发生在你身上，那么对于面试经验，很有可能你有一个非常片面的看法。

作为面试候选人，可以理解只关注一个结果：获得工作机会。但不要忘了，工作面试不是单向的。你也应该关注如何面试该公司，因为他们也在专注于如何面试你。

但是你该问他们什么呢？

很多求职者都问过我这个问题。在过去的 15 年里，我曾在 7 家公司工作（包含 2 个实习岗位，6 个月在一家创业公司兼职），我曾被十几个人面试过。现在我终于决定写下这些在面试中提出的所有问题，希望其他人能够从中获得些许帮助。

旁注：我们在每周的开发者建议播客 Soft Skills Engineering 中涵盖了这个主题和许多其他的内容。欢迎订阅！

我的目标是使它成为一个一直活跃的文档。如果您有建议，请通过 Twitter 联系我，我会将其纳入其中，供大家参考。

你会和谁交谈呢？

在面试时，你通常会遇到三个角色。根据公司的规模，这些可能是一人或多人：

• 软件工程师
• 工程经理（技术负责人，中层管理者，主管）
• 公司领导（副总裁，首席技术官，首席执行官，部门经理）

我对这些角色的每个人都有不同的问题，下面将会列出。请注意，我有时会对多个角色问重复的相同的问题，以了解他们的答案是否一致。

这是一篇很长的文章，它的意义更多是作为参考，而不是通读片段。如果我今天正在面试，我会在带上这个，并在面试中（谨慎地）参考。

大多数问题没有 “正确” 或 “错误” 的答案。它们旨在帮助你了解该公司，它的文化、流程和组织架构。你也可把它们作为对话的开始，当你的大脑 “宕机” 时，这在面试中可能会非常有帮助。

作为礼貌，我通常会在面试开始时告诉面试官，我想有一些提问的时间。这有助于他们对此做出相应的规划。通常情况下，他们在面试结束时让我提出问题，因此要留意面试进程，并让他们在这过程中早点察觉到你的想法。每个问题提问后，暂停下并询问你是否可以继续问问题，以及面试官还有多少时间。

对软件工程师的问题

1. 您是如何知道每天的工作安排的？

这个问题的目的是确定是否存在沟通障碍。我想从 2 到 3 名工程师那里得到答案。如果公司领导说他们遵循一定的流程，但工程师没有谈论到这个流程，那就是沟通障碍的征兆。如果从不同的工程师那里得到不同的答案，这是沟通障碍的另一个征兆。

在高质量的团队中，我得到了一致的答案。每个开发者都知道这个流程，而且这个流程是足够轻量级的，它会获得工程师的支持，而不是反对。

其中一个很好的回答的例子（还有很多其他的例子）是：“我们做 N 周的冲刺，其中每个工程师承诺提交一组功能和错误修复。每天我们都会报告彼此提交的进展情况。我们有一个了不起的产品经理，他与客户接触，帮助我们安排功能和错误修复的优先级。“

其中一个坏的回答的例子（还有很多其他的例子）是：“我进了办公室，看看有哪些迫在眉睫的事情。大多数时候，我会被突发事件所打断。”

注意我没提及 “Scrum” 或其他任何具体的方法论。相比于雇员每天实际上是如何工作的，我对公司用于工程流程管理的标签并不太感兴趣。

2. 您使用什么版本控制工具？

良好的工具是良好团队的强大指标。如果一个团队正在使用一个古老的版本控制系统，他们可能会使用一些其他过时的工具。此外，他们可能不重视投资良好工具所带来的效率提升。

一个很好的后续问题是询问关于工作流的问题。你们使用分支吗？你们喜欢 rebase 或 merge（git 术语）吗？这些问题会告诉你，他们对于所选择的工具有多了解，也会告诉你很多关于他们熟练程度的信息，反过来这会告诉你如果你接受这项工作会怎样呢？例如，你会成为 “本地 git 专家”，还是要向名副其实的 Linus Torvalds 学习？

这个问题也可以开启针对一般的工具的讨论，这通常会给你一些良好的洞察。

3. 这份工作的哪些东西是你喜欢的？

好的回答：我从工作中收获了满足。好的回答：在工作中有很多有趣的东西。好的回答：我喜欢与真正聪明，友好的同事工作。好的回答：管理人员尊重工程师。

越多好的回答更好。我不需要得到上面所有的回答才给一家公司打高分。记住有些人不会自然地 “流露出感情”，所以你可能不会得到主要的回答，但公司可能会很好。

但是如果我听到以下几种回答，并且很少听到好的回答列表中的回答，我会感到很忐忑：

差的回答：支付账单。差的回答：我不用努力工作。差的回答：没有很大的交付压力。差的回答：我是否犯了很大的错误并不重要。差的回答：（沉默）

不要以为这些回答是我编造的。在真正的面试中我确实听到过这些回答。

如果我听到这些差的回答，也不会就此在心里默认它是一间差的公司，但如果这些是仅有的答案，我通常会去其他地方看。

4. 你们写单元测试吗？

当你基于一个工程团队的单元测试习惯对他们做出判断时，要小心了。如果一个团队当我问其关于单元测试时变得兴奋，这通常来说是个好信号。但是另一方面，如果他们不能解释问什么他们要单元测试，或者单元测试的缺点，这是一个盲羊般教条主义的迹象。如果他们对

如果工程师告诉我他们写单元测试，并且他们也能告诉我他们测试的度量标准。比如他们需要运行多长时间，他们有多少测试，覆盖多少代码，这对于我来说很有吸引力，这表明了他们有好的工具，并且知道怎么去使用，另一方面，如果他们相信100%代码覆盖率能基本上保证无错误代码，我持怀疑态度。

我想要事先知道的是，我是否会在这家公司工作中需要面对一个庞大、过时，而且未经测试的代码库。这些将有助于我设定自己的期望，并决定这些是否是我想做的事情。

后续问题:

• 你们更喜欢单元测试还是集成测试？
• 你们会验收测试吗？
• 你们使用什么测试框架，喜欢它吗？
• 你们的单元测试需要运行多长时间？

5. 你们有持续集成吗？

据我所知最好的软件开发团队会使用 Jenkins, Travis 和 Buildbot 等工具。我会通过他们是否熟悉这个概念来衡量此团队是否有持续集成。如果没有，以我的经验来说是一个不好的信号。如果有持续集成系统意味着此团队应该也相信自动化，按我的经验这通常是一个非常好的信号。对于一些团队，这很自然的产生了一个关于 持续交付 的讨论，这与持续集成是一个相关但不同的概念。如果以一个 Web 开发人员的角度来说，我希望团队至少会听过 CD，而有实力的团队更倾向于将 CD 落实到位，至少在某部分如此。后续问题：

• 当 CI 报告了一个错误，你的团队花费多长时间来修复？
• 你喜欢/不喜欢你的 CI 系统吗？
• 你的 CI 运行需要多久？你有让它们更快吗？

6. 你们如何衡量(软件)？

这是一个开放式问题，旨在了解该团队是否有付出努力衡量其软件。对于 Web 开发团队，回答往往侧重于性能指标，如服务器响应时间、请求吞吐量、用户数量、客户端响应等。但是讨论可以涉及到像使用不同语言的用户数量、浏览器崩溃 、缓存命中/错失率以及无数的其他主题等。如果团队没有花时间来衡量，那可能表明了他们没有使用真实的数据来支撑他们的决策。它们可能是过早地进行了性能优化。我看重一个使用实际的可测量数据来支持决策的团队，特别是关于性能方面的，不过它也适用于许多其他事情。

如果面试官知道许多这些问题的答案，那么这是高质量团队的一个好的信号。如果他们不知道自己为什么需要关心这些测试，那么这可能是一个消极的暗示。此外，教条般的规则在这里同样适用。如果团队看起来好像已经锁定了一个并不一定能产生有价值的、可操作的信息的指标，并且他们对于这一点的解释无法让你满意，这可能是一个警告信号。后续问题:你认为最重要的产品指标是什么？

你使用什么测量系统？ （例如 MixPanel, statsd 等）

7. 如何查找和修复 bug？

一个强大的团队通常有专门的测试人员，团队的开发人员专注于代码的质量。一个真正强大的团队具有让人印象深刻的自动化测试。也有一些团队太小，并不具备专门的测试人员或实现测试自动化，但这并不一定意味着他们是一个糟糕的团队。当我提出这个问题的时候，我在试图了解他们工作的流程。他们总是火烧眉毛么？他们是否有一个合理的过程来查找和排列错误的优先级？他们是否是依靠用户来查找错误？

后续问题：

• 你们如何处理 bug 的优先级？
• 你们使用什么 bug 跟踪器？ （以及你们讨厌它们的什么）
• 你们使用 Excel 来跟踪错误吗？ （从未有过!）
• 在你们的 bug 跟踪器发现了多少个 bug？
• 你们需要多长时间来修复 bug（最小/最大/一般）？

8. 你们使用什么协作工具？

根据我的经验，高效率的团队使用大量的协作工具。他们经常使用聊天服务（Slack，IRC，HipChat，Jabber），代码审查服务（Gerrit，GitHub，GitLab，Review Board），当然还有值得敬仰但略有年代感的电子邮件。我正在寻找每个开发者知道其他开发人员在做什么的指示。我不是在寻找荒唐到极致的细节，更多的是为了一般意义上的知道。此外，我喜欢看到不同协作工具间的集成。最简单的例子是在自动构建失败时随时发送自动的电子邮件。另一个关于 web-dev 团队的例子是自动化错误记录服务，当发生严重错误时或当关键指标超过某个阈值时通知团队的聊天室。

9. 你们使用什么框架？

我对框架的看法有两方面：我喜欢时髦的东西。

我喜欢对于我来说是新鲜的东西。

因此，如果一个团队要使用 Motif 构建一个 AIX 桌面应用，我可能不是很感兴趣。但可能你会感兴趣。这是一个很个人的话题，你应该对自己的喜好有一个很好的了解。不管你的框架偏好是什么，了解团队为什么选择他们的框架是很重要的。是什么驱动他们这么做的？他们换框架是不是就像他们换衣服那样快？他们的代码库是否每个月都有碎片化流失，然后变得乱七八糟？他们有没有被一个久远的版本卡住？

至于为什么，我想知道开发者在选择技术方面有多大的发言权。是管理层选择技术吗？管理层是否依赖于开发人员？为了深入了解这些问题，我通常会问他们，“你们为什么在项目中使用某某框架？”如果开发者不知道答案，这可能是一个不好的信号，这意味着他们在项目中不能决定他们要使用什么技术。我希望团队里的成员能够为他们使用的开源项目做出贡献。这告诉我他们不仅能够使用开源代码，而且他们也以足够熟悉项目能为它做出贡献。这些开发者是我喜欢与之合作的类型。如果公司愿意为他们此种行为买单，这说明公司知道这些对于开源开发者的意义是什么。如果团队正在造轮子，而不是使用现成的工具来帮助他们构建产品，这会让我担心。当然也有例外的情况。比如我不会反对 Facebook 用他们自己的框架进行开发（或许我会）。

10. 我们什么时候可以 “结对”？

如果您想要清楚地了解与该团队一起工作的内容，那么请尝试与他们合作。我从来没有亲自做过这种事，但我有一个朋友做过（跟真的似得，对不）。我认为这是一个好主意。 如果你想了解任何有关该团队的事情，请和他们一起工作半天。可能需要您签署 NDA。如果团队甚至愿意考虑这个想法，我认为这是一个非常好的信号。

您可能需要与管理人员安排这件事，所以这个问题更多的是为了得到开发人员的反馈。他们可能会因为不值得提升管理层的观念而感到震惊。

11. 你们的下一个最后期限是什么时候？

(由 Evan Farrer 贡献)这个问题旨在让您更了解公司实际遵循的发展历程。这个问题本身的信息量并不是十分丰富，但是当你添加这些问题时，事情就变的更加有趣了：谁来设定这个期限？

你们遇到了最后的截止日期吗？ 如果没有，为什么没有遇到？

高质量的团队会一致同意并承诺期限。武断地确定的最后期限可能是沟通障碍的征兆，或者至少在确定时间表时，工程师没有一席之地。

12. 搭建新的开发环境需要多长时间？

(由 Evan Farrer 贡献)这个问题有助于衡量公司为优化开发者的开发体验有多少付出。新的开发者需要几个小时、几天或几周的时间来配置电脑并准备开始编码？这些操作是自动的还是手动的？这些问题将告诉你，团队在“支持活动”中的熟练程度，虽然这与编写软件无直接联系，但有助于支持它。所以看看团队是否认真对待这个问题。有些公司会为开发者设置过程如此之快而感到自豪，因为新的开发者在第 1 天就可以投入工作。这表明该公司为开发者提供了无缝的体验。

对于工程经理的问题

1. 你最近写代码是什么时候？

我喜欢经理有很强的技术背景。无意冒犯我的 MBA 朋友们，但是我需要的经理是那些与我做相同事情的人。

2. 你是如何成为经理的？

我喜欢的是那些真心喜欢并有一些小窍门而去选择成为经理的人，而不是那些被迫变成经理的人。我也喜欢那些近似于更专注服务团队的经理们。我最喜欢的经理类型是那些专注于让团队人员生活得更好的人，而不是精于“管理”的人。他们认为自己是团队的帮手和保护者。他们有一种服务态度，而且他们认为自己最重要的工作是让他们团队成员的工作环境更好。

3. 你的工程师如何知道每天的工作？

既然我问了工程师们相同的问题，我希望对比一下经理的回答，看看他们是否一致。如果不同，可能意味着出现了沟通障碍。最糟糕的情况是还没意识到此障碍。我相信找出这种差距并解决它是经理的工作。

4. 现在你的团队最大的挑战是什么？

他们通常会回答人员短缺。因为这是一个显而易见的答案(毕竟他们正在招聘)，我想要问的是他们第二大的挑战。我要寻找他们的松驰时间安排，产品质量问题和人际关系中的危险信号。当你看到它们你就知道了。每个团队都有问题，所以你得到的回答取决于以下几个因素：

• 经理对问题的意识
• 经理对你坦诚的意愿
• 团队问题的严重性

5. 你如何衡量个人表现？

有经验的，有技术的经理能做到这一点。 当评估个别团队成员的表现时，优秀的管理者将会仔细收集整个团队的反馈意见。 一个糟糕的管理者将会根据自己的观察得出结论，而不是通过小组。

6. 你做正式的绩效评估吗？

我喜欢为那些重视反馈意见和帮助团队成员进步的经理工作。 绩效评估比较麻烦，但能激发团队成员的干劲。据我观察，大多数人都不喜欢绩效评估。 优秀的经理一旦意识到这一点，就会立即采取措施，改善绩效评估的方式，让人心甘情愿参与进来。

后续问题：

• 你能告诉我你曾帮助他人提升的经历吗？
• 通过这些绩效你如何引导他人？

7. 您经历过年薪增长吗？

我想了解我的薪酬是否根据我对公司的贡献进行调整，我们每年至少会对其进行一次官方的评估。对于适用的公司，我喜欢询问有关股权问题。您会给我股票期权吗？您能每年给我更多的股票期权吗？

有些工程师在问这样的财务问题可能会感觉不舒服。大可不必这样。工程师通常花费很小一部分时间来思考这些话题，但管理人员一直会涉及这些话题。主管已经对这些问题习以为常：

您如何为加薪做预算？

• 去年的工资上涨的中位数是多少（百分比）？
• 我可以期待一年以后工资是多少？最好的情况？最坏的情况？

我并不把提出这些问题作为签署合同或者保证未来提升的前提。相反，我想了解该公司如何运作。我是否必须按照我的方式来要求加薪，还是已经存在有一个标准的流程？

8. 我可以得到一些描述公司利润的关键点资料嘛？

(由Evan Farrer提供)我认为大多数人已经知道要询问这个问题了，但为了完整起见，还是值得一提的。 大多数公司都准备给你一堆纸质材料或一个描述公司利润的网站。 重要的是你要知道在哪里，因为它通常是你补偿的很大一部分。 这可能只适用于美国。 我并不清楚位于其他国家中由公司所提供的医疗保险优惠政策是如何工作的。

9.你把员工一起排列吗？

（供稿人：Matt Ryan）

一些公司通过在一个大排序列表中排列每个员工，从最好到最坏，然后迫使一定比例的员工成为“好”、“中等”和“坏“的子列表，确定提升和奖金。

我从来没有见过一个喜欢这样的工程师。这在大公司中尤为常见。它可以影响你与同龄人的互动，因为你知道有一天你必须为了钱与他们竞争。

当我遇到这种情况，可能不会立即意味着这家公司是一个可怕的工作场所。在这样的公司里，经常会有一些小小的“空间”在雷达下飞行。询问面试官他们是否喜欢这样的系统。一些管理人员对于系统的不满情绪会很坦率，有的甚至会告诉你有关他们用来为他们的团队谋利的“游戏”系统的策略。如果你找到这种经理，你可能会忽视排名系统。

请记住，并不是每个人都讨厌这个系统。 只是因为我还没有遇到喜欢这个系统的人，但并不意味着他们不存在。跟进的问题:

• 你真的认为 X％ 的员工“差劲”吗？ 这反映了招聘过程的什么问题？ （这是一个大胆的问题 - 谨慎回答）
• 你会运用曲线图来标明表现最好的人吗？
• 你使用什么指标来对员工进行排名？
• 你如何知道这些指标是否收集准确？
• 你如何知道这些指标能反映员工的最佳表现？

更多相关信息，请参阅 Matt Ryan 对该问题的准确分析。

10. 你会做定期的团队回顾吗？

(由 Aric Parkinson 贡献)如果是这样的话，他们喜欢什么？你大概多久可以收到团队成员的反馈？你最近一次根据你收到的反馈改变了你的团队运作方式是什么时候？这些问题能够指引你发现你期待的管理层的样子，还能让你看见团队是否向管理层提供了足够多的反馈。如果团队不进行总结回顾，就难以发现工作中的问题，更不用说变速来纠正错误。 如果管理人员不相信反馈意见能促进团队发展，那么他们可能会对团队出现的问题聪耳不闻，或者会营造一个缄默的氛围，团队成员再问题面前都不敢发声。

针对领导人的问题

我和公司的高层领导交谈的时候不多，尤其是在大公司，每当我这样做的时候，就是我想理解公司财务能力的时候。在每一次的会面中，我可以了解到一些显著的问题。 此外，我也想知道自上而下的文化是什么的，因为这些信息可以告诉我公司如何积极地和消极地对待工程师的。

1. 您是如何融资的?

我正在努力加深对公司背后资本的了解。如果他们由风投、私募股权、公共股票或通过营收自筹的资金，我想对此有所了解。通常我可以在面试前弄清楚这一点，但公司的领导层常常会加深我在某些问题上的理解，这些是我通过 Google 或 CrunchBase 找不到的知识。

2. 你盈利了吗？

如果已经盈利，太棒了！ 如果没有盈利，你的盈利计划是什么？在其他创业公司则通过收购或 IPO 寻找出口的时候，你也开始制定一项计划吧。

后续议题：

过去几个季度/年的历史收入。 它向上趋势吗？

风险盈利，如竞标、意外支出和意外收入不足。

运营: 在筹集更多资金前，公司可以运营多长时间。

3.你怎么看外包？

我想知道我申请的工作在未来是否会外包，或者是否这个工作会变成管理外包工程师的职位。

我在这里不光是讨论离岸外包。这也包含了承包商。

4.告诉我公司的文化。

这是另一个我过去常常用来调和工程师的观点和领导的观点之间的冲突的问题。我寻找一些差异做为异常的信号。如果领导和工程师意见一致，那就说明上下沟通比较通畅。我想知道高级管理层是否已经脱离了前线的员工。我也想看看领导层是否有良好沟通的坚实视野。我理想的公司是有一个强大的，共同的愿景的。

一些公司非常重视企业文化，这可能是件好事。 至少这对你清晰了解公司的价值观有所帮助。 而对于另外那些不重视企业文化的公司，你必须通过隐含的不成文的习惯来发掘。 文化可以非常重要。政治斗争存在吗？专业的价值如何？诚实被重视吗？有加班费吗？

5.你用什么保证这个公司会取得成功？

针对这个问题，我尝试寻找真实的证据，而不仅仅是营销炒作。 如果高层领导给我真实的数字，如收入，市场规模和市值，这将带来很大帮助。 此外，如果我可以从其他来源验证这些信息，那就更好了。另外，数字也有可能反映出糟糕的结果，就像一个月的跑道，很快就没有资金。

6. 告诉我你的报告结构。

对我来说，这个问题的最佳答案其实很简单。如果你能画出一个简单的组织结构图来解释报告结构，我就十分满意。我个人偏向于为规模组织小、敏捷、开销也不大的公司工作。每个人偏好不同，但不管你的偏好是什么，这个问题都是为了提供你所需要的信息，以便对公司做出明智的决定。

结论

面试是双向的。 如果你有幸获得录取通知，请确保你从已有的经验中做出明智的决定。祝你好运！

https://www.oschina.net/translate/how-to-interview-as-a-developer-candidate?lang=chs

閱讀更多 誰不曾年少輕狂 的文章

關鍵字: 支付 面试 片面