BAT程序员面试的关键点,你Get 到了吗?

Posted 2021-05-01 泽林教育

你有没有参加过面试，面试官看着坐在桌子对面的你问：“你有什么问题吗？”，你只是看着他说“嗯，我没有问题了”。如果这曾发生在你身上，那么很有可能你对面试体验有很片面的看法。

可以理解，作为候选者你只关注一个结果：获得一个 Offer。但是不要忘记面试不是单向的。你应该关注面试这家公司就如同他们关注面试你一样。

但是你应该问他们什么呢？

许多开发者都曾问过我这个问题。在过去的15年中，我曾为7家公司工作（包括两个实习职位和在一个创业团队工作的6个月），我也面试过数十家其他的公司。最终我决定写下我在面试中问过的问题，希望能够给其他人提供一点帮助。

你将和谁交谈？

在面试中，你通常会遇到三种角色。这些角色会是一个人或者多个人，取决于公司的大小：

1、软件工程师

2、工程师经理（技术 leader，中级经理，总监）

3、高层领导（VP， CTO， CEO， 部门经理）

对每一个角色我都有不同的问题，我将在下面一一列出来。注意我有时会重复用同一个问题问不同的角色然后看看他们的回答有何不同。

这是一篇很长的文章，所以它的意义更多是作为参考，而不需要通篇细读。如果我今天要去参加面试，我会带着这篇文章并在面试期间参考一下。

这些问题中的多数都没有一个“正确”或者“错误”的答案。它们是用来帮助你了解这家公司、以及其文化、流程和组织。它们通常也作为交谈的开始，这在你面试中出现大脑短路时非常有用。

作为礼貌，我常常在面试一开始就告诉面试官我希望有一点时间来提问。这有助于他们合理安排时间。通常，他们会在面试的最后让我提问，所以注意面试的时间安排，也让他们提前意识到你的意图。问完每一个问题，停顿一下，问一下面试官你是否可以继续提问以及面试还剩余多长时间。

01

每天你怎么知道需要做什么事情？

这个问题的目的是确认功能缺失。我希望从2-3名工程师哪里获得答案。如果公司的领导说他们遵循特定的流程，但是工程师却不谈这个流程，那是一个功能缺失的迹象。如果从不同的工程师那里得到不同的答案，那是另一个功能缺失的迹象。

在一个高质量的团队中，这个问题我所得到的回答是一致的。每一个开发者都知道这个流程，并且这个流程足够轻量级到对工程师提供帮助而不是压制他们。

好的回答示例（还有许多其他的）：“我们会制定 N-星期的 sprint，在每一个 sprint 中工程师会提交一系列的功能和 bug 修复最终交付。每一天我们会相互汇报进度。我们有一位出色的产品经理负责和客户交涉，以保证我们优先开发功能和修复 bug。”

不好的回答示例（还有很多其他的回答）：“我到办公室然后看看哪里需要救火。大多数时候我都被紧急情况中断。”

注意我没有提到 “Scrum” 或者其他特定的方法。相比实际的日常开发怎么完成，我对公司在他们的过程中所使用的标签没什么兴趣。

02

你用什么来做版本管理？

好的工具是好的团队的一个指示。如果一个团队在使用一个古老的版本控制系统，他们也许还在使用一堆其他过时的工具。而且，他们可能不重视良好工具投资所获得的效率提升。

紧接着一个很好的问题是关于工作流。你使用分支吗？你喜欢使用 rebasing 还是 merging（git 术语）？这些问题会告诉你他们所选的工具有多么专业，这将会告诉你很多他们的熟练程度，反过来告诉你如果你接受这项工作，将会有什么期待。例如，你将是“本地的 git 专家” 还是你将向名副其实的 Linus Torvalds 学习？

这个问题可以引发一场通用工具的讨论，这通常会给你一些好的见解。

03

在这里工作你喜欢的是什么？

强回答：我从我的工作中获得许多满足。

强回答：在工作中我们有很多乐趣。

强回答：我喜欢和真正聪明、友好的合作者一起工作。

强回答：管理尊重工程师。

