积累知识并不只是简单地收集信息，更重要的是通过连接，将零散的点串联成一个系统化的理解网络。这个思路源自我阅读《卡片笔记写作法》的启发，其中将连接想法比作修建城市间的铁路。这样的连接能够创造出滚雪球般的复合效应。

几年前，我逼着自己去健身房，结果买了一年的会员，却只去过两次。如今，我每周迫不及待地去游泳，是为了享受在水里畅游的感觉和之后高质量的睡眠。

长期地做一件事情，单靠意志力是不可持续的。关键在于找到一种能享受当下的方法，通过一个即时的反馈回路，让你的行动获得正向奖励。否则，意志力很快余额不足，难以坚持。

有的面试官招人又准又快，有的面试官好不容易招来的人试用期没过就走了，面试官本身都是团队的骨干，为什么在面试质量上差距如此之大？因为面试也需要技巧，特别是记分卡。

什么是记分卡？

记分卡用分数匹配职位和应聘者，匹配的越好，得分越高。

记分卡由不同考点组成。有的测能力，包括技术硬能力，也包括沟通，决策等软能力。有的考态度，看人是否诚实热情，积极坚定。和考点对应的是应聘者的表现以及得分。

下面是一个记分卡的例子。面试的是工程师，考的是软实力和态度。

“你对本次面试有什么反馈？”

一个应聘者说，“非常棒，我觉得你真正在乎我的经历和需求。不像其他的面试官，问我五年计划是什么，然后缺点是什么。我特别不喜欢面试官按照清单念问题。”

得到这样的反馈既开心又惭愧，我确实有个问题清单，也念了其中一些问题，幸好交谈是自然的。面试不是审问，加上人才稀缺，我们既要考验应聘者，又要保证面试体验。这其中的秘密，就是高效而又自然的追问。

面试官学习开放式提问，是为了评估应聘者组织语言的功底。而作为应聘者，有没有什么应对的办法吗？Star框架用过的都说好，来瞧瞧。

什么是Star方法？

Star是Situation、Task、 Action、 Result的缩写，它可以帮助应聘者设计回答的架构。

• 面临的场景：你遇到了什么困难。有那些出乎意料的事情发生了。或者你对什么不满。总之这种情况不能一直保持下去。
• 承担的任务：你的职责是什么。你按月拿工资是为了完成什么任务。在其位思其政，你不能眼睁睁的看着上述情况继续下去。
• 采取的行动：在如此场景下你采取了什么行动，来改善情况，推动事情想好的方面的发展。
• 获得的结果：你最终改善情况了吗，完成了任务了吗，学到什么了吗。

为什么好用？

Star方法好用，一是它引人入胜，听起来像讲故事一样。这是因为它开头引入冲突，设置了悬念。然后介绍故事的主角，他是谁，他是干什么的，他为什么被拖进的冲突之中。进而表明他和困难做了哪些斗争，最后取得了什么结果。按照这个千百年来人们讲故事的套路，听的人肯定爱听并且能听懂。

第二个原因，就是Star方法是一种结构清晰的框架。它有利于人们不断的重复的训练而习得其精髓，进而把各色各样的故事给装进去。

什么时候别生搬硬套？

在学习这个框架之前，有必要提一下它的使用范围，别生搬硬套，闹了笑话。

如果面试官问的封闭的，或者是有标准答案的开放性问题，你最好开门见山，展现你的技能。比如说问你操作系统是如何控制CPU的。建议你不要讲一个你和CPU的故事，丁是丁卯是卯，你说明白就行了。可如果你真有一段和CPU美妙的故事，那么尽情的去征服面试官吧！

如何练习Star方法？

练习Star方法做好的方式就是日积月累。当你在平日的工作中，有什么心得，有什么经验教训，或者主动采取了什么行动的时候，可以试着用Star的方法把他们总结出来。这样你的素材会越来越多。接下来给大家分享几个我遇到的例子。

告诉我你曾经犯过的一个错误

听这个问题，一定要听到弦外之音，面试官真正想要的不是你犯的错误，而是你犯过错误之后学到了什么，做了什么来避免今后再犯同样的错误

