当不懂某项技术时候，如何面试工程师？
导读：原文是针对不懂技术的公司创始人招聘CTO或者工程师时候的一些参考建议，作为技术负责人，也常常面临需要面试不熟悉领域的工程师，比如前端背景负责人面试后端工程师，工程背景技术负责人去面试算法专家，本文的思路值得参考。
当你在招聘工程师，但无法评估候选人某项技术能力时，可以聊聊性格和流程方面的问题。
我看到的创始人最常遇到的招聘难题是找一个合适的技术联合创始人、CTO 或第一任工程师。招聘已经够难了，你还需要和其他公司创始人竞争，因为其他创始人都在努力招聘最优秀的人才。你必须以某种方式脱颖而出。光是你的想法还不够强大。
现在是开发者最好的时代。
让你的招聘问题更加复杂的是，你很可能没有评估技术人才的经验。你可以通过文化、态度来筛选，并从过去的雇主那里获得推荐信。但你无法知道你的候选人是否真的擅长软件开发。
不管你要找的是哪种类型的开发人员，我创造了一个非技术型的创始人在面试候选人时可以使用的问题清单。这些问题并不是编码挑战或白板练习。这些问题也并不是总是有效的，原因我将在下一次讨论。相反，这些是基于软件过程、经验和判断的问题。它们衡量了一个工程师的成熟度和创建一个健康的 SDLC 流程的能力，比你提供的任何编码难题都能更好地预测长期的成功。
我为什么要写这个？
作为一个 Lightmatter 项目联合创始人，在过去 6 年里，我看到与我们合作过的公司和创业者在招聘和留住工程人才方面都很辛苦。
两边都会犯错误。在面试时，初级开发人员往往会夸大自己的能力；早期的创始人也不能犯这样的错误雇佣一个青涩的人。非技术型的创始人在面试时也会问错问题。有经验的开发者不希望自己的时间被一个自以为 "技术过硬 "的创始人浪费掉。缺乏工程领导力，会扼杀一个创业公司的招聘能力。
通过学习问正确的问题，你会表明你已经花时间去了解你的软件和整体开发者文化。然后，你也会知道正确的答案是什么。
以下是我想问的问题。
1、你以前参加过的软件团队的规模是多少？最大的？还是最小的？
当雇佣你的第一个开发者时，第一个问题是，你想通过你的第一个 App 的构建来实现什么？只是一个原型？是否打算放弃它或在以后的日子里用不同的编程语言重新编写？还是你需要第一次就把技术平台搭建好，因为你已经测试过你的想法，现在是时候执行了？
如果是第一种选择，请雇佣（或者更好的是，直接签约）以前只做过单干的工程师。他们不会因为担心测试覆盖率、代码版本控制、或者执行过于彻底的 QA 等问题而造成负担。他们不需要担心任何其他工程师的工作，可以只专注于代码的发布。
但是有趣的是，你不能保证他们是否有资格完成你所要求的工作。最好情况就是朋友介绍，或者之前和他们合作过，但也不确定他们使用的工具是否正确，或者是正确的构建。这就是缺点。
但如果你找到了合适的开发者，他们可以在短时间内出产惊人的代码。这里需要注意的是，单个工程师之所以能够如此快速地工作，不一定是因为缺乏团队经验。更多的是他们可以忽略软件的协作方面的问题，而不是让它拖慢一个项目的进度，也没有为别人编程的负担。编程界有句老话：读（别人的）代码比写代码更难。
如果是第二种选择，那就雇佣有实际工程团队经验的开发人员。没错，这意味着即使只是两个人的团队。一旦有另外一个人和他们一起写代码，开发人员就需要考虑流程问题。
即使没有其他人在身边，他们也会知道版本控制和分支管理的重要性。他们会花时间和你一起清理需求积压，并评估某些技术决策的利弊。比如使用哪家云服务商来做托管？为什么选择 Python 而不是 Ruby 或 Node？在部署后当测试覆盖率下降时，他们会不高兴，他们会在代码中留下评论和大量的文档。他们正在和你一起构建一个产品，其他工程师将能够以惊人的速度加入并做出贡献。
2、如果您在一家较大的公司工作过，比如说 30 个工程师或更多，那么在整个 Sprint 中，团队是如何划分的，任务分配和项目管理的？在公司的流程中，喜欢和不喜欢的是什么？
如果你和一个有扎实的团队经验的工程师聊天，很有可能他是公司内多个团队中某个 3-5 人小团队的一员。其中一个团队很可能是数据库团队。另一个是负责移动应用的团队。也许另一个负责安全，或者一个负责前端。
如果是这样，这是一个好的迹象。有很多团队各自编写自己的代码、集成和发布，候选人有软件项目管理的意识。询问他们的团队在大公司中是如何运作的。他们是否使用敏捷、看板或 Scrum？他们的 Sprint 时间有多长？
你的候选人很可能有你核心应用逻辑相邻的软件基础设施的经验，这些经验对于你的开发流程的顺利运行是必要的。这些如持续集成和部署流水线的组件，或衡量测试覆盖率的套件，它们是让你的团队能够做好工作的工具和配置，是技术基础，当出现问题时，会让你更容易调试。
当你的公司优先考虑这样的工程文化时，它就是一个更强大的招聘工具。工程师们都希望与那些建造酷炫的东西的人一起工作，就这么简单。在开发流程中处于领先地位，就是一种证明方式。
总的来说，在谈论团队管理的时候，没有正确或错误的答案。更多的是让你有机会倾听候选人的意见。唯一的红色信号是，如果他们之前的公司有一个流程，但候选人选择忽略了这个流程。
3、你在以前的公司做软件的时候是怎么评估的，准确度如何？
软件工程的一个普遍的刻板印象就是项目进度总是落后。在初创公司，延迟时间可能是几周到一个月。而在企业级，则可能是几年。出现这种情况的原因有以下几个。
工程师们都很乐观，我们是问题的解决者。我们可以用我们的代码来解决任何问题。有了这些，我们的估计也会变得过于乐观。这种急于求成的心态与不断改变项目范围的经理们一起，是一个致命的组合。
延误的项目是工程文化的一部分，所以像布鲁克斯定律这样的规则也就存在了。在一个已经延误的项目中增加更多的工程师，只会让项目延迟更多。世界上最好的计算机科学家研究过软件估算和时间表，对于如何规划，没有一个好的答案。
工程师通常会收到延误的责备，但从来都没有白纸黑字的时间表。估算时间本来就是一项复杂的工作，这是我在专业上做过的最困难的事情。当经理有不切实际的期望或要求过于精确的估计时，工程师就会产生敌意。
我见过有经理和非技术型的创始人对工期 6 个月以上时间的项目，要求的估算要精确到每小时。怎么会有人现实地要求这样做？
不可能的，不要成为那个创始人。不要对你的团队这样做。这是让工程师辞职的最快方法。没有人能把一个项目的所有任务都估计到小时之内。即使是一个 2 周的项目也很难做到。
也许你的工程师可以为几个功能进行估算，但精确不到小时。最起码要考虑到至少半天的改动。不要使用 "4小时" 和 "8小时" 之类的估算，要用半天和一天。如果你不这样做，你就会陷入以小时为单位思考工作。
如果你面试的工程师提到他们公司是按小时估算的，那可能不是那个工程师的错，除非他之前是 CTO。而这也没有关系。对他们来说是个英雄，如果这个话题出现的话，你可以把工作范围调整到更大的时间段，对他们来说是很舒服的。
如果他们确实有大块工作的经验，或者使用跟踪系统，那么就问一下准确性。让他们有机会分享成功的经验，并对他们的估计错误表示一些谦虚。当工程师能够积极地谈论这两种情况时，这是一个好的迹象。
总的来说，更重要的是你的应聘者曾在一个团队中工作过，在这个团队中存在一个软件的范围和估算过程，而不是评估他们的时间线实际的准确度。
4、你在与上级合作时遇到过哪些问题？有没有在公司里遇到过“第二系统”（重新造轮子） 的问题？
在工程中，还有一种模式是开发者、项目经理、高管们会误认为的，他们现有的平台不够好。需要一个替代品，并且以一种大刀阔斧的方式解决了他们所有的软件问题。这种 "第二系统 "通常一旦建立起来就会失败，实际上比第一个系统更复杂，更糟糕。
你会经常听到同事们说，"我们要从头开始重建我们的 APP，让它变得更好、更快、更优雅。" 另一个可能是 "如果我们能使用[引入新的编程框架、语言或数据库]，我们的应用就会好上 10 倍，我们的用户流失率就会降低，并达到增长目标。"
要注意这一点，作为创始人，不要总是认为自己需要一个新的工具或框架来完成每个项目的工作。我见过一些盈利的公司的创始人，他们的收入都是用电子表格和电子邮件建立的，7 位数的收入，零代码的公司。
问一下你的候选人，问一下他们与上级经历过的好的和坏的情况。问他们是否经历过软件失败或目睹过第二系统案例。关于需求范围变化的情况如何？他们是如何应对的？
这些问题突出了他们在艰难情况下的反应。他们是否辞职了，所以才会来面试？他们是否坚持下来了？
作为面试官，这个时候真的是工程师评估你是否有能力去定义需求范围和领导一个软件团队的时刻。他们很可能比你更担心你的期望值或产品选择不切实际，而不是担心他们没有达到最后期限。
5、您是否从事过任何开源项目？如果有，是哪些项目，为什么？你经常使用哪些库和工具？
作为一个创始人，了解开源软件是至关重要的。事实上，它是如此重要，你很可能要用它来构建你的大部分应用。作为一个非技术性的创始人，你可能不知道这是个什么东西，但从高层次上来说，它是别人写的代码，并授权给其他人使用，互联网上的任何人都可以免费使用或修改。
你的候选人是否曾经做过开源项目并不关键。请将其视为额外的奖励。开发或维护一个开放源码库需要大量的空闲时间，它不是一项不劳而获的工作，也几乎是一份没有报酬的工作。
这里更重要的是，你的候选人必须对开源工具和框架有一定的工作知识，并且有足够的成熟度，知道什么时候可以完全定制一个功能，而不是使用免费的开源软件。
根据你所构建的内容，如果你需要用户登录和退出，你的工程师很可能不应该开发自己的自定义验证系统。或者，如果你需要在你的应用程序中使用日历或日程安排功能，有很多开源库可以管理所有围绕日期和时区的棘手规则。相信我，你不会想从头开始构建这个功能。
我见过无数的创始人雇佣了一个工程师，他们觉得自己需要定制一切。那是一个错误。工程师吹嘘自己有多棒，可以自己构建任何东西，而创始人却喝了这杯酒，认为他们的 APP 是万无一失。他们认为，更多的 "定制代码 "意味着更好、更多的专利。
当我们继承了一个代码库，围绕着与 APP 核心业务逻辑无关的基本功能进行自定义逻辑的时候，我就会很难过。没有理由去重建已经存在的功能!
记住--大多数基于 Web 和移动端的软件工程都是复制、粘贴和调整代码。而不是从头写起。寻找那些能够聪明地谈论整合和使用他人代码的候选人。
总结
这些问题的目标是让你衡量 ego、流程和策略。如果候选人提到他们从未提交过错误的代码，违反最佳实践，或者是另外一个人的阻挠者，这就是一个红色信号。你很可能不应该与该候选人合作。
优秀的工程师（以及任何有性格的人）都会公开谈论他们的错误。
请记住，任何第一次招聘都有很大的风险。这对你和你的公司来说是个风险，但对他们来说也是个风险。
他们对你的信任。你的概念或业务还没有得到证实。你很可能还没有产品进入市场，也没有建立起原型。而你要依靠这个第一个工程师来帮助你实现这个目标。
要大方一点，并给予适当的补偿。
原文
https://www.greghausheer.com/articles/how-to-interview-engineers-when-youre-not-technical
参考阅读：
理想的DevOps流程怎么做？看看Slack的代码部署实践
新项目用 Rust 还是 Go ？
如何快速定位 Redis 热 key?
dubbo-go 1.4.0 版本发布，支持 K8s 注册中心、rest 协议
从lstio的角度谈微服务的一些误区
本文由高可用架构翻译。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。
高可用架构
改变互联网的构建方式
长按二维码 关注「高可用架构」公众号