强回答越多越好。我不必获得以上全部回答来给公司打高分。请记住，有些人不是自然而然的“装腔作势”，所以在这里你可能不会获得精彩的反应，这可能是正常的。

但是如果我听到了类似以下的回答，并且没什么强回答，我会担心：

弱回答：它付我工资。

弱回答：我不需要很努力的工作。

弱回答：这里交付没有太大压力。

弱回答：即使我犯了大的错误也不要紧。

弱回答：（沉默）

不要以为是我想象的这些回答。我在真实的面试中听到过这些回答。

我不会听到这些弱回答就自动将这家公司看成不好的公司，但是如果只有这些回答，我通常不会考虑这里。

04

你写单元测试吗？

在通过一个团队的单元测试实践对他们做出结论时要很小心。如果在我问道单元测试时一个团队非常兴奋，这通常是一个好的迹象。另一方面，如果他们不能解释为什么要使用单元测试，或者说单元测试的缺陷时，这是盲羊教条的一个迹象。如果他们提供一些不好的理由来解释为什么不写单元测试，如“我们没有时间”，那对我而言是一个不好的信号。

如果工程师告诉我他们会写单元测试，并且他们尝试告诉我单元测试的考量，比如需要多长时间来运行单元测试，他们有多少测试用例，以及代码覆盖率等，那对我是非常有吸引力的。这告诉我他们有很好的工具，并且他们知道怎么使用这些工具。另一方面，如果他们相信100%的代码覆盖率就能保证代码中没有 bug，我表示怀疑。

我想提前知道在这家公司我是否会在一套庞大、陈旧、无法测试的代码上工作。这将帮助我管理自己的预期，并且决定是否接受这份工作。

后续问题：

你喜欢单元测试还是集成测试？

你们有验收测试吗？

你使用什么（哪些）测试框架？你喜欢吗？

你的单元测试需要耗费多长时间？

05

你使用持续集成吗？

我所知道的最好的软件开发团队使用 Jenkins， Travis， Buildbot 等工具。如果这个团队没有持续集成，我尝试了解他们是否熟悉这个概念。如果他们不熟悉这个概念，以我的经验这是一个不好的迹象。使用持续集成意味着这个团队也许信奉自动化，以我的经验这通常是一个很好的迹象。

对于有的团队，这自然会引导到持续发布的讨论，这是一个和持续集成相关但是又不同的概念。如果是一个 web 开发者职位，我希望这个团队至少听说过持续发布，强的团队应该使用持续发布，至少有一部分在使用。

后续问题：

当 CI 报告失败时，你们的团队需要多长时间来修复？

你喜欢/不喜欢 CI 系统的哪一点？

你们的 CI 运行一次需要多长时间？你有让它更快一些吗？

06

你们怎么测量？

这是一个开放问题，主要是看看这个团队是否花精力去测量他们的软件。对于 web 开发团队，答案倾向关注性能，如响应时间、请求吞吐量、用户数量、客户端反应灵敏度等。但是也可以讨论使用不同语言的用户数、浏览器故障、缓存命中率等无数其他的事情。如果一个团队没有花时间去测量，很有可能他们没有根据真实数据来做决定。他们可能已经提前优化。我重视使用真实数据来做决定的团队，尤其是有关性能方面，但是它适用于很多其他方面。

如果面试官知道这些问题中多数答案，那是一个很好的信号说明这是一个优质的团队。如果他们对为什么要关注这些测量没有任何主意，这是一个负面的信号。

再次声明，教条主义同样适用于此。如果一个团队看起来已经锁定了一些不会产出价值或者可操作信息的测量指标，并且不能对此给出满意的解释，这可能是一个警告信号。

后续问题：

你们产品最重要的测量指标是什么？

你们使用什么测量系统？（例如：MixPanel）

07

你们怎么发现并修复 bug？

强队通常都有专用的测试人员，团队的开发人员专注于质量。一个真正的强队有强大的自动测试。有的团队太小而没有专用测试人员或者自动测试，但是并不意味着他们是一个不好的团队。当我问这个问题的时候，我是想感受一下他们的流程。他们是否总是火烧眉毛？他们是否有清晰的流程用于发现 bug 并为 bug 排出优先级。他们是否依赖用户发现 bug。

