工程师的人生

Q企业政治是什么意思？工程师应该了解它的哪些方面？

埃文斯所说的政治，指的是人与组织如何调和不同的目标和有限的资源。这包括为相互竞争的产品排定优先级，以及决定谁得到一个高能见度的项目、一次挺身而出的机会，或者接触资深领导的机会。它可能变得不道德，但政治的存在并不要求任何人做出不当行为。

他的第一个原则，是接受关系会影响工作如何完成。第二个是要讲道理，而不是死板或无谓地刁难。第三个是，关系技能和情商是可以学会的；工程师可以改变传达不同意见或坏消息的方式，而不必放弃技术标准。

Q埃文斯如何区分影响力与操纵？

埃文斯从动机说起：影响力是试图说服某人走向一个他相信对对方或团队有益的结果，而操纵则主要是在推进说服者自己的利益。一次透明的交换可以让双方都受益。例如，员工可以接下紧急的工作，以换取经理承诺在绩效校准会上为该员工的贡献说话。

如果员工为了争取编制而虚构复杂度，或者用选择性的证据去拆同事的台，同样的安排就变成了操纵。埃文斯指出，有道德的人也可能在别人拿出更有力的理由时输掉一次决策。

Q为什么整个管理链条可能共享同一个盲点？

埃文斯称之为“叠加的缺陷”：当经理自己也有同样的弱点时，他可能注意不到下属身上的这个弱点。他描述了自己有一段时间看重速度和崇尚行动，然后雇了同样以目标为导向的经理。其他团队把他们当作“拆迁球”，但埃文斯起初看重的是成果，没有看到造成的破坏。

雇用与经理相似的人，可能会去掉制衡，即使这在员工会议上让人觉得更轻松。员工可以观察隔级领导是否与直属经理相似、组织奖励什么样的行为，以及员工自己是不是个异类。埃文斯说，人们需要像挑选一个岗位那样，用心地挑选一位经理。

Q什么时候应该尝试修复与一位难相处的经理的关系，什么时候该转向？

埃文斯越来越倾向于：当与经理的关系行不通、而短期改善的尝试也失败了的时候，就换团队。他建议给新的安排大约三个月，最多六个月，来显示出一个积极的信号；员工不应该一边等经理改变，一边让自己的生活白白流逝。

主持人把这个检验描述为一次实验：给予一些信任，回顾哪些地方做得不错，也许在更谨慎的前提下再给一次机会。一个引人入胜的项目或被许诺的晋升，会让人更难离开，但留下应该是一个有意识的选择，接受这样的风险，而不是假定努力会迫使一位不道德的经理给予回报。

Q合乎道德地向上管理是什么意思？

埃文斯称向上管理是一项正当的技能。员工和经理可以讨论工作风格、各自需要什么信息、偏好怎样的反馈，以及紧急情况下该怎么办。目标是找到一种工作安排，既给经理有用的信息，又保留员工做好工作的空间。

他用了一个故意说得粗俗的办公桌比喻：员工可以把一个没解决的问题带到经理面前，然后留在那里；也可以通过解决它，或提出一个清晰的下一步，把这个问题拿走。经理往往看重那些减少不确定性、让自己的工作更轻松的人。

Q新员工怎样避免陷入“接单模式”？

与其请经理为自己想出下一项任务，埃文斯建议先了解团队的目标，调研手头的工作，并提出一个有理由的方案：比如说明目前的承诺，找出几项可能的任务，推荐价值最大的那一项，同时欢迎对方纠正。

他把最强的版本称为“神奇闭环”（magic loop）：发现需要做的工作，在员工自己的判断范围内处理它，并告诉经理做了什么。他描述了一位客户，花了半天时间改进一个内部工具；先请示会造成本可避免的额外开销，而完成这个无害的改进再汇报，则展现了判断力。这种自主权，取决于信任，以及一段足够经常做对的历史。

Q当 AI 或其他效率提升导致工作量超负荷时，员工应该如何回应？

埃文斯建议把产能呈现为一个共同的优先级排序问题。说明手头已经有什么，指出这些工作的价值，并提议哪些优先级较低的任务可以停掉、自动化或重新分配，以便为更高价值的工作腾出空间。

经理可能不知道一项任务的成本：听起来是小改动的请求，可能牵涉许多隐藏的限制。清楚地说明时间、依赖关系和取舍，有助于一位讲道理的经理理解情况。埃文斯还指出，企业会积累“僵尸工作”，比如没人看的报告，因为团队很少停掉继承下来的任务。如果经理无视产能的证据，坚持每项任务都必须完成，那就是关于这段关系的一个有用信号。

Q员工怎样才能发现经理最在乎什么？

他给出了几条途径：阅读经理的更新和全员信息，对比队友们在做什么，追溯工作如何与公司业务相联系，并直接去问。有用的问题包括：经理的优先事项是什么，什么让他们夜不能寐，以及被分配的任务是不是最重要的问题。

埃文斯说，经理往往有一份非正式的担忧清单，却很少收到别人主动提出的帮助。当员工主动提出处理一个真正的担忧时，经理就有动力提供解决它所需的信息和支持。一次有用的主动提议，即使两个人彼此并不特别喜欢，也能建立工作关系。

Q员工应该怎样要求加薪？

埃文斯说，胜算偏向于开口要：他引用了一项调查，大约 30% 的人要求加薪，而其中大约 70% 的人得到了一些，不过并不总是所要求的全额。他建议以理由开场，而不是干巴巴的要求。有力的理由可以包括高绩效、市场或内部薪酬的比较，以及真实的个人情况，比如家庭需要。

这场对话应当邀请经理帮助一起论证，而不是指责他们扣着钱不给。如果员工的薪水本来就不错，论证就需要更侧重于所创造的价值；如果员工工作做得好、薪资却处在薪资区间的低位，公平与区间内的空间可以支撑这项要求。

Q职场里的“礼貌的虚构”是什么？它什么时候有益，什么时候有害？

埃文斯用“礼貌的虚构”（polite fiction）指一种被接受的回答，用来让社交交流更顺畅，比如别人随口问你好不好，你说“挺好”。它也可以让经理避免强迫员工透露，所谓去看医生其实是去面试。反复出现的信号仍然可能需要注意：好几个周五的预约，可能说明一位员工在面试，或者需要支持。

他把这个词描述为人们避免艰难交流的一种方式，而不是他们就应该互相误导的证明。

Q为什么做人员管理不再是合适的选择？

在优步（Uber）走了管理路线之后，阿特曼发现一线的政治和工作的形态并不适合他。他重新转向产品和工程领导岗位。这段经历塑造了他的看法：晋升不应自动把一位优秀的工程师推向管理岗位。

Q晋升体系可能出错的地方有哪些？

他描述了 Linear 的文化：很少强调正式的级别。他认为，繁复的评分标准，会把工程师的注意力从改进产品，转移到对照清单拼凑证据上。更扁平的体系能让注意力保持在质量上，不过它也有局限，并不是对每个组织或创业者都普适的答案。

Q初级工程师怎样提问、犯错，又不惹恼队友？

主讲人说，大多数队友都希望新人成功：帮助某个人上手，对这个人、对团队、往往对帮忙的人也有好处。风险不在于问一个基础的问题；而在于无视答案，又把同样的问题再问一遍，好像之前毫无进展。

他用菜谱来说明其中的区别。在被告知菜谱和食材在哪里之后，又回来问下一步该做什么，说明没有听进去答案。照着步骤做了之后再回来，说明第三步卡在哪里，则表明你在听、也在努力。

他建议预判下一个可能的问题，并尽可能把相关的问题放在一起问。目标是学会如何独立找到答案，而不是假装自己从不需要帮助。

Q新手开发者怎样分辨一个问题是出于对代码库的不熟悉，还是出于缺乏经验？

他说，一开始，这种区别也许根本无法分清：一个问题可能来自其中一个原因，也可能两者兼有。一个成熟的代码库里，积累了多年的决策、约定和取舍。他举的例子是一个十人团队，在一个代码库上工作了两年半：其中大约嵌入了二十五个人年的背景知识。

这就是为什么学校里的练习，无法让一个人立刻推断出职场里的每一条约定。软件是在共享系统内的团队工作，而不是带着一位作者的假设的私人项目。他建议去问，并运用此前关于倾听、学会如何找到答案的指导。

Q实习生和应届毕业生应该优先关注什么？又怎样判断自己的进步是否足够？

主讲人从期望说起，而不是一个通用的产出定额。团队可能强调原始产出、高质量的交付、速度、运营工作，或日益增强的独立性。他建议先问经理，这个岗位和级别意味着怎样的成功，再去优化，以免优化错了方向。

他把与经理的例行沟通，当作对照这些期望来衡量进展、并暴露阻碍的方式。按他宽泛的描述，实习生通常被期望在实习结束时做出有意义的贡献；新工程师可能被期望参与整个开发周期，并在一两年里变得更加独立。他强调，这因团队而异。

观众的问题还问到什么时候该求助，以及如何选择实习项目或团队。回答没有给出单独的项目选择方法；其实用的指导，是澄清期望，并定期讨论进展。

Q除了写出优秀、可维护的代码，还有什么能帮助职业早期的工程师在竞争激烈的领域中脱颖而出？

他把求职中的竞争与团队内部的竞争区分开来。有限的名额，让求职时的竞争变得相关，但团队成员不需要为了晋升或职责范围而互相拆台。他警告说，隐瞒信息、闲话和嫉妒会损害集体。