场景：为了实现一个新功能，我需要修改数据库的数据模型，添加一个新的列。这个列很简单，我之前也做过类似的操作。为了节省时间，我没有在开发环境里测试，就直接把它部署到生产环境了。结果，我在修改的时候，不小心设置错了列的模型，导致生产环境中断了几个小时。

责任：作为Tech Lead，我犯了一个特别低级的错误，为了防止我的组员今后犯下同样的错误。

行动：我起草了一个部署数据库模型修改的清单，清单里确保所有的修改，不管有多简单，都必须事先在开发环境里经过测试，确保得到的结果是预期结果。

结果：这个清单帮助我们的组员切切实实的走过必要的每一步，避免了很多人为的因为疏忽大意而导致的错误。并且这个清单，在每次有新的经验或教训的时候，都会被更新。这样一来，我们不断积累数据库更新的经验，为我们自动化数据模型更新打下了基础。

请描述你曾做过的一次主动提议

这个问题算是问的比较直接，就是你的主观能动性，是不是曾经自驱改善过什么

场景：经过入职培训，我开始接受团队里的任务，可我发现很多东西在入职培训里我都没有接触，搞的我不得不四处打探那些其实很基本的问题。

责任：作为已经经历了入职培训的员工，一方面我不希望以后把自己的时间花在回答这些本来可以自学的问题上，也为了让今后的入职员工能更快的上手

行动：我找了我的经理，给他建议我们应该在入职培训中加上一个应用程序的实战演练。通过这个演练，新员工可以学会如何写一个API，如何写数据库的请求，如何部署一个服务。获得经理的同意后，我就着手设计了这个实战演练，并且把它加到了入职员工培训的手册里。

结果：如此一来，新入职的员工，通过完成这个实战演练，在结束培训后，做到了真正的可以直接为团队做贡献。并且这个实战演练，只写一次，却可以培训所有新入职的员工，事半功倍！

结语

希望你体会到了Star方法的好处。可就像学习其他任何技能一样，明白道理只是开始，愿你日常的生活中，能付诸行动，多多试验这个方法，等到真正用上的时候，厚积薄发。

和我一起面试的同事提醒我，说有时候我提的问题，聪明的应聘者可以看出来答案。他建议我多问开放式问题。让我们拿这篇文章来研究面试官如何掌握开放式提问。

什么是开放式提问

所谓开放式提问，就是不同的回答者会给出和自身经历密切相关的答案。举例说，您曾经犯过的一个错误是什么？人犯的错误千姿百态。相反，封闭式问题的答案，选项有限。打疫苗的时候，会问最近有没有发烧，有没有高血压，有没有过敏史，有和没有选一个。

为什么要开放式提问

封闭式问题获取信息高效，可为什么面试官却青睐开放式提问？因为它不仅可以帮助面试官全面衡量应聘者的能力，而且让面试任务变得更加有趣一些。

开放式提问的最大威力是挖掘回答者的沟通能力。当一个开放式问题抛出去的时候，回答者大脑里，面对非常多的可能性。如何筛选有用的信息，组织信息的传递结构，让对方准确无误的明白回答，是回答者面临的一个大挑战。不信？可以试试这个问题，请讲讲你曾经做过的一个艰难的决定。

开放式提问还可以看出回答者的思想高度。有的人能从大局观着手，看清外部内部形势，从多个角度，多个层面，多个时间维度给你将清楚一个问题。而有的人，直入事情的某个细枝末节，让你迷失在他的世界里。

开放式提问可以让交流更加人性化。在一个疯狂生长的组织里，面试官每周要面对很多应聘者，如果问题都是封闭式的，面试官就成了一个复读机。开放式问题带来的是五彩斑斓的个性故事，给枯燥的面试任务增添了不少调味剂。

如何学会开放式提问

要学会开放式提问，一是问题不能过于宽泛，二是不要给出太多提示。

学会开放式提问的第一步是确定要评估的能力。开放式问题不是无边无际的问题，讨论的不是无穷无尽的宇宙，而是要有一定的引导性。这个引导性就是你看重什么？如果你想知道应聘者的团队合作能力，就问设计方案是怎么定下来的？如果看主观能动性，就问自主解决过什么问题？

