几年前，我有一些感悟，就和我的团队讨论，如何改变项目经理的角色——我们将要努力实现的行为方式。少关注待办事项，多关注业务；少强调“知”，多强调“学与问”；多关注与客户一对一的交流，少关注汇总数据。我们想在团队中引入能帮助我们进行这种文化变革的人，但是，我们仍然在问同样的面试问题，使用同样的面试风格。所以，我们重新思考了我们的面试方式，并想出了一些对我们有用的东西。
现在，我们已经做了一段时间了，我们认为有必要分享一下我们所做的和所学到的东西。
感悟1:：我们还在问过时的（无效的）问题
第一个感悟是在开始变革PM角色之后，我们注意到，我们仍然在问过去10年甚至更久之前的面试问题。当我们试图寻找能够为团队带来不同技能和观点的人时，这些问题是没有意义的。（注：我开始在微软工作的时候，我们还在问为什么井盖是圆的，一架747飞机能装满多少个乒乓球，以及如何反转一个链表。20年后，我还没有编写反转链表的代码，或者用任何球填满一架747）。
不仅如此，有时候，两个面试官会无意中问同样的基本问题。即使在协调面试话题的时候，不同的面试官也是依赖于相同的核心问题目录。有些问题——基于行为的问题——并不可怕，但我们并没有特别有效地利用它们。
感悟2：并不是每个人都能在快节奏、高压力的环境中做到最好
第二个感悟是在一次会议上。思想高速运转，人们试图借由别人的话把自己的想法引入对话，我们很快就做出了一些重大决定。至少，我确信这将是一个重大的事件——我被一个客户问题搞得心烦意乱，正与客户经理和工程团队一起努力让一个客户摆脱困境。那是另外一回事了。不管怎么说，会议开得很成功，其中一位与会者——我团队里的一位PM，他非常聪明，也非常安静——说，实际上，“我只是在互联网上搜索了有关我们主题的信息，是的，这个想法行不通。”她的态度比这要好。但我，并不是所有人都能在这种快节奏的头脑风暴中表现出色。很多人（包括我）喜欢坐着喝杯咖啡，看一些数据，然后试着把事情想清楚。更重要的是，在我的职业生涯中，我几乎没有一次不在我们做出重大决定时离开一段时间，用新的眼光、新的数据和新的客户研究来看待这个想法。
但大多数面试都是这样的快节奏：对于从未见过的情况，你能多快想出解决问题的办法。
感悟3：看别人如何工作的最佳方式是和他们一起工作
第三个感悟是在我和我们的几个工程团队讨论他们如何将人们引入他们的团队时产生的。开发部门做了很多开源工作（其中包括.NET Core、VS Code、TypeScript等项目）。作为面试过程的一部分，我们的开发团队已经开始与应聘者一起解决一个Bug或开发一项特性。这是一个应聘者和团队合作共同解决一个真正的问题的过程。
写下一个想法并迭代
鉴于“写作就是思考”，我给自己写了一封电子邮件，告诉自己我的团队可以采用如何不同的面试方式。然后我和团队中的很多人分享了我的想法，我们开始迭代。像Karen Ng、 Amanda Silver、Cindy Alvarez、Nathan Halstead、Anthony Cangialosi、Jeff McAffer、Jessica Rich、Travis Lowdermilk等人都参与了迭代和试验。
当我们准备推出时，我们从很小的地方入手，然后继续学习、迭代，然后扩展。现在，这个框架（我们称之为“另类面试框架”，因为我们中没有人特别擅长起名）是我们的标准实践——我们不断改进并从中学习——它对我们非常有用。
以下是我们做的一些与众不同的事情。
提前分享面试
首先，我们要提前几天让应聘者知道面试当天的情况以及我们要解决的问题。我们给他们时间做他们自己的研究和思考。上班并不是每天都会出人意料，那么为什么面试应该是这样呢？
使用一个实际的问题
其次，我们会借助一个团队正在努力解决的实际问题——提高满意度、增加留存率、提高服务或特性的使用率。事实上，这是我们正在研究的一个真正的问题，这有助于促进合作对话。
为应聘者提供数据
第三，我们给应聘者提供我们在工作中所使用的信息，在面试过程中，他们可以自由上网或要求提供更多数据。我们经常为应聘者提供我们的客户研究、使用情况数据、设计和模型——几乎是我们拥有的一切。
使面试过程更具互动性
第四，我们使面试过程更具互动性。我们不是在问你问题。我们有一个问题要一起解决，所以让我们以你加入我们之后的方式开展工作，我们在处理这个特定的问题。
顺着单一场景
第五，我们一整天都顺着一个单一的场景/问题，将应聘者带入到类似PM所经历过的旅程中，从客户或业务问题开始，理解客户的待完成工作，设计解决方案，将解决方案交付到客户手中，最终让他们使用并热爱它。每次面试会关注这个过程的不同阶段。
让面试官结对
第六，我们会让面试官结对。我们不是一对一的面试，而是每次面试时团队中都有两个人参加。我们最初的动机是培训更多的面试官，但房间里有两个人还有其他好处。与多个合作者的对话会更有活力，而且让我们有机会从多个角度聆听同一个对话。每个人聆听对话的方式会有所不同，所以，这给我们提供了一种方法来检查在同样的对话中的无意识偏见。
把反馈放到最后
第七，我们将面试官之间的反馈放到一天结束的时候。我们希望每位面试官都能根据谈话本身的价值来判断应聘者，而不是根据之前的面试官的意见。我们告诉面试官，不管他们是否倾向于建议我们录用某人，都不要向别人发出信号。他们把应聘者交给下一组面试官，并对我们在上一环节中了解到的内容进行总结。在一天结束的时候，每个人都同时提出他们的建议，并对他们所看到/听到的内容做一些解释，说明他们为什么得出了这个结论。
提供关于面试过程的反馈
第八，在每轮面试的最后，我们不仅要与应聘者讨论我们在面试中所了解到的内容，还要讨论在面试过程中什么有用，什么没用。我们会据此优化这个过程。
我知道，这个过程中还有其他一些方面我忘记了，但这八个方面是最重要的。
我们学到了什么？
我们担心应聘者会紧张。两个面试官。一整天都顺着一个实际的问题，使用真实的数据。我们的担心是多余的。几乎每一位应聘者都主动反馈说，这个系统是独一无二的，真得帮助他们了解了我们的业务和团队。甚至那些没有得到工作机会的应聘者也喜欢这个面试过程，明白我们为什么没有提供工作机会。
不断改进这个过程
我们发现我们还有一些不足之处。例如，我们的PM团队非常偏技术。许多PM将代码检入生产产品。这对我们来说是有意义的：我们的客户是开发人员，因此，拥有那种来自软件创建过程的客户理解是有帮助的。但是，在这个过程中，我们并没有很好地深入了解应聘者的技术技能。所以，我们增加了一个面试环节，以便有更多的技术交流。
组织工作
我们了解到，这个过程不利于标准的面试组织工作。举个例子，由于应聘者在处理同样的问题，并在白板上写下他们稍后需要的东西，我们需要为应聘者保留一个专门的空间（会议室或专注室），面试官会去找应聘者。
面试十分“昂贵”
我们知道面试十分“昂贵”。每次面试两个人，我们投入的时间和人力都是两倍，这大大增加了日程安排的复杂性。然而，在最初一些关于费用的抱怨之后，团队中的每个人都开始看到了好处，比如，团队中有更多的人见到了我们潜在的新员工。所以，我们愿意付出这个代价。
归根结底，招聘过程的目标是把优秀的人才带到团队或公司——确保他们是合适的，会取得成功，并为他们创造良好的体验，使他们想要加入。有一位应聘者，她收到了来自我们和西雅图其他几家大型科技公司的竞争邀请，她明确地选择了我们的团队，因为她非常喜欢这个过程。她碰巧是实验阶段中我们的早期候选人之一，她还在这里，而且做的很好，我们有许多员工是通过这种方式招聘的，所以我说，我们做得很好——我们仍然在学习，但是到目前为止，结果已经超过了我们的预期。
查看英文原文：Rethinking how we interview in Microsoft’s Developer Division