他建议的差异化优势，是能够以越来越强的自主性，在软件开发生命周期的各个环节做出贡献。早期的任务可能被有意设得很小，所以一个人多快能独立工作，也许比任何一项交付物的大小更能说明问题。

Q当同龄人似乎晋升更快或头衔更高时，工程师应该如何回应？

他建议把别人的成功当作信息，而不是对自己职业生涯的裁决：如果关系允许，就问问他们做了什么，并从中学习。社交媒体呈现的是别人精心修饰的结果，这使得比较成了衡量自身处境的糟糕标准。

他补充说，如果一个人还没有成长到新的职责范围，晋升可能为时过早，而且成功既靠技能，也靠运气。可控的部分，是在跑自己的赛道的同时，培养自己的能力。

Q从应届毕业生起步，成为首席工程师（principal engineer）的第一步是什么？

他的回答是一级一级地累积。首席岗位需要积累的经验和更广的职责范围，所以过早地瞄准它，可能分散对满足当前岗位期望的注意力。他警告说，在没有做好当前工作的情况下，试图按高出两级的标准表现，可能浪费精力，并带来绩效问题。

他给出的顺序是：在入门级别做出出色的工作，赢得下一个级别，然后重复。重点不是放弃雄心，而是让每一次晋升，都建立在当前级别上已展现出的能力之上。

Q新工程师加入一个团队时应该留意什么？

他点出两个风险：对新人的支持不足，以及团队功能失调。新员工不仅应该问期望是什么，还应问有哪些入职培训和帮助可用；如果缺少支持，他们可以问将如何补上，或者期望是否应当调整。

功能失调可能包括政治、不合理的截止日期、糟糕的代码和无效的管理。他说，这些状况可能要几个月才会显现，所以手里有多个邀请的人，可以问问经理的任期，以及资深工程师待了多久。在他的例子里，资深成员接连离开、经理非常新，是警告信号，但这并不是普遍的录用规则。

他最后把新人的身份，当作一个提出资深队友可能忽略的问题的机会。有些问题可以暴露出假设，并影响团队的方向。

Q人们怎样才能被资深领导看见？

埃文斯说，能见度来自实质，而不是自我宣传：展现好奇心，对一个真正的问题带来深度，良好地协作，有时还要教领导一些有用的东西。他还会留意自然流露在这个人工作里的主动性和精力。没有真正兴趣，却去追求一种高潜力的形象，是“合适”的糟糕替代品。

Q在一次艰难的失败之后，怎样重建信任？

他建议在项目出错时，不要退缩或躲藏。领导应当说明发生了什么，承担自己的那一份，并提出可信的恢复计划。在他讲述的一次重大发布故障中，一份清晰的逐小时更新，以及愿意面对高层领导的态度，帮助恢复了信心，因为人们既看到了问题，也看到了应对。

Q你怎样识别一位糟糕的经理，或者一个可能不适合你的团队？

埃文斯把不诚实和不稳定指为严重的警告信号。他建议建立人脉和经济上的抗风险能力，这样当环境变得难以忍受时，一个人还有选择。他还指出，在亚马逊工作的体验因组织和经理而有很大差异，所以仅凭全公司的名声，并不能说明某个具体的团队。

Q一位成功的技术领导需要写生产代码吗？

埃文斯认为，领导不必是组织里最强的程序员，但应当学习架构、系统，以及兄弟团队的工作。他描述了自己为一个陌生的 AWS 网络岗位做准备的过程：阅读、请工程师绘制系统图，并向首席工程师学习。访谈还就技术深度在高管层级上有多重要进行了辩论。

Q经理怎样打造一个人们敢于表达不同意见的团队？

经理的反应，让团队知道“开门政策”是不是真的。埃文斯描述了对假设进行压力测试，并有意邀请人们提出不同意见，尤其是作为帮助初级同事练习发声的一种方式。当团队成员提出一个站得住脚的反驳时，经理必须带着好奇和欣赏来回应。

Q内容创作是怎么开始的？

在亚马逊，她是数据工程团队里唯一的女性，感到孤立，并带着冒名顶替综合征的怀疑：自己是否属于这里。大约在 2015–16 年，她开始在 Instagram 上发布小小的工作成绩、演讲和完成的项目。这些帖子帮助她找到了背景相似的科技行业女性，也让她不再觉得孤单。

当短视频兴起时，她发现自己对着镜头讲话很自在，也喜欢教数据科学和技术。短视频承载不了她想要的深度，所以她转到了 YouTube。她的第一个用网络摄像头录制的简单故事，讲的是自己如何从非技术背景进入科技行业，吸引了大量观众。她开始热爱这份创作工作，同时把表现数据描述为让人情绪疲惫。在访谈的当时，她说内容收入已经超过了她在谷歌的全职薪水。

Q你在谷歌担任首席分析负责人，具体做什么？

她负责谷歌搜索广告，包括文字广告和以图片为主的广告。她进入这个领域时没有广告或搜索方面的经验，用了几年时间学习这个领域。她认为这项工作与收入有实质性的联系，同时对“创造收入的工作能保证不被裁员”的说法加以限定。

Q为什么女性在科技行业中的比例仍然偏低？

她描述的是好几个层面，而不是单一的原因。成为团队里唯一的女性，可能让人感到孤立，尤其是在职业生涯早期；随着工作和家庭责任的累积，女性可能还会面临不同的压力。她强调，这些挑战出现在教育和职场管道的多个环节。

Q如果科技行业的性别比例在接下来的 50 年里保持不变，你会失望吗？

如果像她女儿这样对技术感兴趣的女性离开，而男性留下，她会感到失望。她不确定到那时这种差距是否会被解决，并称这是一个困难的、有多个层次的问题。

Q一位资深工程领导应该保持多大程度的技术能力？

安德森说，领导不必是最强的程序员，但也不能以管理为借口，对系统保持无知。他接手一个大型 AWS 网络组织时，阅读了基础性的书籍，请每位工程师绘制架构图，并向首席工程师学习。几个月之内，他就能参加运营评审并解释事故。采访者反驳说，AWS 的正常运行时间本身就是产品；两人都同意技术上的熟练度很重要，不过争论它在高管层级上，应该与沟通和业务领导力如何权衡。

Q晋升流程和经理教会了人们关于发声的什么？

安德森对比了亚马逊详尽的晋升文档，与 Meta 一次更快、更不正式的讨论，在那里，同事们直接权衡候选人的履历。他认为，推迟优秀候选人的晋升，可能比让某人在晋升之后再成长更糟。经理有时会采取一个可信的对立立场，来检验假设，或帮助初级员工练习说“不”；关键的信号，是当有人提出异议时，经理如何反应。

Q你对亚马逊的文化和员工流动有什么了解？

他不同意把亚马逊当作一个统一的职场：团队各不相同，而当地的经理会强烈地塑造体验。他描述自己见过一个团队，在一年内部调动限制到期之后，几乎所有人都离开了。安德森和其他“把关人”（bar raiser）写了一份提案，要求取消等待期，认为强制留任掩盖了管理问题，还迫使员工辞职。领导层采纳了一项政策，允许人们更早地调动，把责任转向经理。

Q第一条建议：怎样把薪酬请求表述为对双方都有利？

刘把与经理的关系描述为一个联盟：双方都应该理解条件，以及各自的贡献。与其让这场对话仅仅围绕“要更多的钱”，他建议就岗位期望和成果达成一致，最好形成书面文件。这给了经理一个具体的依据来为员工说话，也让这个请求关乎所创造的价值，而不是围绕一块固定的蛋糕的私下较量。主持人强调了薪酬与价值之间的区别，然后刘分享了一个定级的例子：一位有十多年经验的候选人，拿到了微软 L62 的录用通知；他们向招聘经理论证了 L63 的职责范围，并提出加面试。刘说，经过大约一个半月的流程，候选人的级别提高了，影响到基本薪酬、股权和奖金。两位讲述者都强调适配和可持续的期望，而不是不惜一切代价地追求头衔或薪酬的最大化。

Q第二条建议：什么是 BATNA？候选人为什么应该强化它？

BATNA 的意思是谈判协议的最佳替代方案。刘说，候选人应当了解自己的备选项，并考虑公司的备选项，而不是接受“这个录用通知是千载难逢的机会”这种稀缺叙事。他提醒，任何谈判都不应把食物或住所这类基本需求置于风险之中。主持人和嘉宾都同意，候选人有时可以通过走开来行使筹码，同时承认求职是有压力的，而且个人的情况各不相同。刘用一位客户来说明这个想法：他搜寻了大约四个月，在六七年经验之后，拿到了波士顿一家创业公司大约 13 万美元的录用通知。客户拒绝了，两个月后，拿到了特斯拉高于 30 万美元的录用通知；刘说，这位客户后来获得了晋升。这是一个单独的、有报告的案例，并不是典型的结果，也不是拒绝一份录用通知就会得到更好的承诺。

Q第三条建议：在薪酬谈话之前，员工可以做什么来让自己的工作被看见？

刘否定了“好工作会自动说话”的想法，尤其是在大型组织里。第一，向经理要绩效反馈；如果对方很忙，就自己带来对反馈的深思熟虑的看法。把差距对应到能补上所缺技能的工作上，去执行，并通过展示发生了什么变化来闭环。第二，以有用的节奏沟通。刘建议向经理和隔级经理做每周和每月的“我的现状”更新，涵盖成绩、阻碍和优先事项。保留一份持续更新的成绩记录，但在报告时过滤出每位接收者最需要的重要信息。这场访谈更广泛的要点是：有规律的、相关的能见度，而不是为发状态而发状态。

