我不常与招聘人员交谈。事实上，我通常不与第三方招聘人员合作，因为他们往往只对填补职位空缺、收取佣金然后继续下一个职位感兴趣。此外，大多数招聘人员并不真正了解以 DevOps 为导向的组织的需求。但是，优秀的招聘人员通常是寻找优秀人才的最佳知识来源。
当我坐下来写一篇关于 DevOps 招聘的文章时，我知道候选人和招聘经理的想法将得到 Opensource.com DevOps 社区的充分报道。但我认为，从招聘人员那里获得一些关于如何为 DevOps 职位寻找、培养和招聘优秀人才的技巧会很棒。
欢迎 Ken M. Middleton，他来自 Your DevOps Recruiter。去年，Ken 联系我，希望在我找工作期间进行合作，我很快就认识到他的诚实和坦率。Ken 知道我正在寻找的东西超出了他的能力范围，并告诉我了。在那一刻，他赢得了我的尊重。
我和 Ken 坐下来，向他抛出了一系列关于招聘的问题。以下是我们讨论的一些重点。
我从一个非常直接的问题开始：您如何找到顶尖人才？
Ken 提供了两个有趣的答案。“您可能猜到第一个答案是：LinkedIn。对于任何招聘专业技能人才的人来说，LinkedIn 都是真正能够挖掘潜在人才的绝佳工具。我认为这就是 LinkedIn 为自己创造的东西。你在 LinkedIn 上看到的人，他们实际上并没有在找工作，但他们愿意听取关于工作的信息。我能够与他们建立联系。我认为人们真的需要理解 LinkedIn 是一个双向的街道。”
Ken 补充说：“这是我努力做好的一件事，我一直在为此努力。您正在根据 LinkedIn 个人资料以及个人资料的强度和他们创建的品牌来关注最优秀的人才。但您自己也必须拥有一个非常强大的品牌。因此，对我来说，我的 LinkedIn 个人资料是我营销平台的一部分，当我联系某人时，我希望他们明白我身处 DevOps 社区——我评论 DevOps 相关的事情；我正在关注不同的 DevOps 文章。”
Ken 的第二个答案对于熟悉 Opensource.com 的人来说并不意外，但可能会让 DevOps 世界中的一些人感到震惊：“您必须积极参与您所在的地区，无论是通过聚会小组，还是通过其他不同的 DevOps 或 AWS 小组，或任何其他联系或课程论坛。您真的必须看看那里有什么，走出去与人们见面。”
想象一下！打破信息孤岛的协作在 DevOps 招聘中起作用。这是一种经常被忽视的招聘方法。
您不需要有职位空缺来提升自己并结识志同道合的人。我尝试鼓励与我一起工作的内向的人更多地参加聚会和社区活动。您不一定需要在这些活动中发言。您甚至不必提问。但至少去向某人介绍一下自己。最终，您会找到一个有相似兴趣的人，您可以与他们讨论事情。建立这样的关系将为您带来招聘以外的好处。
填补未填补的 DevOps 职位空缺
在与 Ken 的谈话中，我了解到许多 DevOps 职位空缺都未被填补。
“我从事 IT 招聘领域已有 11 年了，但当我离开之前的公司并在 2017 年 3 月开始自己创业时，我开始关注所有这些 DevOps 职位，我意识到很多职位都没有被填补。其中一些职位已经空缺了将近一年。我不明白问题出在哪里。”
Ken 继续说道：“我开始做一些研究，我发现的是，您的一般招聘人员试图招聘这些职位，但他们不清楚 Git 和 GitHub 之间的区别。他们不知道持续集成与持续部署的区别。因此，当他们与这些人交谈时，他们使用了所有这些通用术语，并将不合格的人推向这些职位。这只是在浪费大家的时间。如果您要聘请招聘人员来帮助您寻找人才，您真的需要一个懂行话的人。”
也花时间与招聘人员协作。在组织中将知识传播到技术团队之外可以使其更进一步。
当我问 Ken 他是否使用硅谷的招聘方法（查看候选人的 GitHub 个人资料）时，他回答说他很少这样做。“我会去查看一些人的个人资料，但我不会查看他们的代码，因为我不知道自己在看什么。但我所做的是努力确保我了解所有不同的技术以及他们如何使用这些技术。”
Ken 说，从 GitHub 招聘是个坏主意。“这具有相当的排他性。[GitHub] 帮助我整体上扩展了知识。但我不看 GitHub。我确实不断尝试找出在哪里可以找到新人，如果这是不同的途径。我一直在寻找不同的途径来找到人才。”
学习新技术
持续学习即使在高度技术领域之外也大有裨益，Ken 认真对待 DevOps 的持续学习和反馈原则。
我想向 Ken 施压，解决我在招聘人员时经常遇到的一个问题：您如何知道候选人是否可以学习新技术？您如何评估他们是否已经完全投入并与新事物隔绝？
Ken 回答说：“我注意到，与我合作过的一些经理有点过于关注特定技术，以至于他们愿意放弃在技术方面可以有所作为的优秀人才。”
很高兴知道，在评估是否聘用人员时，勾选清单上的复选框并不是最佳方法。
Ken 继续说道：“我发现 [是]，如果他们正在进行第一次 DevOps 招聘，他们会非常关注技术——而且如您所知，那里有很多不同的工具，当您查看人们可以使用的工具组合时，几乎是无穷无尽的。因此，当他们如此专注于，嘿，这个人必须具有这种配置管理工具、这种监控工具、这种容器工具的经验时——这就像——好吧，他们可能需要拥有这些经验。但让我们谈谈您想要完成什么。他们可能会学到什么？以及您正在寻找的文化方面是什么？我发现，当您遇到对技术过于具体的经理时，他们的职位很难填补，这几乎是不可能的。”
为文化契合度而招聘
在我们的谈话中，文化和寻找文化契合度这个话题出现了几次。Ken 的回答永远改变了我面试的方式
“我总是喜欢问人们，‘告诉我，您理想的角色类型是什么？如果您可以随心所欲地选择您想做的事情和您想在其中工作的环境类型，请与我谈谈。’因此，当我和人们一起工作时，我尽量不要以工作为先。我可能会告诉您，‘嘿，我有一份工作，您需要 XYZ 技术’，但我不会告诉您文化是什么样的。我不会告诉您公司是什么样的。我不会告诉您任何关于公司正在寻找什么的信息，因为我想听听您在寻找什么。如果您说的内容与我正在寻找的内容一致——我认识一些人，他们说，‘我想在一家初创公司工作——我喜欢忙碌的环境；我喜欢一直学习新事物，我喜欢他们没有流程到位。’好的，这听起来像一家我正在合作的公司。但如果您告诉我——我也经常听到——‘我想要一家成熟的公司；我不希望担心从现在起两年或 18 个月后，当我们的众筹没有成功时，我会失去工作’——我会倾听。我让他们告诉我他们想要什么。这让我了解了他们正在寻找什么样的文化。”
太棒了！方法不应该是向某人推销一份工作，而是找到最适合您的文化和需求的人。硬性推销通常会让一个人接受。但是，如果一位候选人需要被推销到您的公司，您认为他们会在一两年后还在吗？
确保职位适合候选人的需求和愿望，然后再告诉他们更多信息。
推荐人调查中的秘密
我问 Ken：您如何验证您对候选人才能的评估？
Ken 对这个问题给出了一个有趣的答案：“您必须核实他们的推荐人。您必须打电话给与他们共事过的人，与他们谈谈这个人是什么类型的员工。我喜欢我的顾问，我认为他们很棒，我总是会为他们辩护，但我从不相信顾问的话。我做不到。我在这里为两个人服务：我在这里为客户服务，我也在这里为您服务。而我把您放在一份您实际上不合格或与文化不符的工作中，这既对您不利，也对我不利。”
您如何根据推荐人来衡量某人是否适合特定职位？
“我会核实他们的推荐人，我心里知道客户在寻找什么，但我不会以这种方式引导推荐人。我会问一个问题，例如，‘嘿，告诉我关于 John 的情况。告诉我他是什么类型的工作者。请向我介绍一下您对他在日常工作中的期望。他的软技能是什么？他的缺点是什么？他是如何处理这些缺点的？’我正在倾听所有这些事情，然后一旦我对他们是否匹配有了很好的认识，我甚至会问——而且大多数时候这都很有效：‘这是这个人可能要进入的环境类型。他们正在寻找 X、Y 和 Z，这个、那个和其他。您对这个人完成这项工作的能力有什么看法？’”
“而且我遇到过一些人——您可以看出有些人会说，绝对的，这个人非常适合——或者当他们开始给您限定条件时，例如，‘如果他们这样做，他或她会很好’，或者‘这是我认为您需要确保这个人理解的内容。’这有助于我描绘出一幅这个人是否总体上合适的图景。但这是一个漫长而彻底的过程，因为它确实需要时间。而且这不是一门完全的科学；它有点像一门艺术。”
您如何衡量推荐人的质量？您如何验证候选人发送的是朋友而不是经理的推荐？
“我使用 LinkedIn 来验证推荐人。我不接受朋友，我不接受同事；我接受经理。当人们给我他们说是经理的人，而我无法通过 LinkedIn 验证时，这也是一个危险信号。而且我很少推荐这些候选人，因为他们给我的是同事，却说是经理。幸运的是，借助 LinkedIn，您现在可以过滤掉很多此类信息。”
建立融洽关系、发现危险信号和衡量人才
与候选人互动时，建立融洽关系非常重要。找到共同的兴趣点进行交谈。如果这种兴趣来自职位本身，那就更好了。Ken 详细阐述了这个想法
“我试图在您的 LinkedIn 个人资料中放入一些能够引起您的共鸣并让您说‘好吧，让我与这个人联系并进一步了解他们’的内容。我总是对人们使用的一件最大的事情是，‘嘿，听着，即使您现在没有找工作，与招聘人员建立联系以了解市场上的动态始终是有意义的。我是一位 DevOps 招聘专家；我很乐意与您分享我在市场上看到的情况，您现在不需要寻找任何东西，但一两年后，如果您正在寻找，我希望我们建立一种让您感到舒适的关系。’因为建立信任的关系需要时间，而这正是我真正向人们推销的：我想在您不寻找工作时与您交谈，这样当您准备好时，您会感到放心，因为您知道我可以代表您辩护。”
令我懊恼的是，频繁跳槽在招聘中被视为非常糟糕的事情。Ken 解释说
“人们频繁跳槽始终是一个危险信号。除非您是 H-1B 候选人——有些人只是处于需要接受合同工作的境地——如果您有一份工作，如果您每 18 到 24 个月就换一次工作，这只是一个危险信号，因为一定有什么原因让您无法长期从事一份工作。现在，我知道人们说千禧一代、千禧一代会这样做。这是真的，但许多公司都在寻找能够在职位上工作超过 18 到 24 个月的人。如果候选人跳槽如此频繁，一些客户甚至不会考虑他们。他们甚至不会看他们。”
我问 Ken：您如何衡量对特定技能或人才的需求？ 听到人们正在寻找 Kubernetes 技能，我并不感到惊讶。
“幸运的是，我隶属于一家名为 TEEMA Group 的公司，所以我可以看到甚至我的合作伙伴发布的职位。因此，当我开始看到大量职位要求某种技能时，我就可以判断这种技能更受欢迎。就像现在，Kubernetes——几乎每个人和他们的表亲都在试图找到一些具有 Kubernetes 经验的人。许多公司正在考虑容器化、微服务，以及与级别相关的 Kubernetes，他们意识到在他们的环境中使用它可以带来的好处，这是一个非常热门的领域。”
“除了 Kubernetes 之外——我的意思是，它一直如此稳定。其他一切都只是遍布各行各业。每个人都想要 AWS——尽管越来越多的公司正在使用 Google Cloud，因为我听说它真的很好，很多人都喜欢它。但 AWS 是您在 DevOps 世界中的首选；如果您没有 AWS 经验，您真的会限制自己的机会。您几乎必须尝试获得一些 AWS 知识才能在目前可能 80-85% 的 DevOps 环境中工作，因为它长期以来一直是首选，人们只是在不假思索地使用它。我不知道有多少人关注 Azure，但 AWS——它们让许多竞争对手相形见绌。如果您没有经验，您真的需要获得这两种经验。”
我请 Ken 详细说明他是如何评估某人对于像 Kubernetes 这样新技术的技能的。
“这又回到了我们之前讨论的内容。这就是我现在所处的位置。我有一个客户想要一个具有 Kubernetes 经验的人，这个职位已经空缺了两个月，我们找不到任何有经验的人。当我们有一个非常非常好的人时，他正在寻找的东西，那个人接受了另一份工作。我尝试做的是帮助我的客户理解您需要在某些技能上稍微妥协，并关注那些有能力掌握它的人，那些非常擅长 Docker、使用过不同集群、对 Kubernetes 有一定了解并且可以掌握他们不了解的东西的人。我尝试真正关注他们之前所处的哪些情况让他们不得不学习一项他们不了解的技术。他们是否具有已被证明的能力来完成他们需要做的事情以快速掌握一项新技术？”
DevOps 职位头衔
关于 DevOps 职位头衔存在大量争议。值得庆幸的是，谷歌的 Liz Fong-Jones 和 Seth Vargo 已经结束了关于 SRE 与 DevOps 的争论。但是 DevOps 工程师的头衔呢？
“您知道，这是一把双刃剑。因为以前，您会遇到一些人称他们为软件工程师，但他们使用了所有不同的工具。他们使用了 Docker、Jenkins，以及所有这些 VM 工具——Chef、Ansible 和 Puppet——但他们被认为是软件工程师。人们当时被低估了，因为他们的头衔没有说‘DevOps 工程师’，但他们确实是，对吧？而且您今天仍然会看到一些这种情况。因此，现在发生的事情是，每个人的简历上都有‘DevOps 工程师’。我的意思是，并非他们没有经验——因为他们中的许多人确实有不错的经验——但这就像如果有人接触过任何类型的自动化系统或自动化工具，甚至只是做过 shell 脚本，他们就会在简历上写上 DevOps，他们就是 DevOps 工程师。”
除了“DevOps 工程师”之外，还有其他突出的头衔吗？
“‘DevOps 工程师’是一个重要的头衔。‘站点可靠性工程师’也一直存在。‘构建和发布’。这是您一直看到的三种头衔。然后有些人只是称自己为‘软件工程师’，但如果您查看他们的简历，他们正在做很多 DevOps 相关的事情。但是 DevOps 头衔确实已经普及，并且出现在每个人的简历上；它只是一个热门流行语。”
我希望您发现我们的对话和我一样具有启发性。我很乐意在评论中听到您的想法。
[请参阅我们的相关报道，谁在驱动卓越招聘的文化？]
评论已关闭。