导读：面试是工程师在职业生涯中总会碰见的问题。相信很多工程师对怎么回答面试官的问题已经有自己的总结。面试是双向的过程，面试官在面试你的过程中，你也在面试公司。你可以从面试中获取公司很多信息。本文作者总结了面试中针对不同面试官的不同问题。由高可用架构翻译，转载请注明出处。
面试的时候，面试官通常最后会问：“你有什么问题吗？”，面试者往往回答说：“没有”。 如果这种情况总是发生在你身上，那么很有可能你对面试有一个非常片面的理解。
作为候选人，你通常只是专注于面试结果：是否获得工作机会。 但不要忘了，工作面试不是单向的。 您应该在面试的时候专注于面试公司，因为他们同时也专注于面试您。那你应该问公司什么问题呢？
很多求职者都问我这个问题。 在过去的15年中，我曾在7家公司工作，并且面试过更多家公司。 我决定写出面试中，我提出的所有问题，希望能够帮助其他人。我希望保持本文持续更新。 如果您有建议，请通过Twitter通知我，我会将你的问题纳入其中，让大家受益。
[h1]你会和谁谈？[/h1]
在面试中，您通常会遇到三种角色。根据公司的规模，可能是一个人或多个人：
- 软件工程师
- 技术经理（技术负责人，中层管理人员）
- 公司领导（副总裁，CTO，首席执行官，部门经理）
我将在下面列出针对这些不同角色的不同问题。我有时会对多个角色重复相同的问题，以了解和比较他们的答案。
这是一篇很长的文章，它的意义更多是作为参考，而不是为了你照本宣科。如果我今天正在面试，我会看看本文，并在面试中（谨慎地）参考本文内容。
大多数问题没有“正确”或“错误”的答案。它们旨在帮助您了解公司，了解其文化，流程和组织。当您的大脑卡壳时，他们也可以作为对话开头，在面试中可能会非常有帮助。
我通常在面试开始时告诉面试官，我想有一些时间提问。这将有助于他们指定相应的面试计划。通常情况下，在面试结束时面试官会让我提出问题。每个问题后，暂停以询问您是否可以继续提问题，以及面试官还有多少时间。
[h1]针对软件工程师的问题[/h1]
[h2]1、你怎么明确每天的工作？[/h2]
这个问题的目的是确定是否有协作上的问题。我想从 2 – 3 名工程师那里得到答案。如果公司领导说他们遵循一定的过程，但工程师不会谈论这个过程，那就是协作问题的征兆。如果您从不同的工程师那里得到不同的答案，这是另一个工作协作问题的征兆。
在高质量的团队中，我会得到一致的答案。每个开发者都知道这个过程，并且可以很好的支持工程师的工作。
有一个好答案的例子（还有很多其他的）：“我们做 N 周的冲刺，其中每个工程师承诺提供一组功能和修复错误。我们每天都会报告我们对彼此的进展情况。我们有一个产品经理，帮助我们处理优先级较高的功能和错误修复。“
也有一个坏的答案的例子（还有很多其他的）：“我进了办公室，看看是什么出问题了。大多数时候，我会被紧急事务打断。“
注意我没有提到“Scrum”或任何其他具体方法。我对工程师实际的日常“如何做的事情”更有兴趣，而非工作过程的使用的标签。
[h2]2、用于版本控制的工具是什么？[/h2]
使用良好的工具是好团队的特征。如果一个团队正在使用一个古老的版本控制系统，那么他们可能会使用一些其他过时的工具。此外，他们可能不重视投资良好的工具以实现工作效率增长。
询问工作流程是非常好的进一步的问题。你使用分支版本吗？你喜欢 rebase 还是 merge（git术语）？这些问题会告诉你，他们所选择的工具有多么的专业，同时将会告诉你很多他们熟练程度的信息，反过来也告诉你如果你接受这项工作，你会有什么期待。例如，你会成为“本地 git 专家”，还是跟随一个名副其实的 Linus Torvalds 学习？
从这个问题可以开始关于一般工具的讨论，这通常会给你一些很好的见解。
[h2]3、在这里工作你喜欢什么？[/h2]
正面的答案：我从我所做的工作中获得了满足。
正面的答案：我们在工作中有很多乐趣。
正面的答案：我喜欢与真正聪明，友好的同事合作。
正面的答案：尊重工程技术。
这样的答案越多越好。我不一定因为上面的答案给公司高分。请记住，有些人不会透露真实想法，所以你可能不会在这里得到同样的反应，这也是正常的。
但是如果我听到以下几种答案，我就会感到紧张：
负面的答案：帮助我支付账单。
负面的答案：我不用努力工作。
负面的答案：没有很大的交付压力。
负面的答案：如果我犯了很大的错误也没什么。
负面的答案（沉默）
这不是我编的答案。我真的在面试中听到过这样的答案。
如果我偶尔听到这些负面答案，我不会自动认为它是一个糟糕的公司，但如果这是唯一的答案，我通常会在其他地方看看。
[h2]
[/h2][h2]4、你写单元测试吗？[/h2]
（面试官：咳咳（尴尬），旁白由高可用小编贡献）
根据单位测试实践对工程团队作出结论时要小心。当我询问单元测试时，如果一个团队兴奋不已，这通常是一个好兆头。另一方面，如果他们不能解释为什么需要单元测试，或单元测试的缺点，这可能是盲目的教条主义。如果他们无法给出不写测试的理由（特别是像我们没有时间这一借口），那对我来说是一个糟糕的迹象。
如果工程师告诉我他们编写单元测试，他们就能够告诉我们有关指标。例如测试运行多长时间，有多少测试以及代码覆盖率，这对我来说非常有吸引力。这表明他们有好工具，并且知道如何使用它们。另一方面，如果他们认为 100％ 的代码覆盖确保了一个无错误的代码库，那么我很有兴趣加入。
通过本问题，我可以知道是否会在一个大的，旧的，未经测试的代码上工作。这将帮助我管理自己的期望，并决定这是否是我想做的事情。
后续问题：
- 你喜欢单元测试还是集成测试？
- 你有验收测试吗？
- 你使用什么测试框架？你喜欢它吗？
- 您的单元测试要运行多长时间？
[h2]5、你有持续集成吗？[/h2]
好的软件开发团队使用 Jenkins，Travis 和 Buildbot 等工具。如果团队没有持续集成，我会尝试衡量他们是否熟悉这个概念。如果不是不熟悉，在我的经验中这是一个坏迹象。持续集成系统意味着团队可能相信自动化，这在我经验中通常是好迹象。
对于一些团队，这自然而然导致了关于持续交付的讨论，这是与持续集成相关但不同的概念。如果这是网站开发人员的职位，我希望团队至少听说过持续交付，而强一点的团队则至少在一定程度上使其成为现实。
后续问题：
- 当 CI 报告失败时，您的团队需要多长时间才能解决问题？
- 你喜欢/不喜欢你的 CI 系统？
- 您的 CI 运行一次需要多长时间？你会让他们更快吗？
[h2]
[/h2][h2]6、你会观测你系统中哪些东西？[/h2]
这是一个开放式问题，旨在了解该团队是否努力观测其软件。对于 Web 开发团队，答案往往侧重于性能指标，如服务器响应时间，请求吞吐量，用户数量，客户端响应等。但是讨论可以涉及到像不同语言的用户数量，浏览器崩溃，缓存命中/错失率以及无数其他主题。
如果团队没有花时间来观测，那可能是他们没有使用真实数据作为决策的指标。这可能是过早的优化。我重视一个根据真实的测量数据做出决策的团队（特别是关于绩效），这也适用于许多其他事情。
如果面试官知道这些问题的答案，这是一个很好的迹象，说明该团队是高质量的。如果他们不知道为什么需要关心这些指标，那可能是一个负面信号。
关于教条的规则在这里仍然适用。如果团队已经锁定了一个未必能产生价值的，可操作强的指标，并且他们无法解释这一点，这可能是一个负面信号。
后续问题：
- 您最重要的产品指标是什么？
- 你使用什么观测系统？ （例如，MixPanel，statsd 等）
[h2]
[/h2][h2]7、如何查找和修复 bug？[/h2]
一个强大的团队通常有专门的测试人员，与此同时团队的开发人员也专注于质量。一个真正强大的团队有令人印象深刻的自动化测试。有些团队太小而无法拥有专门测试人员，但这并不意味着他们是一个糟糕的团队。当我问这个问题时，我试着去感受他们的测试过程。他们是否总是火烧眉毛？他们是否有一个理智发现和优先考虑错误的过程？他们是否依赖用户查找 bug？
后续问题：
- 如何优先处理错误？
- 使用什么错误跟踪器？ （和你讨厌什么）
- 使用Excel来跟踪错误吗？ （nooo！）
- bug跟踪器有多少个bug？
- 错误需要多长时间修复（最小/最大/典型）？
[h2]
[/h2][h2]8、你使用什么协作工具？[/h2]
根据我的经验，好团队使用大量的协作工具。他们经常使用聊天服务（Slack，IRC，HipChat，Jabber），代码审查服务（Gerrit，GitHub，GitLab，Review Board），当然还有电子邮件。我正在寻找每个人如何知道其他开发人员在做什么的方式。我并非在寻找细节，更多的是为了通识。此外，我希望看到同协作工具集成。最简单的例子是可以发送自动构建失败消息的电子邮件。 web-dev团队的另一个例子是自动化错误记录服务，当严重错误发生时或当关键指标跨越某个阈值时通知团队。
[h2]
[/h2][h2]9、你使用什么框架？[/h2]
我个人对框架的态度：
- 我喜欢现代的东西
- 我喜欢令我感到新奇的东西
所以如果一个团队在 Motif 中构建一个 AIX 桌面应用程序，我可能不感兴趣。但对你来说这可能是一个有趣的主题，你应该对自己的喜好有一个很好的了解。
不管您的框架偏好，了解为什么团队选择了该框架很重要。他们是炒作驱动的吗？他们改变框架像换内衣一样频繁吗？他们被困在古老的版本上吗？
关于为什么问该问题，我是想了解开发商在选择技术方面有多大的自由度。管理层是否决定技术选型？管理层是否依赖于开发人员？要解决这些问题，我通常会问：“你是如何在项目中使用框架 X 的？”。如果开发人员不知道答案，这可能是一个坏迹象，也可能他们是新人。
我喜欢看到团队为他们使用的开源项目做出贡献。这告诉我，他们不仅可以使用开源代码，而且还能熟练掌握它。这才是我愿意与之共事的开发人员。如果公司愿意为他们这样做付出就更好了。这告诉我公司了解成为开放源码社区一分子的意义。
如果团队正在重造轮子，而不是使用随时可用的工具来帮助他们建立自己的产品，那么我就会紧张。这个规则也有例外。例如，当 Facebook 这种体量的工资正在自己的框架上工作时，我就不会紧张（或者我会的）。
[h2]
[/h2][h2]10、我们什么时候可以尝试一起工作？[/h2]
如果您想要清楚地了解与该团队合作的内容，那么请尝试与他们一起工作。我从来没有做过这件事，但我有一个朋友做过（有可能是故事）。我认为这是一个好主意。如果你想了解有关团队的任何事情，请和他们一起工作半天。当然这可能需要您签署 NDA。如果团队愿意考虑这个想法，我认为这是一个非常好的迹象。
如果要这样做，您可能必须与管理人员进行沟通，所以这个问题更多地是为了得到开发人员的反应。他们可能对这样的想法感到震惊，认为不值得。
[h2]
[/h2][h2]11、你的下一个截止日期是什么时候？（由 Evan Farrer 撰写）[/h2]
这个问题旨在让您更了解公司实际遵循的开发过程。这个问题本身并不能带来丰富的信息，但是当你提出这些问题时，事情会更加有趣：
- 谁设定这个期限？
- 你在最后的截止日期前完成工作了吗？如果没有，为什么不？
高质量的团队一致同意截止日期并设定该日期。任意修改的截止日期可能是工作协同出现问题的征兆，或者至少说明在确定时间表时工程师没有话语权。
[h2]
[/h2][h2]12、建立新的开发环境需要多长时间？（作者 Evan Farrer）[/h2]
这个问题有助于衡量公司在开发者体验方面付出的努力。新的开发人员需要几个小时，几天或几周的时间来设置计算机并准备开始编码？是自动还是手动？这将告诉您，团队在“支持活动”中的熟练程度（与编写软件无关，但有助于支持该目标）。团队是否认真对待这一问题？
有些公司为新开发人员有配套的配置流程感到自豪，因为新的开发人员可以在第 1 天将代码投入生产。这表明该公司为开发人员提供了无缝的体验。
[h1]
[/h1][h1]针对技术经理的问题[/h1][h2]
[/h2][h2]1、你最后一次写代码是什么时候？[/h2]
（面试官：咳咳（尴尬），旁白由高可用小编贡献）
我喜欢拥有强大技术背景的经理人。无意冒犯我的 MBA 朋友，但我真的喜欢那些和我有类似经历的经理。
[h2]
[/h2][h2]2、你是怎么成为一名经理的？[/h2]
我认为好的经理是发自内心的喜欢而非被迫成为经理。我喜欢管理人员专注于为他们的团队服务。我最喜欢的经理是那些专注于自己的团队改善而不是“管理”的人。他们认为自己是团队的帮手和保护者。他们有一种服务态度，他们会认为最重要的工作是让团队成员工作的更好。
[h2]
[/h2][h2]3、你的工程师如何知道每天的工作？[/h2]
既然我问了工程师同样的问题，我就会和经理的答案进行比较，看看他们是否匹配。如果不匹配，可能意味着有一些协作上的矛盾。工作中最可怕的问题是无法辨识的问题。我认为这是经理的工作，确定工作中的问题并解决它。
[h2]
[/h2][h2]4、现在团队最大的挑战是什么？[/h2]
他们通常回答说是工作人员短缺。因为这是一个显而易见的答案（他们毕竟是招聘），所以我想问第二大挑战是什么。我正在寻找像延迟时间表，产品质量问题和人际关系的问题。每个团队都有问题，所以你得到的答案取决于几个因素：
- 经理对问题的意识
- 经理是否诚实地对待你
- 队伍中的问题的严重性
[h2]
[/h2][h2]5、你如何衡量员工的个人表现？[/h2]
熟练的经理将有很好的技术手段来做到这一点。当评估个别团队成员的表现时，最好的经理将会仔细收集整个团队的反馈意见。不好的经理将会根据自己的观察点作出评价，而不咨询小组。
[h2]
[/h2][h2]6、你做正式的绩效面谈吗？[/h2]
我喜欢为那些重视反馈意见并帮助团队成员改进的经理工作。绩效评估可能是痛苦，也可能是积极的过程。根据我自己的观察，我认为大多数人认为这一过程是痛苦的。一个真正伟大的经理将会明白这一点，并且将采取措施，以某种方式使绩效评估变得非常好，让您印象深刻，并希望为他们工作。
后续问题：
- 你能告诉我一段时间你帮助某人提高他们的表现吗？
- 在这些考核中你如何教导人？
[h2]
[/h2][h2]7、你每年都会给下属调薪吗？[/h2]
我想知道我的薪酬是否会根据我对公司的贡献进行调整，我们每年至少会对其进行一次官方的评估。对于这样的公司，我喜欢询问有关股权的问题。你会给我股票期权吗？你能每年给我更多的股票期权吗？
有些工程师对问这样的财务问题会感到不舒服。工程师通常花费很小一部分时间来思考这些问题，但管理人员总是会被问这些问题。这些问题不应该让经理感到不舒服：
- 你如何进行加薪预算？
- 去年的中位数上涨是多少（百分比）？
- 我可以期待一年以后多少工资？最好的情况，最坏的情况？
我不会将这些问题写入合同，这些问题也不会保证未来的加薪。相反，我想了解公司如何运作。我是需要用我的方式来要求加薪呢，还是有一个已经就位的标准过程？
[h2]
[/h2][h2]8、我可以得到一些描述公司福利的资料吗？（供稿人：Evan Farrer）[/h2]
我认为大多数人已经知道要问这个问题，但为了完整起见，值得一提。大多数公司都准备给你一堆纸或一个描述公司福利的网站。重要的是要知道，因为它通常是您很大一部分补偿。这可能只适用于美国。我不知道公司提供的医疗保险奖励在其他国家如何工作。
[h2]
[/h2][h2]9、你会给员工排名吗？（供稿人：Matt Ryan）[/h2]
一些公司将排名和奖金相关，通过排列每个员工，从最坏到最坏，使一定比例的员工进入“好”，“平均”和“坏“子列表。
我从来没有见过一个喜欢排名的工程师。这在大公司中尤其常见。它可以影响你与同龄人的互动，因为你知道有一天你必须与他们争夺钱。
当我遇到这种情况，并不意味着公司是一个可怕的工作场所。在这样的公司里，通常会有一些明面之下的操作空间。询问面试官他们喜欢该系统。一些管理人员对于系统的不满情绪会很坦率，有的甚至会告诉你他为团队争取利益的“游戏”系统策略。如果你找到这种经理，你也可以忽视排名系统。
请记住，并不是每个人都讨厌这个系统。只因为我没有遇到喜欢该系统的人并不意味着他们不存在。
跟进问题：
- 你真的认为X％的员工“坏”吗？这对你的招聘过程有什么看法？ （这是一个大胆的问题 – 小心谨慎）
- 你应用某种曲线来确定表现最好的人吗？
- 您使用什么指标来对员工进行排名？
- 您如何知道这些指标是否准确收集？
- 您如何知道这些指标实际上是最佳表现？
[h1]
[/h1][h1]针对公司领导层的问题[/h1]
面试并不总是能碰到公司的高层领导（特别是对大公司来说），但是当有这样机会时候，我把它作为评估公司财务可行性的机会。我可能没有资格这样做，但有一些明显的问题，我有时可以通过面试发现它们。此外，我也想知道自上而下的文化是什么，因为这些信息可以告诉我公司如何重视工程师价值。
[h2]1、你们资金情况如何？[/h2]
我正在努力了解公司背后的资金。我想知道他们是否由风险投资，私募股权，公共股票或通过收入自筹资金。通常我可以在面试前弄清楚这一点，但公司的领导层常常会给出一些通过 Google 或 CrunchBase 找不到的见解。
[h2]
[/h2][h2]2、公司盈利了吗？[/h2]
如果盈利了，太棒了！如果没有盈利，你们的盈利计划是什么？一些创业公司有盈利计划，而其他创业公司则通过收购或 IPO 寻找出路。
后续议题：
- 过去几个季度/年的历史收入。它向上趋势吗？
- 竞争风险，如竞争，意外费用和收入不足。
- 跑道：在筹集更多资金前，公司可以运营多长时间。
[h2]
[/h2][h2]3、你对外包有什么看法？[/h2]
我申请的工作是否可能会在未来被外包，或者这项工作是否可以变成管理外包的工程师。
这里不只是问离岸外包，包括各种合同方式的外包。
[h2]
[/h2][h2]4、公司文化是什么？[/h2]
这是另一个问题，我用来对应工程师与领导层的观点。我正在寻找里面不同的地方。如果领导和工程师观点接近，这表明了良好的从上到下的沟通。我想知道高层领导是否与海内外员工脱节。我也想看看领导层是否有远见，是否沟通良好。我喜欢的公司需要有一个强大的，共同的愿景。
一些公司非常重视文化，这可能是件好事。至少你会清楚公司的价值观。对于其他公司，你必须通过隐含的，有时候是不言而喻的细微差别来确定。公司文化是非常重要的。有政治斗争吗？有专业价值吗？诚实是否被看重？有加班费吗？
[h2]
[/h2][h2]5、你如何确保这个公司会取得成功的？[/h2]
随着这个问题，我也会寻求真实的证据，而不仅仅是营销炒作的信息。如果高层领导给我实际的数字，如收入，市场规模和资本化，这是一个好兆头。此外，如果我可以从其他来源验证这些信息，那就更好了。另一方面，某些数字可能表示非常糟糕，公司的资金只够再烧一个月了。
[h2]
[/h2][h2]6、告诉我你的汇报关系。[/h2]
（面试官：这个面试者好霸气！旁白由高可用小编贡献）
对我来说，这个问题的最佳答案是一个简单的答案。如果该人可以画出一个解释汇报关系结构的简单组织结构图，我很满意。我个人的喜好是为小型，敏捷的公司工作，而组织和通信开销最小。您的偏好可能会有所不同。不管你喜欢什么，这个问题都是为了给你所需要的信息，以便对该公司做出明智的决定。
[h1]
[/h1][h1]结论[/h1]
面试是双向的。 如果您有幸获得 offer，请确保您的经验做出明智的决定。 祝你好运！
推荐阅读
本文作者 Dave Smith，由 jesse 翻译，转载请注明出处，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。
高可用架构
改变互联网的构建方式
长按二维码 关注「高可用架构」公众号
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/256012.html