Q尽职调查式的对话应包含什么？候选人什么时候应该要求不同的级别？

利用与招聘经理的对话，弄清这个岗位真正的优先事项、职责范围、资源、紧迫性、成功的衡量标准和管理风格。候选人在评估经理和团队的同时，公司也在评估候选人。要问经理是否会为这项工作说话，以及这个机会是否契合候选人的长处。

如果岗位职责听上去比所给的级别更大，就问这个岗位能否重新定级。嘉宾说，有些候选人成功了，而另一些则可能被要求再走一轮面试。提出头衔的要求，如果是在拿出关于工作内容的证据之后，会更有力，而不是出于对更高级别的抽象偏好。

Q怎样把一个诱人的录用通知，与自己实际将要加入的工作和团队进行比较？

对话提醒不要把更大的薪酬数字当作全部的决定。嘉宾描述了权衡机会、团队、管理层、公司方向和个人风险；如果运营条件或领导层不对，一个看似有吸引力的岗位也可能成为糟糕的选择。候选人应当借助尽职调查，了解可能的日常工作，以及公司兑现其承诺的能力。

Q谈判需要另一份录用通知吗？该怎样提出请求？

不需要竞争性的录用通知；嘉宾说，他的大多数客户都没有。候选人可以通过与相关同行交流、了解市场，以及对任何正在进行的流程保持诚实，来创造有用的选项。要陈述一个具体的期望，并提出明确的要求。一个区间可能把讨论锚定在较低的一端，所以要决定哪个数字代表你的请求，而不要给出一个你并不当真的区间。

不要编造录用通知，也不要在筹码上撒谎。目前尚未归属的股权或奖金，可以被描述为候选人离开时所放弃的一部分，但论证应当保持可信、符合事实。

Q在表示打算离职之后，应该接受挽留的方案吗？

嘉宾不接受绝对的规则。当一位强有力的经理承诺在职责范围、晋升或薪酬上做出有实质意义的改变，并表现出愿意为你说话时，挽留方案可能是合理的。更多的时候，仅凭金钱的承诺，并不能解决这个人当初考虑离开的原因。要说出离开的打算，观察对方的反应，并且只有当根本的条件以可信的方式发生了改变，才留下。

他用一个在谷歌被一再重置的晋升来说明这一点：当另一份录用通知到来时，一位经理不愿意支持他，这比一句口头承诺更能说明问题。

Q当招聘人员说录用通知是最终版本，或者要求尽快答复时，候选人能做什么？

首先要理解招聘人员受到的限制：招聘人员可能是在传达一个真实的薪酬区间或流程上的限制，而不是掌控着所有可能的例外。请他们带着一份清晰、有理有据的论证，去找薪酬委员会，并在事实支持调整时，让招聘经理或资深的赞助人参与进来。要专业地升级，并持续与了解这个岗位的人建立直接的关系。

截止日期可能是真的，但候选人可以要求时间，并拿到书面的延期。关于毁约的讨论是有语境的：勒努（Lernout）描述了一些公司在签署录用通知后撤销，或在达成一致后改变远程办公条款，并说这些经历影响了他自己对相互承诺的看法。他没有为每种情况给出一条普适的道德规则。

Q对于一个在重组后团队发生变化的人，这套系统可以怎样帮助他？

这个例子是：请新经理重新锚定期望，请原来的经理做交接，并开展一次聚焦的 30 天重新介绍，其中包含与隔级领导的关系。这条建议旨在立足于积累下来的辅导资料，而对话仍由真人教练主导。

Q教学是怎样成为学习的方式和公开的声音的？

辅导帮助维拉姆加马理解了数学和物理，她还通过向自己解释概念延续了这个习惯。在大学里，她把数据结构的笔记变成了博客；其中一篇文章吸引了大量 LinkedIn 读者。后来她用日常物品和视觉类比，制作了一些有趣的短讲解，跟着评论区里的问题走，而不是一开始就打算打造个人品牌。

Q你是怎样为早期的实习开辟出一条实用的路径的？

作为国际学生，她起初并不知道学生可以什么时候实习，也不知道美国的主动招聘是怎么运作的。一位招聘人员让她把三页的简历缩短之后，她开始申请，参加了会议和黑客松，并在房利美（Fannie Mae）获得了一份实习。后来她用多种途径进入目标公司：活动、招聘会、给员工发消息和在线申请。她指出，自己的求职发生在另一个市场，并建议建立直接的关系、做高影响力的行动，而不是漫无方向的活动。

Q技术创作者应该在网上分享什么？

她把稳定的职业形象，与成为全职创作者区分开来。一篇有用的每周帖子，可以总结一个技术想法、一个项目，或一项学到的技能，同时保护机密细节。她的话题来自评论区的问题、工作和会议。她会研究到自己能把这个想法讲清楚，制作一个通俗易懂的短版本，然后为感兴趣的观众提供带有技术细节的、更深入的书面内容。

Q是什么在引导你走过亚马逊、创业公司和投资这些阶段的职业生涯？

职业生涯从远处看，比身处其中时显得更有计划性。乔普拉一再追随有野心的人和新技术，走向这个领域的前沿：滑铁卢、亚马逊和微软，然后是社交平台和移动。一位亚马逊的资深领导，把他们反复聊起的创业话题，变成了向投资人的引荐，并推动他离开去创业。乔普拉说，初级工程师可以通过带着深思熟虑的观点发言，贡献新鲜的技术视角，同时担起让自己有用、而不只是嗓门大的责任。

Q编码智能体会消灭优先级排序和管理吗？

主持人问，指挥智能体的工程师是不是正在变成经理，以及经理将来是监督更多的智能体，还是更多的人。乔普拉说，经理历来负责分配稀缺的工程时间；如果智能体让更多的工作变得可行，组织可能会转向这样的系统：运行实验、测试功能、把它们暴露给用户，并决定什么能进入生产环境。主持人指出，不断扩大的前沿仍然会产生选择。乔普拉同意，雄心可以移到更高的层次，但评估成果和取舍的系统仍然是必要的。

Q奥罗斯为什么从资深的个人贡献者转到工程管理？

在跨越几个岗位和技术栈的大约十年之后，奥罗斯觉得自己作为工程师的学习已经开始放缓，尽管他参与过非常大型的系统。当时他的团队出现了一个管理岗位的空缺，而优步（Uber）提供了六到十二个月的学徒期，并真正保留了回到个人贡献者岗位的选项。

他把管理看作学习一门新学科、拓宽自己选择的机会，也是避免日后为错过一扇门而后悔。他还想把自己从体验过的经理身上得到的教训付诸实践：有一位很支持他但不够投入，另一位则是微观管理。他想试试成为自己希望拥有的那种经理。

Q工程经理需要有多懂技术？

奥罗斯并不把先前的编码经验当作绝对的要求。好奇心、人际技能和激励团队的能力，可以让一位非技术背景的经理有成效，但他认为，如果缺乏足够的技术理解，这份工作要难得多。

当他的团队转向分布式系统时，他阅读架构文档和 RFC，把不熟悉的概念写下来，并学习一致性和持久性，以便能参与决策。他把这与那些只会点头、把每一个技术问题都推给技术负责人的经理作了对比。一位理解实质内容的经理，可以在会议上做出贡献，而不必让每个决定都等着“翻译”。

Q职业早期的工程师怎样赢得经理的关注？

奥罗斯把可靠的执行放在第一位：了解团队的目标，快速上手，向经理和同事征求反馈，并把分配到的工作做好。然后观察在那家具体的公司里，最强的工程师实际上在做什么。比如，创业公司可能奖励交付有用的功能，而较大的组织可能更依赖设计评审和书面提案。

他告诫不要把个人发展与业务影响混为一谈。他曾经为了提升公开演讲能力而做会议演讲，并期望这份努力有助于自己的晋升，但他的经理无法把它算作团队的影响。更资深的工程师把演讲与一项业务需求联系起来，比如招募平台工程师。副业项目和公开的能见度可以帮助个人，却不一定推进雇主的目标，所以最好尽可能让两者对齐。

Q有什么被忽视的因素，能帮助工程团队把事情做成？

奥罗斯强调能量：有干劲的人往往无论有没有某个特定的流程或工具，都能取得进展，而一个能量低的团队，即使采用了正确的框架，也可能陷入停滞。他说，他听说强烈的共同兴奋感，帮助 OpenAI 的团队快速交付，并建议工程师既要考虑自己的能量，也要考虑他们加入的公司的能量。

他把引人入胜的工作比作 Factorio 这样的游戏：当团队想要解决这个系统、一起获胜时，重复性的任务也会变得令人沉迷。AI 智能体也许能自动化一些例行工作，但它们无法创造让团队在乎结果的动力。

Q面对一个过度拥挤的市场，候选人该如何应对？

迈把招聘看作雇主与候选人之间的匹配，而不是对每一位工程师的全球排名。他建议瞄准那些候选人能展现相关价值的组织和问题领域，然后通过同事、内推和专业社群建立真诚的关系。为进入一个雇主，要开辟好几条有目的的路径，而不是只等一份申请或一次内推。

他建议先了解哪些公司使用相关的产品或基础设施，然后做一个与真实业务问题相关的、小而有用的项目并分享出来。重点是在一个细分领域里展示有用的专长，而不是把大量投递误当作有成效的求职。

Q你自己的职业生涯让你对使命感和倦怠有什么认识？

