首页 » 编程知识 » 针对工程师、技术经理及CTO的提问指南

针对工程师、技术经理及CTO的提问指南

admin 编程知识 88 次浏览 没有评论
程序员精选俱乐部

在面试中,您通常会遇到三种角色。根据公司的规模,可能是一个人或多个人:

  • 软件工程师
  • 技术经理(技术负责人,中层管理人员)
  • 公司领导(副总裁,CTO,首席执行官,部门经理)

我将在下面列出针对这些不同角色的不同问题。我有时会对多个角色重复相同的问题,以了解和比较他们的答案。

针对工程师、技术经理及CTO的提问指南

这是一篇很长的文章,它的意义更多是作为参考,而不是为了你照本宣科。如果我今天正在面试,我会看看本文,并在面试中(谨慎地)参考本文内容。

大多数问题没有“正确”或“错误”的答案。它们旨在帮助您了解公司,了解其文化,流程和组织。当您的大脑卡壳时,他们也可以作为对话开头,在面试中可能会非常有帮助。

我通常在面试开始时告诉面试官,我想有一些时间提问。这将有助于他们指定相应的面试计划。通常情况下,在面试结束时面试官会让我提出问题。每个问题后,暂停以询问您是否可以继续提问题,以及面试官还有多少时间。

针对软件工程师的问题

1、你怎么明确每天的工作?

这个问题的目的是确定是否有协作上的问题。我想从 2 – 3 名工程师那里得到答案。如果公司领导说他们遵循一定的过程,但工程师不会谈论这个过程,那就是协作问题的征兆。如果您从不同的工程师那里得到不同的答案,这是另一个工作协作问题的征兆。

在高质量的团队中,我会得到一致的答案。每个开发者都知道这个过程,并且可以很好的支持工程师的工作。

有一个好答案的例子(还有很多其他的):“我们做 N 周的冲刺,其中每个工程师承诺提供一组功能和修复错误。我们每天都会报告我们对彼此的进展情况。我们有一个产品经理,帮助我们处理优先级较高的功能和错误修复。“

也有一个坏的答案的例子(还有很多其他的):“我进了办公室,看看是什么出问题了。大多数时候,我会被紧急事务打断。“

注意我没有提到“Scrum”或任何其他具体方法。我对工程师实际的日常“如何做的事情”更有兴趣,而非工作过程的使用的标签。

2、用于版本控制的工具是什么?

使用良好的工具是好团队的特征。如果一个团队正在使用一个古老的版本控制系统,那么他们可能会使用一些其他过时的工具。此外,他们可能不重视投资良好的工具以实现工作效率增长。

询问工作流程是非常好的进一步的问题。你使用分支版本吗?你喜欢 rebase 还是 merge(git术语)?这些问题会告诉你,他们所选择的工具有多么的专业,同时将会告诉你很多他们熟练程度的信息,反过来也告诉你如果你接受这项工作,你会有什么期待。例如,你会成为“本地 git 专家”,还是跟随一个名副其实的 Linus Torvalds 学习?

从这个问题可以开始关于一般工具的讨论,这通常会给你一些很好的见解。

3、在这里工作你喜欢什么?

正面的答案:我从我所做的工作中获得了满足。

正面的答案:我们在工作中有很多乐趣。

正面的答案:我喜欢与真正聪明,友好的同事合作。

正面的答案:尊重工程技术。

这样的答案越多越好。我不一定因为上面的答案给公司高分。请记住,有些人不会透露真实想法,所以你可能不会在这里得到同样的反应,这也是正常的。

但是如果我听到以下几种答案,我就会感到紧张:

负面的答案:帮助我支付账单。

负面的答案:我不用努力工作。

负面的答案:没有很大的交付压力。

负面的答案:如果我犯了很大的错误也没什么。

负面的答案(沉默)

这不是我编的答案。我真的在面试中听到过这样的答案。

如果我偶尔听到这些负面答案,我不会自动认为它是一个糟糕的公司,但如果这是唯一的答案,我通常会在其他地方看看。

4、你写单元测试吗?

(面试官:咳咳(尴尬),旁白由高可用小编贡献)

根据单位测试实践对工程团队作出结论时要小心。当我询问单元测试时,如果一个团队兴奋不已,这通常是一个好兆头。另一方面,如果他们不能解释为什么需要单元测试,或单元测试的缺点,这可能是盲目的教条主义。如果他们无法给出不写测试的理由(特别是像我们没有时间这一借口),那对我来说是一个糟糕的迹象。

如果工程师告诉我他们编写单元测试,他们就能够告诉我们有关指标。例如测试运行多长时间,有多少测试以及代码覆盖率,这对我来说非常有吸引力。这表明他们有好工具,并且知道如何使用它们。另一方面,如果他们认为 100% 的代码覆盖确保了一个无错误的代码库,那么我很有兴趣加入。

通过本问题,我可以知道是否会在一个大的,旧的,未经测试的代码上工作。这将帮助我管理自己的期望,并决定这是否是我想做的事情。

后续问题:

  • 你喜欢单元测试还是集成测试?
  • 你有验收测试吗?
  • 你使用什么测试框架?你喜欢它吗?
  • 您的单元测试要运行多长时间?

5、你有持续集成吗?

好的软件开发团队使用 Jenkins,Travis 和 Buildbot 等工具。如果团队没有持续集成,我会尝试衡量他们是否熟悉这个概念。如果不是不熟悉,在我的经验中这是一个坏迹象。持续集成系统意味着团队可能相信自动化,这在我经验中通常是好迹象。

对于一些团队,这自然而然导致了关于持续交付的讨论,这是与持续集成相关但不同的概念。如果这是网站开发人员的职位,我希望团队至少听说过持续交付,而强一点的团队则至少在一定程度上使其成为现实。

后续问题:

  • 当 CI 报告失败时,您的团队需要多长时间才能解决问题?
  • 你喜欢/不喜欢你的 CI 系统?
  • 您的 CI 运行一次需要多长时间?你会让他们更快吗?

6、你会观测你系统中哪些东西?

这是一个开放式问题,旨在了解该团队是否努力观测其软件。对于 Web 开发团队,答案往往侧重于性能指标,如服务器响应时间,请求吞吐量,用户数量,客户端响应等。但是讨论可以涉及到像不同语言的用户数量,浏览器崩溃,缓存命中/错失率以及无数其他主题。

如果团队没有花时间来观测,那可能是他们没有使用真实数据作为决策的指标。这可能是过早的优化。我重视一个根据真实的测量数据做出决策的团队(特别是关于绩效),这也适用于许多其他事情。

如果面试官知道这些问题的答案,这是一个很好的迹象,说明该团队是高质量的。如果他们不知道为什么需要关心这些指标,那可能是一个负面信号。

关于教条的规则在这里仍然适用。如果团队已经锁定了一个未必能产生价值的,可操作强的指标,并且他们无法解释这一点,这可能是一个负面信号。

义乌奥美编程,转载链接。

本文永久链接: http://code.ywbb.com/89.html

发表评论

Go