后续问题：

怎么为 bug 排优先级？

使用什么 bug 追踪系统？（你讨厌它的哪一点？）

你们使用 Excel 来跟踪 bug 吗？（不！！！）

在你的 bug 跟踪系统中你有几个 bug？

修复一个 bug 你需要多长时间（最少、最多、平均）？

08

你们使用什么合作工具？

以我的经验，优质的团队会使用许多合作工具。他们常常使用聊天服务（Slack，IRC，HipChat，Jabber），代码 Review 服务（Gerrit，GitHub，GitLab，Review Board），当然还有电子邮件。我在寻找每个开发者知道其他开发者在做什么的信号。我不是在寻找疯狂的细节，更多的是想了解一般意识。此外，我喜欢看到集成合作工具。最简单的例子就是当自动编译失败时会自动发送一封邮件。web 开发团队的另一个例子是当严重错误发生时或当关键指标跨越某个阈值时自动错误 log 服务发送通知到团队的聊天室。

09

你们使用什么框架？

我个人偏爱框架两个方面：

1、我喜欢现代的东西

2、我喜欢新（对我而言）东西

所以如果一个团队在使用 Motif 开发一个 AIX 桌面应用，我可能不会感兴趣。但是可能你会喜欢。这是一个深刻的个人喜好问题，你应该对自己的喜好有一个很好的了解。

不管你个人对框架的喜好是什么，了解他们为什么已经选择了他们的框架非常重要。他们是跟风？他们频繁的更换框架？他们的代码库就是一堆本月框架榜单中的代码堆积？他们一直使用古老的版本？

在为什么这个主题上，我希望了解在选择技术时开发者有多少自由。管理层是否授权技术选择？管理层是否听从开发者？为了了解这些问题，我通常会问“你们是怎么开始在项目中使用框架 X 的？”。如果开发者不知道答案，这也许是一个不好的迹象，也有可能他们在公司的时间不够长还没有参与做这个决定。

我喜欢看到团队为他们使用的开源项目贡献代码。这说明他们不仅能够使用开源代码，同样还足够熟练到为它贡献代码。这是我喜欢共事的开发者。如果公司乐意为开源项目付费，那就更好了。这说明公司理解了成为开源公民意味着什么。

如果团队重新造轮子而不是使用已有的工具来帮助他们开发项目，我会感到紧张不安。这条规则也有例外。例如，当 Facebook 也曾开发他们自己的框架，我不会反对他们那样做的。

10

我们什么时候可以结对？

如果你真的想清楚了解与这个团队共事是什么样子，尝试真正的和他们一起工作。我个人从未这么做过，但是我有一位朋友就这么做了。我觉得这是一个很棒的主意。如果你想了解这个团队的每一件事情，去和他们一起工作半天。这可能需要签署 NDA 协议。如果这个团队愿意考虑这个建议，我觉得是一个很好的迹象。

你可能需要通过管理人员来安排，所以设计这个问题主要是想看看开发者的反应。他们可能会感到震惊，因为他们觉得不值得提到管理层。

11

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

这个问题是希望更多的了解公司实际遵循的开发流程。单从这个问题不会获得非常有用的信息，但是当你添加上这些问题，事情就变得有趣得多：

谁来设置最后期限？

你的上一个任务在最后期限前完成了吗？如果没有，为什么没有？

高质量的团队会一致同意并承诺最后期限。随意设置最后期限是功能缺失的迹象，或者至少说明工程师在设置最后期限时没有发言权。

12

搭建一个全新的开发环境需要多长时间？

这个问题帮助判断公司花费了多少精力在开发者体验上。一位新的开发者是需要数小时、数天还是数周才能拥有搭建好环境可用于开发的电脑？这个过程是自动的还是手动的？这将告诉你这个团队在“支持活动”上的高效并不和开发工作直接相关，但是这种高效却有助于他们的开发。团队有认真对待这件事情吗？

有的公司引以为傲的是：他们有开发环境搭建流程，可以快速的让新的开发者在第一天就能提交代码到生产环境。这说明公司很认真的对待为开发者提供无摩擦体验。

13

结论

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