迈讲述了自己在 Facebook 做有害内容的工作，既有意义又令人疲惫，以及后来努力去寻找使命更契合的工作。他把倦怠描述为不只是工时问题：当工作与身份融为一体，或者当一个人觉得被困在不再值得做的工作里时，它就可能出现。他回忆起连续熬夜之后错过了一个亚马逊的交付日期，这成为他与工作的关系发生转变的一刻。他的建议是留意错位，避免把一份工作变成你的全部身份，并规划一个现实的下一步。

Q什么样的面试流程足够公平，值得信任？

迈说，目前的形式让人痛苦，也可能错过优秀的候选人，但他不认为这个流程已经全盘崩坏。编码和设计练习，是为了抽样考察有用的技能而设计的；AI 工具现在挑战了它们的假设，而且许多面试官没有受过前后一致地评估的训练。组织可以从研究“误拒”（false negatives）中学习，包括那些被拒绝后来却成功的候选人，但这需要时间和重新审视决定的意愿。

Q技术工作是怎样变成更广泛的产品影响力的？

Chen 回顾了自己在微软和 Facebook 的经历，当他超越被分配的实现工作去做事时，他的贡献就增长了。他打造了有用的工具，向客户和开发者学习，并在玩家和开发者的行为推翻了团队最初的假设之后，改变了早期 Messenger 游戏平台。后来的晋升，来自把影响力扩展到多个产品和组织，而不是单纯多写代码。

Q是什么帮助你建立了信心并赢得晋升？

Zhang 谈到了冒名顶替的感觉，以及看到别人显而易见的成功、却清楚自己的挫折之间的失衡。一个支持她的人脉很重要，一位为她说话的经理也很重要。她还从同事的晋升材料中学习，用它们找出具体的差距，而不是猜测晋升需要什么。

Q你是如何在六年里，从实习生升到 Meta 的主任级 E7 的？

诺瓦蒂把自己的速度归因于对 Facebook 投入了异乎寻常的关注，因为他相信它的愿景，并想提升它的影响力。他说，薪酬和晋升清单并不是他的主要动力；看到工作产生的效果所带来的势头，让他想做出更多贡献。他还强调，不同级别之间的转变各不相同，所以不应把他的路径简化为一个普适的晋升配方。

Q跳过会议、独立工作，是不是一种职业成长的通用策略？

诺瓦蒂说，他不会把“退出”当作一种一刀切的策略来推荐。他的决定取决于公司所宣称的价值观，以及他是否把这段时间用在价值更大的工作上。有时他会提前向产品经理说明情况，让对方在会上代为转达他的更新或顾虑。据他讲述，他是想避免一场会议的时间成本，而不是放弃这项决定或相关的人。

Q一位高产出的个人贡献者怎样才能创造跨团队的影响力？以编码为中心的路径在哪里达到极限？

主持人问，一个独自写了大部分代码的人，怎样仍然能产生广泛的组织影响。诺瓦蒂同意，一个人是有极限的：编码量可以让一个人非常有价值，但要对一个更大的群体产生影响，需要的不只是个人产出。他描述了自己收到的反馈：他需要扩大自己的影响力，才能达到下一个级别。作为回应，他组织了一次代码健康峰会，把来自不同迁移和基础设施项目的工程师聚在一起。这项工作为他赢得了更好的评估，以及通向 E8 的路径，但他意识到，更广泛的领导工作并不是他最想做的。他更喜欢写代码、快速交付，并看着别人使用成果。

这场访谈让取舍的两面都清晰可见：“编码机器”的身份可以带来深厚的手艺和快速的交付，而更高的级别则可能需要帮助他人做出更好的工作。

Q为什么有些备受重视的工程师，几乎没有 LinkedIn 上的存在感？

诺瓦蒂描述了一个招聘市场：受信任的招聘人员与资深工程师保持长期关系，所以这些工程师不一定需要一份公开的资料，也能听到机会。他说，有些人可能只保留最简的资料，并提醒这并不是每个人都该删掉 LinkedIn 的理由。他的观察针对的是一小群高薪、资深的工程师，而不是职业早期候选人的规则。

Q我应该怎样准备行为面试的故事？

准备六到八个故事，展现你所瞄准的级别。从真实的经历里挖掘，给每个故事一个清晰的形状，不要把准备想得过头，变成一个编造的叙述。

Q为什么选择 Staff 以上的个人贡献者路径，而不是管理？

科技行业提供了在别处不常见的资深个人贡献者岗位。管理是另一份工作，涉及招聘、薪酬、冲突，以及向上向下的沟通。讲述者建议，如果 Staff 或首席工程这类工作吸引你，就先走这条路来保留选择：从 IC 转到管理是可行的，而在管理岗位上待了多年之后，再回到高级别的 IC 路径可能更难。

Q我怎样才能让领导层支持一个想法？

了解经理和资深领导真正的业务问题，然后把提案与其中一个联系起来。一个解决当前压力（比如人员流失）的低成本想法，比一个收益含糊、或结果无非是“原样不变、只是步骤更多”的架构重写，更容易得到支持。

Q应该怎样思考资深职责范围和职业选择？

讨论回到了建立更广的主人翁责任的证据，而不是等待一个头衔。埃文斯鼓励工程师区分那些会教会或拓展自己的机会，与只会增加工时的工作。创业公司和大公司的环境，各自提供不同的风险和学习条件；合适的环境取决于这个人想优化什么。

Q怎样向导师学习，又不把自己的选择外包出去？

埃文斯把指导看作有边界的帮助，而不是承诺去解决另一个人的职业生涯。学习者应当带着一个具体的问题，把建议当作输入，并仍然为按它行动负责。大学和职业的选择同样需要评估实际可得的学习和机会，而不是遵循某个单一的公式。

Q如果我扛不住压力怎么办？

埃文斯把压力描述为高期望、有意义的赌注和后果的结合。要重新找回视角，就回想你已经成功应对过的情形，并把害怕的结果具体化：现实中最坏的情况是什么，接下来你会怎么做？这并不会抹去赌注，但它可以用一个可控的计划，取代一种弥漫的危险感。

请求下一级别职责范围的具体例子

一个人可以对当前级别感到满意，同时仍然探索更多的职责范围或不同的角色能提供什么。如果经理给出闪烁其词的回答，埃文斯建议请对方给出下一级别要求什么的具体例子。

Q学习和入职，会随着资历的不同怎样变化？

初级工程师往往需要明确的背景和共同的概念学习，而更有经验的新员工，可能被期望自己吸收一个系统，并找出自己可以在哪里做出贡献。在两种情况下，当新工程师在试图做出大的改动之前，先了解周围的架构和关系，入职效果最好。

Q如果晋升是竞争性的，帮助同事是不是一种糟糕的职业策略？

这个回答拒绝了“所有职业进展都是零和竞争”的假设。帮助同事可以建立信任，让你的判断被看见，并增强团队的交付能力；这些效果的影响，可能比一个晋升周期的时间跨度更长。

这并不意味着接受被剥削，也不意味着指望一个功能失调的组织来奖励好公民的行为。如果环境确实有毒，就把精力花在寻找一个更健康的环境上，而不是通过扣着不帮忙或拆同事的台来谋求晋升。

Q一位有经验的工程师应该怎样准备行为面试的故事？

选择与所追求级别相匹配的真实例子。一个资深级别的故事，应该展现出不止完成被分配的任务：让模糊性、职责范围、决策和结果清晰可辨，同时不脱离实际发生的事情。重点是传达判断力和主人翁责任，而不是夸大一项贡献，或者编造一个光鲜的人设。

Q什么让一份晋升的论证有说服力？

用能展现下一级别工作的具体成果，取代泛泛的称赞。以可靠著称是有帮助的，但晋升材料应当让评审者很容易看到具体的贡献、它们的范围和效果。在工作发生时就保留记录，而不是在评审时请经理凭记忆去重构。

Q亚马逊是否已经进入“第二天”（Day Two），它的工程文化发生了什么变化？

布朗同意，亚马逊已经变成了一家不同的、更慢的公司，不过他并不把这自动当作坏事。决策和交付可能耗时长得多，而且他看到管理层与资深个人贡献者之间的鸿沟，比他记忆中的更宽。

他说，这种变化在 AWS 之外更明显，而在 AWS，工程本身仍然是产品，工程师保有更多的影响力。他把早期的文化描述为：让首席工程师能异乎寻常地接触资深领导，并在产品和技术决策中拥有更强的发言权。

Q布朗离开亚马逊的时机对吗？这种变化有什么具体的例子？

他说，答案取决于一个人想从公司得到什么，但是较慢的决策流程会让他更频繁地感到沮丧。举个例子，一家海外的制造合作伙伴破产了，这带来一个有时间压力的选择：关于设备，以及是否雇用这家合作伙伴的前员工以保住专业能力。

布朗主张迅速行动，把这些人留住，同时公司去评估其余的问题。相反，这份提案在法务、产品和多层管理之间流转了好几个月。等到决定下来时，招聘的机会已经过去了。他把这与他所熟悉的、较早期的亚马逊作了对比，他相信那时的亚马逊会先行动，之后再收拾一个可以控制的问题。

Q布朗为什么在个人贡献者与管理岗位之间来回切换？

他把这种模式描述为锯齿形。作为个人贡献者，当他无法推动一项更广泛的工作时，挫败感会不断累积；他就会成为经理，去组织工作、让人们对齐，并为一个方向担起责任。后来，他会怀念直接的技术工作，并在组织层面的问题得到解决后，回到 IC 的角色。

在最好的状态下，首席工程师这个角色让他得以结合两种模式：确定方向并身先士卒，然后深入技术细节，同时不把亲自动手的工作当作一种干扰。