定了方向，可以让问题有的放矢。然而，给出的信息也不能太多，面试者一定要培养耐心和好奇心。

我经常陷入一种半开放式提问的困境中。

起初提问是开放式的。比如说，这个项目成功的关键在哪里？有些回答者想了很久也不说话，有的给了我预想外的答案。我常常忍不住提示回答者从客户反馈上，项目管理的角度上想一想。而这些提示，不仅限制了对方的思考范围，而且传递了我想要的答案。

所以，要想开放，就要有耐心。对方需要时间去思考，就给他时间。要着急的不应该是面试官，而是应聘者，这是考验大家忍受空白的能力。其次就是要有真挚的好奇心。不要把自己的答案，强加到对方身上。也许你的答案很不错，但是别人可能有更好的想法。如果答案确实不如意，你想深挖一些，与其给提示，不如问应聘者有没有要补充的。

你呢，有什么学会开放式提问的妙招吗？

技术管理者的成长中，有两个因素的比例会发生变化：技术和管理。起初，技术占主导地位，比如 Tech Lead 会花时间做架构设计，写代码。接下来，从管理一个团队，到管理多个团队，技术的比例会降低，管理的任务会增加。技术就像功夫一样，一旦停下来，就退化了。保证下属，特别是 Tech Lead 下属工作的质量，作为管理者，要学会借助外力。

Tech Lead 接受一个新项目，经过一段时间的努力，敲定了解决方案。管理者要求 Tech Lead 把他的方案展示给其他团队里的 Tech Lead 做审查，收集不同方的意见，完善方案，就是所谓的借助外力，保证质量。

管理者也可以亲自上阵做方案的可行性分析，然后拍板做决定。可这样做有好几个缺陷。一是管理者本身的技术洞察力会退化，所做的决定会有片面性。二是，管理者会耗费时间去查看具体的事务，占用自己的时间不说，还很有可能成为团队进展的瓶颈。最后一点，管理者如果幸好采纳了 Tech Lead 的方案，下属的积极性不会受到影响。而一旦管理者开始发表自己的看法，引入自己的理念，对原有方案进行修改的话，就会导致方案执行过程中，下属因为执行的不是自己的想法，而有所保留主动性。相反，像【影响力】中说的那样，一个人更容易被和他有着相同背景的人影响， Tech Lead 更容易采纳和他们有着相同身份的人的意见，而并不觉得被人强加了不属于自己的想法。

因此可见，借助外力，不仅可以节省管理者自己的精力，使解决方案更加完善，还可以确保方案的执行过程中下属保持高昂的积极性。如何才能借好外力呢？

首先，找到合适的 Tech Lead 圈子。不同的 Tech Lead 有不同的优势，要想得到贴切的意见，必须要有的放矢。作为管理者，要刻意的去培养这个圈子。当别的 Tech Lead 收集意见的时候，管理者自身和下属要积极的贡献想法。礼尚往来，当你们需要审查的时候，别人也来帮助你们。

其次，要选择好时机，不要等到万事俱备才找外力。要在设计初期，几个大方向明确下来的时候，征求别人的意见。此时的意见是最具有价值的，它们可以帮助 Tech Lead 砍掉不靠谱的分支，把精力集中到最有潜力的大方向上。如果拖得时间太长，越晚整合别人的意见就越麻烦。

最后，要保证在展示解决方案的时候，有态度，刻意的制造辩论点。我见过一些 Tech Lead ，在展示自己方案的时候，缺乏故事的带入性，一个人像念经一样，让别人不知道如何提意见。要想收集到有用的反馈，Tech Lead 要讲清楚所面临的的挑战及其背景，然后态度鲜明的讲解为什么你采纳了当下的选项，而拒绝了其他的。有取有舍，才能有辩论点。

技术管理者，随着管理任务的增加，技术投入的减少，必须学会从，事必躬亲做事情，到排兵布阵管事情的思维转变。只有这样，才能真正发挥团队合作的威力。