识别让工作值得做的团队条件

布朗把亚马逊的 Scout 项目称为一段特别愉快的时期：一个小团队，一个尚未解决的问题，以及从零开始构建的空间。他在回顾时，更清楚地认识到它的特别之处。一位前副总裁曾经打断他的工作汇报，问他是不是玩得开心，促使他去反思这段经历，而不只是任务清单。

评估一个岗位背后的人与团队动态

随着人们在职业上有更多选择，布朗说，团队里的人成为一个核心因素。有趣的问题往往唾手可得，但一个合拍的团队，能提供可以学习的同事，并让日常工作可持续。如果可能，在接受一个岗位之前，先观察这个团队一起工作的样子。

Q早期的谷歌在成长过程中发生了怎样的变化？你是怎样把你的 20% 时间变成有意义的工作的？

比斯格利亚在 2003 年加入谷歌，当时它大约有 800 名员工，并亲眼看着它增长到大约 8,000 人。他自己的工作，从积极的工程开发，转向了会议、合作伙伴关系和解释云计算。他对“20% 时间”做了宽泛的解读，在华盛顿大学讲授一门关于 Hadoop 和大规模计算的课程，使用一个根据谷歌已发表的想法构建的开源系统。

这门课程传播到了其他大学，成为教给学生企业所需技能的一种方式。在这项工作既显示出教育价值、又显示出超越大型网络公司的应用之后，谷歌给了这个项目一座数据中心的使用权，比斯格利亚的工作也发展成了与外部合作伙伴一起的全职投入。这个故事说明，当公司的资源遇到一个具体的外部需求时，一项倡议是怎样成长起来的。

Q你对创始人、融资和打造产品有什么体会？

随着 Cloudera 的成长，比斯格利亚发现，强大的创始人之间也可能发生冲突，而一家快速扩张的公司，在某些职能上，可能雇到比早期领导者更有能力的人。他说，他的长处是愿景、社区，以及让人们相信一个机会；随着公司对高管的需求超出了他自身的成长，他想要更多的指导。

他坦率地说，CEO 这个角色，不像设定愿景和建立关系那样适合他。一位创始人可以擅长招募人才、让一个想法令人信服，同时仍然更喜欢另一种运营角色。

把失败转化为共同的改进

在 2011 年的一次宕机之后，阿圭列斯说，有用的回应不是追责。团队构建了一个可复用的测试平台，它传播到了最初的服务之外。这次失败，成了改进其他团队工作方式的机会。

Q高标准和职业成长怎样相互促进？

他描述了一个飞轮：可靠地交付，赢得信任，承担一个更大的问题，然后凭判断力行动，而不是等待许可。一个有挑战的目标，不一定要求完全的确定性；他谈到做出有雄心的押注，同时让失败带来信息。他自己非线性的发展，包括在一个级别上停留了很长一段时间，驳斥了“一份出色的职业生涯必须以固定速度上升”的想法。

通过说服他人来建立采用

工程师必须说服别人，并建立组织内的采用。阿圭列斯强调，技术想法不会仅凭代码传播。

Q当一位同事为了出人头地而隐瞒信息或撒谎时，你应该如何回应？

不要照搬这种行为。欺骗也许能赢下一场孤立的较量，但它会损害人们在分配工作、考虑晋升时所依赖的声誉。讲述者实用的做法是：停一下，避免被激怒，让这种模式随着时间显现出来，而不是上钩。

Q技术能力会不会有一天不再是职业的瓶颈？

当前的瓶颈，才是该去解决的那个；预想好几个未来的瓶颈，可能让人分心。技术能力或对本地情况的了解，在早期可能占主导，但到了资深工程师前后，限制因素往往是行为：书面和口头的沟通、声誉、追查根本原因、指导他人，以及培养他人。技术能力仍然可能是约束，但并不是唯一的约束。

Q从工程师的角度看，什么样的产品经理或项目经理才算优秀？

产品经理应当澄清客户的问题及其目的，同时对技术方案保持灵活。一条有用的需求，会说明系统应当让客户能做什么、以及为什么；规定实现方式却不解释问题，会让工程师无法提出替代方案。项目经理应当用排期来估算上线时间，而不是把一个激进的日期当作唯一的提效工具。如果项目延期，可用的杠杆是范围、人员或其他资源，以及日期。经理应当说明哪个杠杆在动；如果哪个都动不了，那么这个计划就是不可信的。

Q当新经理微观管理并推翻团队的决定时，员工应该怎么办？

讲述者说，即使经过仔细的面试，一位经理也可能是有毒的，并指出自己在亚马逊 13 年间换过 20 多位经理，最后五年才一直跟着同一位经理。如果这种行为很严重，他建议去跟隔级经理谈，了解这是否可以接受、会有什么改变，同时在需要时寻找另一个团队。他警告说，有毒的环境可能变得常态化，员工不应该以为经理会改变。

Q一个要求高到无法持续的岗位，应该离开吗？

休一次假，也许能短暂地缓解压力，却没有改变工作量。讲述者建议直截了当地告诉经理，目前的负荷是不可持续的，看看最耗人的部分能不能改变。如果什么都没变，离开可能是更好的选择。如果这个人原本很看重这个职场，就应该先看看这份工作能不能变得可持续，避免用一个问题换另一个问题。

Q裁员的幸存者，怎样处理内疚，以及对下一轮的不确定？

讲述者承认失去同事的悲痛，并把可控的表现，与公司的经济状况区分开来。他建议保持强劲的表现，并寻找由合并或重建阶段所创造出来的领导机会。这是他对这种情形的解读，并不是承诺重组一定会创造机会。

Q怎样才能避免重蹈那些导致被解雇的行为？

先回顾每次被解雇之前的关键互动：发生了什么，本可以怎样说或做得不同，以及别人是怎样处理类似情形的。然后学会在它发生的时候就注意到触发点，并打断那种熟悉的反应。当根本原因难以独自看清时，讲述者还建议去做心理咨询。在重新申请工作之前，要能够描述为解决这种模式而采取的具体步骤。

Q当企业式的乐观显得做作时，怎样才能坦率？

这个回答区分了“直说”与“有用的说”：直白的悲观在技术上可能是准确的，却依然帮不到团队。要以有分寸的方式，指出具体的障碍，并邀请大家讨论解决办法。在这个例子里，同样关于规格、代码和截止日期的顾虑被提了出来，却没有变成个人的发泄。

Q一位资深工程师怎样培养队友，而不失去耐心、也不伤害他们？

讲述者首先质疑了提问者对同事轻蔑的措辞，说沟通本身可能就是拖住这个人的原因。然后他把教学视为一种投资：花三天时间教一项一小时的任务，在类似的工作重复出现时可以回本，尤其是当这位同事还能去教别人时。如果帮助没有产生效果，就检查教学方法。教的应该是解决一类问题的通用方法，而不是一项狭窄的任务。最后，质疑我们给自己讲的英雄与恶棍的故事：同事评判的是行动，而我们倾向于用意图来评判自己。良好的意图，并不会让有害的行为变得无害。

Q候选人该怎样解释因为一位糟糕的经理而离职？

他建议用一种外交式的解释，把注意力放在候选人接下来想要什么上：在某个特定领域的成长空间，一个职责范围更广的岗位，或者之前团队的机会与候选人目标之间的不匹配。批评前任经理，会让面试官怀疑候选人日后会怎样谈论新雇主。文字稿中的法律题外话，在这里不被当作法律指导。

Q怎样为一个软件平台找到合作者，又不被人抄走想法？

主持人更看重执行，而不是守住一个想法。他建议把项目讲清楚，邀请人们为共同的目标出力，并给合作者足够的背景，让他们理解整个工作。如果项目推进了，那位召集大家并带领交付的人，可以为自己的工作和所展现的领导力赢得认可。把想法拆碎或藏着掖着，会让别人更难加入，也让项目更难交付。

Q工程师怎样才能在解释想法时更清晰、更简洁？

主持人把功劳归于练习和准备，而不是天赋。就一个想法写点东西、并反复解释它，可以暴露理解上的漏洞，并让之后的解释更有效率。他建议对着橡皮鸭、同事或镜头练习。录下自己，一开始可能不舒服，但反复练习，可以让在面试或会议中说话变得更熟悉。

Q如果我的经理在晋升上很吝啬，而我其他方面都喜欢这个团队，我能做什么？

讲述者从自己的经历开始：一位经理尽管被多次提醒，仍然错过了必需的晋升提交。经理的支持和能力是核心，因为他们为材料提供赞助，并为员工说话。要观察行动，而不要只依赖令人安心的话。

在离开之前，和隔级经理谈谈这种模式，问问它反映的是公司政策，还是某位地方经理的问题。调到兄弟团队，也许能保住组织里行之有效的那些部分。如果内部没有出现选项，而缺乏支持的情况持续，离开可能是必要的。

Q我应该对一位正在破坏团队文化的、要求苛刻的新经理当面对质吗？

讲述者指出，经理也可能是低绩效者，仅凭头衔并不能证明能力。他建议把正在发生的事、以及是否有其他人受到影响，告诉隔级经理。改变可能需要几个月；如果隔级老板对正在伤害团队的行为看不出问题，这就是关于组织容忍什么的证据。在那种情况下，要准备去找一个更健康的团队或公司，而不是假定经理会很快改变。

Q职业早期的工程师觉得被资深队友碾压，应该怎么办？

当同事有多年经验时，感觉自己是大池塘里的一条小鱼，是很常见的。如果工作在其他方面是健康的，讲述者鼓励留在一个让工程师接触到更强同行的环境里：观察有经验的人如何做事，可以加速成长。在较小职责范围里的舒适感，并不是衡量适配度的唯一标准；持续的挑战可以是有成效的，即使一开始会让人觉得别扭。

Q面试是估算我市场价值的最好办法吗？

面试提供了一个直接的数据点，但它需要大量的准备，也可能得不到录用通知。一开始，可以对比薪资网站和可信同行提供的薪酬信息。如果这些调研显示有明显的差距，就在承担完整的求职成本之前，先和现任经理谈谈。如果雇主不愿解决这个差距，或者更大的变动是值得的，那么准备面试才更有意义。

Q工程师是否应该每两年换一次公司来最大化薪水？

讲述者没有给出一条普适的“跳槽”规则。他说，他优化的是职业成长和稳定，而不只是薪水，同时承认薪酬和成长是相关的。一份更高的录用通知，只有在整体情况更好时才有用。在调动之前，要调查经理、团队、代码库、运维负担和职场质量；他曾经通过内部的匿名调查，发现一个目标团队看起来比他现在的团队更糟。

Q为了得到更有挑战的工作，我应该接受更低的薪水吗？

讲述者质疑“更好的学习必须以降薪为代价”这个假设。经验是有价值的，包括对自学成才的工程师而言，一个人可以寻找既能提升技能、薪水又更高的岗位。要找一个更大的池塘，抛开稀缺心态，而不是自动用薪酬去换成长。

Q如果我在不止一家公司都被拒绝晋升，怎么办？

反复被拒绝可能令人气馁，而且即使对优秀的工程师，资深级别的晋升也很难。讲述者警告说，当需要改变的是个人层面时，不要反复换团队：他描述了一位有能力的工程师，他那种居高临下的态度从一个团队跟到另一个团队，每一次都挡住了晋升。

把被拒绝的反馈当作一张地图。在从失望中恢复过来之后，把具体的差距转化为一个计划，并在之后的尝试中寻求更详细的反馈。当环境是障碍时，换公司可以有帮助，但跨组织反复出现的反馈，可能指向需要关注的某项技能或行为。

已省略这个回答与下一个答疑问题之间的赞助商片段。

Q你现在怎样理解在亚马逊的那艰难的两个月？

他不想把这段经历变成一个关于责怪的故事。他描述了一个压力很大的团队，资源不足，工作文化很差，同时试图不把这段经历当作自己没有能力的证明。回头看，他说，仅靠学业上的努力，并没有让他为职场里对领导力的期望和人际技能做好准备；他不得不去适应职场的真实文化。

主持人把某一个团队的失败，与整个行业区分开来，并认为“不是游就是沉”的环境可能会伤害职业早期的工程师，尽管要求苛刻的高绩效组织也可能有其长处。嘉宾同意，新工程师可能把一个糟糕的团队，误认为是每个职场的样子。

Q亚马逊的团队经历具体是什么，让它如此艰难？

他在新冠疫情期间远程加入了 Alexa 组织。工作让人觉得吃力不讨好，团队缺乏协作，工程师们在凌晨两三点提交代码。他逐渐认识到，这种功能失调是团队层面的问题，一位初级工程师无法修复。最终离开的结果还不错，不过他有时会想，自己是否本可以坚持得更久。

Q会不会有更多软件开发者能从心理咨询中受益？是什么帮助了你？

他把改变自己处理人际和工作方式的功劳，归于认知行为疗法。他把社交技能描述为可以练习的东西：微笑和问候这类小动作，能建立熟悉感。他主张学习情绪上的掌控，而不是压抑感受，并认为软件开发者除了技术学习，也可以从花时间和金钱做心理咨询中受益。他推测了自己的神经类型，但说得并不确定；本章不把它当作诊断。

Q投了几百份申请却一个面试都没有，应该怎么办？

在经历了一段令人气馁的、没怎么进展的申请期之后，他建议把眼光放到同一个申请渠道之外：去结识可能在招聘的人，参加活动，展示有用的工作，并问别人有什么问题需要解决。这个建议是有语境的，并不是保证人脉就能拿到工作。

Q你能讲讲，你曾经把团队的流程、软件或系统变得更简单的一次经历吗？

第一次尝试说的是：团队继承了一套有 bug 的软件，带来了运维负担，并有一个有风险的依赖。随着上线临近，候选人决定弃用这个服务，把客户端迁移到现有的软件上，并说结果是夜间的告警呼叫减少了，架构也更简单。这个例子有一些有用的事实，但面试官还无法判断候选人的角色、职责范围，或者这个决定有多难。作者随后再次问了同一个问题，来示范一个更有力的开头。

Q你是怎样找到这个服务的用户，并安全地将它下线的？

候选人启用了透传模式，让客户端表明自己的身份，分析日志，发现有 27 个团队在使用这个服务。其中大多数可以迁移到候选人所在团队已经拥有的端点。团队把客户端分了工，为那个依赖拿到了临时豁免，宣布了三个月后的关停日期，并支持迁移。有一位客户端缺少合适的 API，并向上升级了问题；上线之后，候选人的团队构建了所需的功能。上线没有被打乱，架构也得到改善，不过与那位客户的关系依然紧张。这个追问，让候选人的分析、协调和取舍管理都变得可见，同时让结局保持真实，而不是完美地解决。

Q约翰一开始选择什么故事来展示他的领导力？

被问到他最强的行为面试例子时，约翰从他在微软 19 年的概括性叙述开始：把服务从本地系统迁移到 Azure，构建数据分发服务，然后管理网络方向的工程师。他把“扭转局面期间的增量交付”确定为核心故事，但他最初的描述很快扩展到了 Secure Future Initiative 的要求、AI 的竞争、人员编制的历史和重组。

当史蒂夫问约翰，是继承了这支团队和软件，还是帮助创建了这支团队时，约翰解释说，这个八人小组一部分是新的，一部分来自他在成为他们的经理之前就施加过影响的人。他还描述了这项服务是在组织调整之后才到他手里的。这份叙述是准确的背景，但它最初把微软的组织结构放在了约翰的领导决策之前。

Q之前的自动化尝试为什么失败？约翰改变了什么？

约翰起初把早先自动化的失败归因于糟糕的源数据，然后描述了错误的网络数据导致配置错误的事件，比如把一个已被使用的 IP 地址分配给另一个系统。当他推测之前的工作可能缺乏测试或资深人员的监督时，史蒂夫质疑了这个推测：回答需要一个合理的、基于证据的叙述，而且要得体，而不是对其他工程师的猜测。

经过这番诊断，约翰演练了一个更以领导力为中心的回答。他说，接手团队之后，他起初只是让事情先运转一阵，没有轻易动摇局面，然后选择顶着阻塞 Azure 团队的压力，保护出研究的时间。团队回顾了早先的失败，找出三个可能的根本原因，在评审中核对，并在自动化的过程中运用这些经验，让新的工作不再重蹈覆辙。文字稿没有列出全部三个原因，所以这份凝练稿也没有补上它们。

Q在早期的面试受挫之后，约翰是怎样准备的？

约翰说，他离开微软之后，大约完成了 12 到 15 场面试。他还没有为第一轮亚马逊的面试做好准备，系统设计的问题暴露了差距，并带入了之后的回答。几轮之后，他准备得更充分了；一道很难的编码题，促使他向一位在 Netflix、业余做辅导的同行求助，练习实现，并拓展到 AI 工程工作。在这场辅导的时候，他正在一家早期创业公司工作，同时仍然希望得到一个 Netflix 的机会。

史蒂夫实用的建议是，面试本身就提供了有用的练习，并且比在准备阶段凭空猜测，更具体地暴露差距。他指出，候选人无法控制哪个机会先到来，之后也许可以与一家公司重启流程；他并没有声称，经过某个特定的轮数，就一定能拿到录用通知。

Q候选人怎样才能让面试官记住这场对话？

史蒂夫说，当候选人在自己专长的领域里教给面试官一些东西时，一场面试就可能变得出色。作为候选人提问环节的实用开场，他建议阅读一篇相关的 Netflix 工程博文或视频，并向最懂技术的面试官，就材料里没有讲清的某个方面，提出一个深思熟虑、具体的问题。约翰说他明白了这个任务。这是建议，并不是说约翰在后来的面试中做了这一步。

Q讲讲你的团队的目标，与它所依赖的团队不一致的一次经历。

约翰最初的回答，描述了一个掌管上游防火墙审批的安全审批团队。他的团队想通过把审批和供应打通，把网络供应时间从两周缩短到一天以内，但另一个小组说，这项工作不是优先事项，一年之内都做不了。约翰说，他提议自己的团队接下一部分工作，并构建一个自己能够拥有的 API。另一个团队就已知安全的端口范围，推进了自动审批，而约翰的团队得到了一个端到端的 API，可以验证并用来实施防火墙规则。

史蒂夫喜欢约翰没有直接跳到升级上报，但他说，这个叙述听起来太顺了。他请约翰把真实的摩擦写进去：另一个团队已经规划并承诺了工作，而这个请求是在规划之后才到的。约翰确认确实存在这样的摩擦，并同意故事应当承认相互竞争的承诺，以及他自己的团队所承担的工作量。史蒂夫进一步建议，描述拥有这个 API 如何减轻了另一个小组的负担，并且在架构上说得通。

Q讲讲你架构过的一个项目，以及你做出的取舍。

Kennan 从一份入职问卷讲起，它是为进入一款财务辅导产品的客户准备的。一个被提议的白标（white-label）版本，其范围对现有的后端资源来说太大，所以他的任务是重新设计 API，并重构前端。现有的 17 页表单只用一个 URL，这使得生产环境的 bug 很难复现，而它的错误处理，让客户在得知答案没有保存之前，就完成了一次辅导环节。

他说，他画出了现有调用的图，提议把一些逻辑从前端挪到后端，以便更可靠地处理错误，并把表单拆成带有状态和可复用函数的分页路径。取舍包括：前端的控制力减弱，API 请求可能变慢，换来的是更容易的错误处理，以及一套更易测试、更可扩展的流程。这个为期两个月的项目，产出了一份更可靠、经过测试的问卷，但他的开场是按时间顺序的，在面试官看到他的主要行动之前，先给了一堆背景。

QKennan 怎样才能表明，这个项目体现了资深级别的职责范围和贡献？

史蒂夫提议从四个维度来评估一个故事：职责范围、影响、个人贡献和难度。Kennan 认为这份问卷是一个资深级别的项目，因为它对产品很重要，并且需要对之前的工作有高层次的把握。当被问到队友是否也能讲同样的故事时，他澄清说，架构、后端的协调、与产品经理的协作和故事拆解，是他负责的，而团队负责了实现。

史蒂夫说，这个职责范围听起来是资深级别的，而对他设计并实现的架构作一个清晰的概述，比详尽地交代每位贡献者的百分比更有用。他用海岸线作类比，说明极端的细粒度，可能掩盖真实的贡献，就像用更小的尺度去测量海岸线，会使它显得更长。目标既不是把整个团队的工作都揽到自己头上，也不是稀释真正的个人贡献；Kennan 说这个区别很有帮助。

Q当没有精确的指标时，Kennan 能主张什么影响？

Kennan 起初描述了一份更可靠的问卷和更快的后续改动，但说他没有具体的指标，也不想编造一个。史蒂夫把影响定义为一种可衡量的变化，有定量指标时更倾向于定量，没有时也接受定性的证据。他指出，说新流程是可扩展的，或者这个项目避免了一次大得多的重新设计，本身并不能说明一个业务成果。

当史蒂夫问到产品的利害关系时，Kennan 解释说，客户可以通过这项服务投资大约 5 万到 20 万英镑，而辅导师利用问卷的细节来指导潜在的投资者。史蒂夫建议明确指出，一次糟糕的入职通话，可能让公司失去一位客户；Kennan 同意，这更好地解释了一份可靠的问卷为什么重要。这是对业务背景的一种辅导式解读，而不是一个所报告的、经过衡量的收入结果。

Q两种 API 设计之间的取舍是什么？

Kennan 起初把从前端逻辑和多次请求，转向以后端为中心的端点，称为这个取舍，但他的描述混合了响应时间、控制力、回滚处理和错误的复杂性。史蒂夫放慢了解释的节奏，请他说出每个选项的利与弊。他们澄清了：单一端点让前端只需发出一次请求，但会把更多编排和错误处理放进 API；多个端点让前端能控制各个单独的保存，并且可能返回更快，但需要更多前端的协调。

在进一步追问下，Kennan 指出了更尖锐的现实约束：更干净的、由后端支持的设计需要一位后端工程师，而他的团队没有这项资源，因为另一个团队有相互竞争的优先事项。史蒂夫说，一位有经验的面试官不需要冗长的实现层面的解释，就能理解这种资源冲突。在一个示范的标题里，他把有 bug 的问卷和客户的利害，与对后端支持的需求联系起来；这个样例是史蒂夫的措辞，并不是 Kennan 逐字重复的完整回答。

QKennan 是怎样影响资源分配的决定的？

当史蒂夫问发生了什么时，Kennan 先说团队推动了一个更稳定的架构，并且一位后端工程师被暂时从另一个项目调了过来；他意识到自己用了“我们”。史蒂夫从这个集体的结果里，诊断出领导力的信号：Kennan 是一位需要影响自己经理的个人贡献者，并要提供数据，来论证从另一位经理的团队里调走一项资源的合理性。

史蒂夫示范了因果链：Kennan 提出基于证据的论证，他的经理把它带到整个组织，后端工程师被重新分配；并称 Kennan 是“第一块多米诺骨牌”。Kennan 说，这种界定自己贡献的方式很有帮助，但这场辅导里并没有他给出的完整修订回答。示范的措辞仍是教练的，而不是 Kennan 实际的最终回答。

Q描述一下你在工作中做过的最具创新性的事情。

Kennan 选择了引入端到端测试。他描述了比较 Playwright 和 Cypress，构建概念验证，招募感兴趣的工程师，向技术负责人展示建议，绕开后端和 DevOps 的环境限制，并为登录和辅导师注册流程加上测试。他的第一个结果是，这些流程现在可以端到端测试，问题可以在上线之前被发现，但他开头并没有给出业务影响的具体衡量。

史蒂夫问，可靠性或业务结果有什么变化。Kennan 说，测试能更早发现问题，并让改动更可靠，但承认这种影响很难衡量，也没有阻止任何大规模的故障。他们确认，这个小团队没有专职的测试人员，产品经理自己在做一部分流程测试。Kennan 确认这为产品节省了一些测试时间，并说产品经理支持这个想法。史蒂夫建议使用这种定性的节省时间，以及团队的约束条件，而不要编造一次戏剧性的事故或指标。

Kennan 还描述了 DevOps 起初拒绝提供新的测试环境。他的解决办法，是使用当前的开发环境，同时不污染它：用带有后缀、可以被清除的一次性假邮箱创建账号。史蒂夫把这个障碍与主动性联系起来：采用一个现成的测试工具，仍然需要协调和一个实用的变通办法。

Q一位安全工程师应该怎样介绍自己的技术职业生涯，又不让面试官淹没在工具里？

Muhan 描述了大约三年的渗透测试经历，一段独立的漏洞研究时期，以及他用静态分析和一个 AI 助手搭建的、用于发现 WordPress 插件漏洞的流水线。他说，这项工作带来了几个 CVE，有的已公开，有的还没有披露。教练把这当作很强的素材，但说第一遍讲的是一串技术和活动的清单，而不是对候选人的简明描述。

修订后的自我介绍，应当以这项工作的目的和候选人的角色开头，然后挑选几个能让职责范围变得具体的成果。教练请他把已公开的发现与未披露的区分开，避免暗示团队的成果完全是他一个人的，并解释是什么吸引他从事应用安全。他建议把工具当作辅助的细节，而不是标题。

这位候选人实际的 CVE 数量，在这场辅导里被描述得前后不一，所以本章没有把它们归并成一个数字。可用的经验是：在重复每个指标之前先核实，并让自我介绍传递出所追求的岗位类型。

Q怎样才能让一个主动性的例子，在中级别听起来分量十足？

Muhan 首先给出了一个小小的 IPv6 文档的例子：他的团队缺少一台适合做一项必需测试的家用路由器，所以他写了一份基于 EC2 的隧道文档。史蒂夫说，这项工作体现了足智多谋，但它在整个测试工作中占的份额很小，对一个中级别的岗位来说，可能读起来像一个初级的例子。

Muhan 接着描述了对一个依赖审计工具的更大改进。一个网络端点对它的请求做了限流，团队只能等它的速率限制，一次运行大约要 15 分钟。他调查后发现了这个工具可以用的一条 API 路径，然后修改了实现并加入了缓存；一次运行缩短到大约一分钟。

教练的修改加入了团队的背景：工程师们一直在等速率限制恢复，而 Muhan 提出了一种让工作继续推进的办法。当结果包含触发点、候选人的决定、可衡量的效果，以及团队工作方式上的任何变化时，就更有说服力。这是一个扎实的主动性故事，不过教练仍然要求更清晰地证明流程上有更广泛的改变，才能把它当作一个强有力的中级别例子。

Q候选人怎样诚实地描述一个弱点，又不让某一个细节主导整个回答？

Muhan 说，他会被网上的内容和消息分心，然后晚上加班补回时间。他试过屏蔽工具，也改变了作息。教练认出了一种真实的模式：上下文切换降低了专注度，并把工作推到了晚上。

这里的辅导是关于选择相关的细节，而不是编造另一个弱点。Muhan 可以解释，通知和网页浏览如何把他的注意力碎片化，描述他采用的屏蔽工具和作息，并说出发生了什么变化。教练提醒，在面试中点出具体的社交平台，可能造成他在工作时间刷屏的误导性印象；他应当保持回答的准确，同时聚焦于行为和纠正的步骤。

Q工程师应该怎样讲一个与客户之间的道德边界的故事？

一位客户要求在一天的期限内做一次渗透测试，而 Muhan 说，这类工作通常需要四五天。他争取到了更多的时间，完成了一次范围更窄的测试，发现了一个低严重度的问题。他没有把这个有限的结果，当作客户应该取消另一家服务商合同的证据。他不知道客户最终作了什么决定，因为那天是他的最后一天。

教练建议把它表述为一次关于证据能够支持什么的专业分歧。Muhan 可以解释时间表的限制，他能够负责任地完成哪些工作，以及他为什么不会认可一个测试无法证实的结论。重点是展现判断力和清晰的底线，同时不把客户或另一家供应商塑造成反派。结果应当明确保持为未知。

Q面试中的精力，怎样才能在镜头前显得真诚？

Muhan 问，他是否必须表现得比自己的感受更兴奋。史蒂夫说，镜头和面试的紧张，可能会压平一个人平常的精力，所以他建议适度补偿，让面试官看到候选人真正的兴趣。他举的例子，是 Muhan 对安全谜题和渗透测试的热情。

区别在于，适应一个职业场合，与假装成另一个人。一个人对经理、朋友或家人说话的方式可以各不相同，同时仍然保持真实。史蒂夫建议录下一次练习的回答，回看，并调整精力和表达，而不改变事实，也不制造热情。

在结尾的反思中，Muhan 说，他现在打算更有意识地构建故事，选择能展现有意义职责范围的例子，并避免可能分散重点的细节。

QAaron 应该怎样介绍他六年的工程工作，而不是逐个团队地复述时间线？

Aaron 的第一个回答，依次讲了 Alexa、内部评估工作、对外的 Bedrock 服务和智能体评估。史蒂夫说，这个时间顺序很有意思，却让人很难看到 Aaron 本人：他是什么样的工程师，他亲自贡献了什么，他能把什么问题讲清楚。

建议的自我介绍，把他定位为一位在 Alexa 和 Bedrock 与科学家和自然语言团队并肩工作过的工程师。教练建议他选出一个有难度的问题，直接说清楚，然后在给出解决办法之前停顿一下。一个简洁的问题陈述，让面试官能判断工作的规模，并提出一个有用的追问。

他还建议删去那些无助于听者理解岗位或问题的事实。技术术语和内部的产品区分，只有在能够澄清 Aaron 的贡献时，才应放进回答里。

Q工程师怎样解释一个资深规模的技术问题，以及用来解决它的判断？

Aaron 最有力的例子，是一个为文本数据集构建、执行路径很窄的评估框架。研究人员需要评估多模态数据集，包括大型视频文件，来自不同的存储位置，针对不同的推理端点。原有的假设已不再适用。

Aaron 描述了他如何泛化数据集格式，把推理放在可扩展的客户端之后分离出来，支持一个生产环境的端点，并改变数据到达作业的方式。他选择了一种托管的文件模式，而不是编写和维护自定义的分块下载代码，或采用更昂贵的文件系统，因为这个工作负载不需要那些额外的性能。他记录了扩展点，并把服务交给了下一个负责的团队；该团队后来利用他引入的抽象，添加了客户端。

史蒂夫说，当 Aaron 点出了让重新设计变得困难的压力时，这个故事才变得可信：一个真实的评估需求和一个截止日期，而现有用户仍然依赖旧的文本路径。面试官是在试图把问题的大小，与岗位的级别相匹配。工具名称和实现细节，只应在需要解释取舍和 Aaron 自己的贡献时，才随之出现。

Q当分歧仍未解决时，一个关于分歧的故事应该展现什么？

Aaron 说，当两种设计看起来都合理时，他往往避免冲突。教练重新界定了这个面试问题：团队需要在意见不同的情况下继续推进，一个有用的故事，会展示问题、各方的理由，以及决定是怎样推进的。分歧不必以一方被证明愚蠢收场。

Aaron 描述了一个仍在进行的团队间问题：较旧的服务使用一个推理平台，而一个较新的平台还没有接下旧平台所支持的全部用例。他的团队想为客户弥合这个差距，但平台团队对自己的路线图和支持承诺还不确定。教练称这是一个可能的影响力例子，但指出它仍未解决，而且主要是通过产品和管理层来斡旋，而不是与对方直接对话。

史蒂夫给了一个假设性的设计例子：SQL 对比键值存储，来说明怎样公平地界定相互竞争的约束。这是教练的例子，不是 Aaron 工作经历中发生的事。一个完成的面试回答，应当使用一个真实的、已经解决的决定，解释为什么两种选择都合理，并展示下一步或结果。如果两种选择在功能上等价，选择对方的做法，可能是一种稳健的判断，而不是被动的同意。

Q候选人应该怎样用面试故事来评估与公司的适配度？

教练说，面试故事应当既反映候选人的长处，也反映候选人想要工作的环境。一位看重工作与生活平衡的人，不应该仅仅为了拿到录用通知，就假装欢迎一种围绕例行个人牺牲而建立的文化；被录用到一个不合适的环境，可能造成面试回答原本想避免的那个问题。

对于冲突类的回答，史蒂夫建议展示候选人会评估哪些分歧是重要的。一个有力的回答，不会声称“老板说什么我就做什么”；它会解释为什么一项决定不值得升级上报，或者为什么一项风险需要更坚定的回应。这条建议是作为教练关于适配度和面试的判断来呈现的，而不是关于每位雇主的普遍规则。

Q第一个冲突故事传达出什么级别的信号？

Ahmed 首先描述了与一位同事的设计分歧，关于一种更稳健的方案，用来防范未来的数据丢失和运维工作。他研究了风险，提出了一个带有额外组件的设计，并最终把这个问题带给了一位资深工程师和经理。后来一次压力测试表明，那条更简单的路径在预期的数据负载下会很吃力。

史蒂夫说，这个故事有有用的素材，但按最初的讲法，分歧是与另一位中级工程师之间的，并且通过升级到更资深的人来解决。这使它听起来更接近一个扎实的中级别例子，而不是 Staff 级别的。对于冲突类的回答，他建议在抽象之下一层点明真正的取舍，解释为什么同事更简单的做法同样说得通，并展示两个人是怎样推进的，而不是把候选人塑造成显然正确的一方。

教练更广泛的教训是：选择一个职责范围和参与者都与目标岗位相符的故事。冲突本身不是成就；判断力、协作，以及朝着决定迈进，才是。

Q与一位首席工程师的分歧，怎样才能展现 Staff 级别的判断力？

Ahmed 随后讲了一个来自更大项目的、更有力的故事。他希望自己的团队承担一项工作，让下游客户不必去应付困难的数据负载；一位首席工程师则认为，这些客户应该自己负责这项工作，给 Ahmed 的服务增加复杂性是不合理的。Ahmed 不同意，但听取了意见，并服从了这位首席工程师的决定。

后来的结果让这个例子更有力：下游服务在这个负载下很吃力，Ahmed 的服务则处在更有利的位置来承受它，这位首席工程师回来对 Ahmed 说，他们本应选择他的方案。史蒂夫建议描述 Ahmed 如何让最初的决定变得可逆，然后与这位首席工程师一起闭环，方式是寻求共同的学习，而不是绕场炫耀胜利。

这次辅导强调了几个有用的信号：带着清晰的理由向上挑战，决定之后服从，当证据不完整时保留一条实际可行的改变方向的路径，并承认对方的推理。这位首席工程师后来的承认，比 Ahmed 单方面宣布自己是对的，是更有力的证据。

Q你怎样讲一个展现职责范围和压力的交付故事？

Ahmed 描述了领导一次向新系统的迁移，用于大规模的事件报告。这项工作已进行了大约两年；在早先的延误之后，领导层设定了一个四周的交付窗口。涉及将近二十个合作团队，第一次发布取决于上游和下游的团队。Ahmed 把团队的流程从 Scrum 改成了看板式的优先级队列，指定了更清晰的责任归属，与技术项目经理协调，并协商哪些需求可以推到后续的版本。

史蒂夫请他给出具体的对比，让规模变得可以理解：固定的截止日期、相互依赖的团队数量，以及所要求的范围的大小。Ahmed 指出有三四项大需求是可以推迟的候选，包括一个复杂的去重和数据合并功能。教练提醒，“很多工作”或故事点，并不能告诉面试官一个项目有多大。

当一项需求回来了，故事就变得更真实：利益相关者最终判断，去重的工作毕竟是必需的。Ahmed 和队友简化了设计，实现并测试了它，并在截止日期前几天发布。史蒂夫建议把这次反转，作为故事中的最后一个障碍。文字稿没有提供经过衡量的可靠性或合作方满意度的结果，所以本章没有编造。

Q教练给 Ahmed 留下了什么框架？

史蒂夫总结了三条面试故事的原则：以一个能在大约 15 秒内说清故事的标题开头；把核心回答控制在大约两分钟；选择能展现目标级别的例子；并把例子与公司看重的东西联系起来。清晰的结构，帮助面试官跟上证据，而不必强迫候选人复述每一个技术细节。

结尾还把观众引向一个仅限会员的后续内容。那部分后来的问答内容不在这份文字稿里，所以本章只涵盖这里可得的这场辅导。

Q讲讲你帮助一位吃力的同事的一次经历。

候选人描述了一位新的 L4 应用科学家加入一个复杂的亚马逊搜索团队。入职材料宽泛且让人应接不暇，所以他安排了答疑时间，发现主要的问题是一次性给的背景太多，并把工作拆成可以达成的步骤：构建特征，训练一个模型，然后集成起来进行测试。他还修订了入职文档，让后来的新人可以复用。

要点。教练要求一个清晰的结果，和一个更简单的开头。故事应当说明，对这位同事和团队来说，什么发生了改变，但文字稿并没有确认一个员工结果，所以不应该美化。要把说法限制在候选人的实际角色之内，而不是声称一次他无法核实的晋升或结果。

Q你最大的弱点是什么？

候选人说，他的估算可能过于乐观，尤其是在研究和探索会带来不确定性的陌生领域。他把这种模式与想要取悦别人联系起来，并点出了代价：返工、让队友和利益相关者感到焦虑，以及损害信任。

要点。一个有用的关于弱点的回答，会点明一个真实、反复出现的问题，解释它的影响，说明反馈来自哪里，并描述目前的应对措施，同时不假装这个问题已经消失。候选人修订后的做法，是留出更多的探索时间，加上缓冲，获取同行的意见，说明各项假设，并给领导一个更现实的范围。他指出，研究性工作中的不确定性，仍然高于熟悉的实现类任务。