资源

关于 Staff-plus 工程师的更多资源

我访谈过的 Staff Engineer，没有一个人是独自走到今天的。他们大多要么靠如饥似渴的阅读，要么靠建立起强大的同事关系网。本节收集了一些值得推荐的资源。

你的人际网络 几乎所有 Staff-plus 工程师一致认为，最有价值的学习资源不是书、博客、演讲或论文，而是他们的同行和导师网络。如果你只有一个小时用来提升自己，最好的投入方式就是去结识一批担任类似角色的人。

如果你在找 Slack 社群，Rands Leadership Slack 里的 #staff-principal-engineering 是一个相当活跃的频道。

Staff-plus 工程师是做什么的？ 以下是一些人对自己角色的描述：

• Being a principal engineer at Skyscanner

• Defining a Distinguished Engineer by Jessie Frazelle

• How I operated as a Staff engineer at Heroku by Amy Unger

• Not all engineering leaders are engineering managers by Tanya Reilly

• The Nuts and Bolts with Tanya Reilly

• On Being A Principal Engineer by Silvia Botros

• On Being a Senior Engineer by John Allspaw

• Staff Engineering by Sam Kleinman

• Thriving on the Technical Leadership Path by Keavy McMinn

• What’s a senior engineer’s job? by Julia Evans

• What a Senior Staff Software Engineer Actually Does, Part 1: The Role and My Tasks and Part 2: The Mindset and Focus of the Role by Joy Ebertz

• What does Staff level mean at GitLab?

如何成为 Staff-plus 工程师 以下是一些人分享的成为 Staff-plus 工程师的经历：

• Becoming a Staff Engineer – Interview with Kristina Fox, Staff iOS Engineer at Intuit by Kaya Thomas

• On becoming a senior technical leader by Jesse Pollak

• On Mid‐Career and Managers by Ryn Daniels

• How does one become a Staff Software Engineer at Google? on Quora

• The Engineer/Manager Pendulum by Charity Majors

• THings to Know About Engineering Levels by Charity Majors

以 Staff-plus 工程师的方式开展工作

• Being Glue by Tanya Reilly

• Computers can be understood by Nelson Elhage

• Effective Mental Models for Code and Systems by Cindy Sridharan

• “I Wouldn’t Start From Here.” How to Make a Big Technical Change by Tanya Reilly

• Migrations: the sole scalable fix to tech‐debt by Will Larson

• On Mid‐Career and Team Dynamics by Ryn Daniels

• Reclaim unreasonable software by Will Larson

• Surviving the Organisational Side Quest by Tanya Reilly

• Systems that defy detailed understanding by Nelson Elhage

• Team Objectives by Marty Cagan

• Technical Decision Making by Cindy Sridharan

• Technical Research and Preparation by Keavy McMinn

• The Behind‐the‐scenes Work of Tech Leadership by Jean Hsu

• Understanding Project Management Will Improve Your Developer Job by Daniel Na

• What Does Sponsorship Look Like? by Lara Hogan

• Where to Start by Keavy McMinn

• Design Docs, Markdown and Git by Caitie McCaffrey

技术方案文档

• A practical guide to writing technical specs

• Design Docs at Google

• Design Docs, Markdown, and Git

• Documenting Architecture Decisions

• How to write a better technical design document

• Technical Decision‐Making and Alignment in a Remote Culture

• Writing Technical Design Docs

工程战略 关于广义工程战略的文章：

• A Framework For Responsible Innovation

• How Big Technical Changes Happen at Slack ‐ Several People Are Coding

• On Drafting an Engineering Strategy

• Defining a Tech Strategy

• Delivering on an architecture strategy

• Stepping Stones not Milestones

• Achieving Alignment and Efficiency Through a Technical Strategy

• The difficult teenage years: Setting tech strategy after a launch by Anna Shipman

• Learning to have an engineering vision

工程战略的实例：

• Run less software by Rich Archibold

在战略的其他方面也有很多优秀资源，例如 Marty Cagan 关于 Product Strategy 的系列文章。

书籍 虽然我发现很多人并没有读太多书，但当我请 Staff 工程师推荐最有价值的资源时，他们最后总会提到一位私人导师或一本书。针对某个具体问题，他们也许会提到相关的博客文章和技术演讲，但真正改变他们的，是这种篇幅更大、更像纸质书的形式。

以下是被推荐过的一些书：

• A Philosophy of Software Design by John Ousterhout

• Accelerate: Building and Scaling High Performing Technology Organizations by Forsgren, Humble and Kim.

• Becoming a Technical Leader: An Organic Problem‐Solving Approach by Gerald Weinberg

• Building Evolutionary Architectures by Ford, Parsons, and Kua

• Escaping the Build Trap: How Effective Product Management Creates Real Value by Melissa Perri

• Good Strategy Bad Strategy: The Difference and Why it Matters

• High Output Management eBook: Andrew S. Grove

• The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier

• The Mythical Man‐Month by Fred Brooks

• The Phoenix Project by Kim, Behr, and Spafford.

• The Passionate Programmer by Chad Fowler

• The Pragmatic Programmer by Andrew Hunt, David Thomas

• Resilient Management by Lara Hogan

• Software Design X‐Rays: Fix Technical Debt with Behavioral Code Analysis by Adam Tornhill

• Thinking in Systems: A Primer by Donella Meadows

如果你还想找更多推荐书单，这类书单有很多，包括我自己在 Irrational Exuberance 上列的 Best Book。

演讲 和我聊过的 Staff-plus 工程师普遍认为，做演讲对他们的帮助大于听演讲，但其中确实也有一些非常出色的演讲。Cindy Sridharan（Twitter）是发掘精彩演讲的最好来源，特别是她整理的 Best of 2019 in Tech Talks、Best of 2018 in Tech Talks 和 Best of 2017 in Tech Talks。

论文 很少有 Staff-plus 工程师是计算机科学论文的狂热读者。不过，大多数人对几篇奠基性论文都很熟悉，而那一小部分经常读论文的人，也确实从中获益良多。

如果你想加入经常读论文的行列，没有比 Adrian Colyer 的 the morning paper 更好的起点，它会在每个工作日给你发一篇计算机科学论文的解读。如果你更想先对一些知名论文有个基础了解，可以先读 How to Read an Academic Article by Peter Klein 或 How to Read a Paper by S. Keshav，再来看下面这份推荐论文清单：

• Dynamo: Amazon’s Highly Available Key‐value Store

• On Designing and Deploying Internet‐Scale Services

• No Silver Bullet ‐ Essence and Accident in Software Engineering

• Out of the Tar Pit

• The Chubby lock service for loosely‐coupled distributed systems

• Bigtable: A Distributed Storage System for Structured Data

• Raft: In Search of an Understandable Consensus Algorithm

• Paxos Made Simple

• SWIM: Scalable Weakly‐consistent Infection‐style Process Group Membership Protocol

• Hints for Computer System Design

• Big Ball of Mud

• The Google File System

• CAP Twelve Years Later: How the Rules Have Changed

• Harvest, Yield, and Scalable Tolerant Systems

• MapReduce: Simplified Data Processing on Large Clusters

• Dapper, a Large‐Scale Distributed Systems Tracing Infrastructure

• Kafka: a Distributed Messaging System for Log Processing

• Large‐scale cluster management at Google with Borg

• Mesos: A Platform for Fine‐Grained Resource Sharing in the Data Center

要找高质量论文来读，最好的去处是 Papers We Love，他们还会组织线下聚会来讨论论文。另外一些资源还有 ACM SIGOPS Hall of Fame Award 榜单和 Irrational Exuberance 的论文合集。

其他不错的东西 在整理这些资源时，我还发现了一些不太好归类，但我觉得很好、值得一看的内容：• Testing in Production, the safe way 和 Testing in Production: the hard parts by Cindy Sridharan

• A decade in review in tech by Cindy Sridharan

• Boogeyman Problems by Dan Na

如果你发现了更多，欢迎推荐给我！

Staff-plus 工程师在组织中的位置

当我为工程组织做组织设计时，我经常思考“组织数学”：每个团队应该有一名经理和六到八名工程师，每个管经理的经理应该带四到六名经理。从这些数字出发，你可以很快算出适合你组织的、基本好用的结构。它可能不是_完美_的，但它_可行_。

在我用这套方法设计多个组织的过程中，一个反复出现的边界情况是：最资深的工程师应该向谁汇报？按组织数学的要求，他们应该向组织末梢节点的经理汇报吗？还是说，作为组织中的关键领导者，他们应该向更高级别的领导者汇报，以便获得做好工作所需的信息和授权？

在回答之前，有必要先描述一下当今公司中最常见的几种配置，特别是不同 Staff-plus 类型在汇报关系上的差异：

• Tech Leads 通常向负责一个团队的经理汇报，较少情况下会向负责两到四个团队的经理汇报。无论哪种情况，他们的运作范围都和那位经理一致。例如：Dan Na 向负责国际化平台（Internationalization Platform）的经理汇报。

• Architects 通常向更高级别的经理汇报，多半是管经理的经理。他们往往负责该经理职责范围内某个横向切面，例如数据建模。例如：Keavy McMinn 向 CTO 汇报。

• Solvers 通常出现在“弱团队概念”的公司里，在这类公司中汇报层级往往没那么明确，也不是刻意设计的。他们最常见的是向团队经理汇报，但各种情况都有。另一种常见模式是把这些人集中到_“Office of the CTO”_ 或 “Office of the CEO”，由一位高管直接给他们安排工作。例如：Ritu Vincent 所在的孵化器向 CEO 汇报。

• Right Hands 向一位高级领导者汇报，通常是负责上百人甚至更多人的经理，带着这位领导者的授权开展工作。例如：Rick Boone 向负责基础设施的 VP 汇报；Michelle Bu 向首席产品官汇报。

理解这些不同类型在组织汇报关系上的典型差异，有助于解释汇报结构中那些看似随意的安排_背后_的原因。

CTO 办公室

先岔开说一下 “Office of the CTO” 这个概念，因为很多人还没有在工作中遇到过。通常 CTO（有时 CEO 也会这样做）会直接带两到八名 Staff-plus 工程师。这些人会被当作高级领导者来对待：领到一个问题或机会去推进，几乎没有什么管理上的支持，必要时可以就近找这位高管要支持。

在这些办公室里，你会看到 Architects、Solvers 和 Right Hands 的混合搭配。

通常 Office of the CTO 在公司发展相对后期的阶段才会出现，常常是作为已有组织问题的变通办法而引入的，例如 Staff-plus 工程师和经理团队之间缺乏信任，或者 CTO 无法授权。如果你发现自己在公司发展的_早期_就想用这一招，先问问自己：你是不是在回避一个本该直接解决的问题，而不是往组织结构里塞一个新概念。

但在实践中……

从类型上看，每位工程师在组织中通常都有理论上正确的位置，但你会发现，在实践中，很少有组织能让实际汇报结构和理论结构完全一致。

有时这是因为管理团队对组织结构关注不够。在另一些情况下，是因为经理没有足够的带人带宽来把人放在正确的位置上。例如，“正确”的经理手下已经带了十二个人，实在没法再有效支持一名工程师。还有一种常见情况是组织结构变得太频繁，经理不愿意让这位工程师_再_换一次经理，尤其换经理常常会导致一次含糊其辞、不上不下的绩效评估。

如果你发现自己汇报的对象可能不是合适的经理，和你的经理聊聊这件事是合理的，但要意识到，很多经理听到“你不是适合我的经理”这种暗示时会产生防御心理。如果你的经理足够成熟，而且你和他的关系很好，那就直接谈。如果不是，风险更小的做法是和他的越级上级做一次比较抽象的讨论，聊聊在他们组织里 Staff-plus 工程师一般向谁汇报。

在你急着推动改变之前，先问问自己：如果汇报结构变了，会有什么不同？汇报结构是一种权力形式，而人们普遍会高估权力能带来的帮助。经典的陷阱在于：最能从更多授权中受益的人——少数群体和女性——恰恰最可能遇到对这种调整建议反应防御的经理。

理想的做法是什么？

如果你想给管理团队写一份提案，讲清楚这类组织调整长期应该怎么做，可以考虑以下几点。条件允许时，汇报关系的调整应该立即发生。 拖延会迫使当事人经历两次转换，其中还包括新旧角色之间一段特别难熬的中间状态。即使意味着新经理手头工作已经饱和、能给你的支持会减少，一次到位的角色转换风险总是更低。

如果做不到立即调整，一定要定一个时间表，明确角色变化之后什么时候转到正确的经理手下。如果没有一个可以重新讨论结构的时间点，这件事大概率就不了了之了。

大多数公司都很难搭起这种组织基础设施，把 Staff-plus 工程师真正当作领导者来支持，所以你要把这看作一个需要_用几年时间_去推进的问题，而不是一个能一夜解决的问题。如果你指望上来就得到一个立竿见影、永久有效的方案，很可能会经历一番动荡。

管理 Staff-plus 工程师

在收集 StaffEng 的反馈时，有人希望多写一些关于管理 Staff-plus 工程师的内容。这和本书的主题不太契合——本书主要写给 Staff 工程师本人，而不是写给公司或经理——但这是一个有意思的话题，值得作为附录来写。

当然，管理 Staff-plus 人员并不全是特殊之处：管理任何人、任何角色都有通用基本功，比如做好 1 on 1 或给反馈。这类内容可以去读 Lara Hogan 的 Resilient Management 或 Camille Fournier 的 The Manager’s Path。我在这里想写的是，管理 Staff-plus 和管理比如 Senior 工程师有什么不同。

这些角色在不同公司之间差异很大，所以管理你的 Staff-plus 工程师时，有些做法取决于你们公司侧重哪种 Staff 类型，以及 Staff-plus 工程师在工程组织中的位置，但也有一些做法在大多数配置下都适用。

• 多赞助、多支持，少指挥。 如果你每天都在给 Staff 工程师下指令，说明你把他们用错了地方。如果你连每周一次的反馈都给不到，就是在拖慢他们的成长。如果你不把自己的赞助加到他们的项目上，他们身上的主动性就会被磨掉。

• 帮他们重写对成功的定义。 在一支高绩效的产品工程团队里工作，是一个正反馈飞轮：产品经理认可你的工作，工程经理带动团队，同事喜欢一起共事，用户喜欢你的产品，业务喜欢用户的增长。反过来，Staff 工程师的反馈飞轮远没有这么即时。你要花更多时间处理冲突，站在更长的时间维度上工作，代表一些重要的优先级，而这意味着要给另一些业务或产品目标降级。很多人没有处理好这种转变，一年后醒悟过来，发现自己讨厌上了新角色。作为他们的经理，你可以帮助他们认清这种转变，并找到保持活力的补偿策略。

• 给反馈。 重写成功定义的一个特别重要的策略——也是让他们持续成长的策略——就是频繁给反馈。如果他们打错了仗，直接告诉他们，并告诉他们_为什么_。如果他们排的优先级和你不一样，告诉他们，并告诉他们_为什么_。对高绩效者来说，没有什么比不知道自己做得怎么样更让人焦虑！如果你不给反馈，特别是不肯定他们做得最好的工作，他们就会一直换打法，直到你开口为止（结果往往让你后悔）。

• 让他们知情。作为经理，很容易忘记自己能接触到的信息比一起工作的工程师多得多。现实是，大多数组织的信息流都是围绕经理之间互通关键信息来建的。如果你不建立一个稳定、可复用的机制，把你的上下文同步给他们，你的 Staff-plus 工程师就会束手束脚。有些人会在 1:1 开头同步这些信息，效果还行，但我更倾向于边发生边丢到团队聊天频道里，再汇总到每周邮件里发出来。

• 让他们参与规划和排优先级。 很多工程师苦恼于“正确的事永远排不上”，而最好的解法之一就是主动让更多工程师参与规划过程。这在两方面起作用。第一，他们能了解更多竞争中的工作，理解那些工作为什么重要；第二，他们在场，才能更有效地为他们眼中缺失的技术工作争取资源。

• 约定好如何在独立行动中保持对齐。 当你把支持的 Staff-plus 工程师推向领导岗位，他们会开始更多地主导工作，其中有时会让你意外。如果和你共事的领导者_从不_让你意外，说明你授权不够，但如果他们经常让你意外，明确一下你的管控手段会很有帮助。

• 给他们留思考的空间，同时别让他们脱离组织的日常现实。 很多担任这类角色的人被影响力和“为业务做正确的事”驱动得太强，不加外部干预就会把自己耗干。如果你是他们的经理，这个“外部干预”就是你。如果你看到他们花太多时间救火、帮人扫清紧急工作的障碍，就和他们一起守住一部分深度思考的时间。反过来，如果你看到他们只做深度思考，很可能正在失去上下文，如果不调整这种配比，还可能失去同行和业务的尊重。

• 提醒他们是榜样。 和经理一样，组织里的工程师会看着 Staff-plus 工程师，学什么行为、什么做法会被奖励（和被容忍）。这是很大的责任，也是很大的影响力机会：以身作则践行正向价值观，他们就有机会在周围带出一个正向的组织。

• 减少经理工作的外溢。 为了追求效率而牺牲有效性，很多公司把经理困在海量的协调和官僚事务里。当你忙到 drowning，就会到处找人帮忙，很多时候就是把管理工作甩给手下的 Staff 工程师。这种事肯定_有时_会发生——你和管理 Staff-plus 工程师本来就是合作关系——但要尽力减少这种量，并保证它是暂时的外溢，而不是永久的甩锅。

• 给他们未经提炼的问题。 这是高级角色，应该给他们一片问题空间，让他们自己收敛成更具体的问题和解法。他们的技术上下文比你好，如果你把自以为的问题指得太死，就用不上他们的判断力。选对问题至少和找对解法一样能产生影响，而只有留出空间，才可能选对问题。

• 把空间让给他们的领导力。 当你管理一名 Staff-plus 工程师，想办法把你负责的东西明确划出一块，交给他们负责。例如，你怎样才能让他们、而不是你自己，对团队的技术质量负责？这对你们双方都是杠杆，也能让 Staff-plus 工程师有主人翁感。

• 珍惜他们。 优秀的 Staff-plus 工程师运作起来相当独立，所以组织着火时很容易先把他们往后放。忽略最重要的人，是经理版的“吃零食”——感觉重要，但通常不是正确的优先级。所以 1:1 要照开，总之要记得为他们到场，特别是当他们不是那种会主动索取关注的人。

• 建立并坚持和业务对齐。 有些工程师抱着“技术工作比需要这些工作的业务更重要”的心态也成功了。这种心态一般都有毒，但在 Staff-plus 工程师身上是剧毒。这个人是整个组织的榜样，把他们拉出这种视角，是他们能留在领导岗位的必要条件。和业务错位的领导者，公司最后都会架空乃至请走。

• 按完整角色要求他们。 很少有人带着重大技术短板升到 Staff-plus，但以我的亲身经历，很多升到这个级别的人带着明显的领导力或行为短板。这些人拿到了 title，却陷在 Staff 期的炼狱里：被期待去领导，却被挡在大多数领导机会之外。大家觉得他们太不可靠、“拉他们进来成本太高”。你得把这些短板反馈给他们，按完整角色期待要求他们。别让他们无限期地当个半吊子领导。也许他们当初是靠 title 通胀拿到的角色，于是你决定替他们遮掩短板而不是解决问题——别这样，正确做法是想办法支持他们，同时把责任还给他们。

• 给他们进房间的机会，但别把它当身份象征。 人们常常执着于身份象征，工程师特别常见的一种就是“在房间里”。有时开会_就是_工作本身，但大多数例行汇报会人已经太多了，与其场场都叠加上，不如把参会分摊开，这样你和你支持的 Staff-plus 工程师都能省出大量时间和空间。

从 Senior 到 Staff-plus 的转变是一次重大转变，改变的是工作的性质，而此前的晋升往往只改变工作的范围。很多人 struggle 于这种转变，很多经理也不知道怎么帮自己带的 Staff-plus 工程师。当然，这份清单并不完整，但希望它是一个有用的起点。

设计 Staff-plus 面试流程

谈到设计 Staff-plus 工程师面试流程，首先要说的是：绝对没有人确信自己的 Staff-plus 面试流程是有效的。很多流程最后招的是解题_特别_快的 Senior 工程师，而这并不能反映真实角色。另一些流程看重沟通能力，沟通确实是角色的关键部分，但肯定不是全部。还有少数公司把流程做成了看候选人像不像现有高级工程团队的一员，把优秀和眼熟搞混了。

即使没人对自己的流程很满意，依然有一批集体经验可以借鉴，这就是本节要讲的。我们先看 Staff-plus 面试流程常见的失败模式，再讨论你_真正_想考察的信号，最后讨论一些有助于评估这些信号的面试形式。

挑战

技术面试整体上已经够乱了，面试非常资深的候选人还有自己专属的一整车问题。在思考什么做法更好之前，先理解常见的失败模式会很有帮助：

• Senior 工程师加强版。 很多面试流程把 Staff-plus 工程师当成各方面都强一点的 Senior 工程师：写代码快一点，表达清楚一点，聊架构时 nuanced 一点。这源于大多数人不熟悉 Staff 角色，通常会导致 Staff-plus 工程师在这种流程里表现很差。特别是大多数 Staff-plus 工程师写代码比 Senior 少，因此做程式化编程题反而_更慢_而不是_更快_。你会遇到一些手速依然很快的 Staff-plus 工程师，但这种速度和他们的影响力没什么相关性。

• Senior 工程师减弱版。 反过来，另一些面试流程意识到 Staff-plus 工程师写代码时间更少，预期他们在一些程式化编程题上会慢一些。这让 Staff-plus 工程师更容易通过，但并没有考察到让这类工程师产生卓越影响的特质。如果不增加额外的面试来捕捉这些长处，程式化工作的速度在一定程度上确实和资历相关，但它和其他很多因素的相关性更强。

• Senior 工程师，能发 offer 版。 另一种失败模式是公司招不到 Senior 工程师，就把 title 通胀一下，但角色期待不变。这时面试和实际工作是匹配的，但 title 不匹配。公司和候选人都不愿承认这种通胀，之后公司所有 Staff-plus 招聘都蒙上了一层不确定性。

• 像我们的人。 很多流程关注 Staff-plus 候选人表现出的智慧和自信像不像公司现有的 Staff-plus 工程师，面试反馈里会出现“感觉他天然就是这个团队的人”这类话。这种做法更容易锚定在自信外露这类半随意的特征上，而不是候选人的能力上。

• 不如我。 特别是在招第一批 Staff-plus 工程师时，经常会遇到一些偏初级的面试官，低估候选人的长处，反而锚定候选人能不能干好面试官现在的活。你会遇到很 impressive 的 Staff-plus 候选人，但面试团却怀疑他能不能胜任中级工程师。这种情况在女性和少数群体候选人身上被提起得最多。

• 反向过滤器。 某些面试是组织不会用 Staff-plus 工程师的信号：白板算法题、面试官大多偏初级，等等。很多 Staff-plus 流程会让最好的候选人在流程早期就退出，而且这种流失常常在招聘指标上看不见。

• 太看重 title？ 到了一定成就水平，人们不太在意公司内部级别，一般是因为财务上已经比较自由。这给刚达到 Staff-plus 水平的人带来一种 peculiar 的压力：怕显得太看重职业或 title，反而让第一次拿到这个 title 变得更难。

有些问题很难解决，有些只要放在心上就很好解决，但在设计或重做 Staff-plus 面试流程时，这些都值得考虑。

考察信号

最好的面试流程都是从想捕捉的信号正向推导出面试主题和形式，所以第一个重要问题是：“招到成功的 Staff-plus 工程师，哪些信号最重要？”

我建议重点关注的信号是：

• 自我认知。他们是否为错误负责？是否在曾经较弱的领域展现出成长？

• 判断力。 他们能不能看到拐角后面的问题？能不能处理宽泛、模糊的问题？能不能在关于权衡或设计的争论中居间调解？能不能给高难度工作的执行降险？

• 协作。 他们能不能和别人好好合作？经验不如他们的人呢？比他们经验丰富的人呢？他们的经理呢？跨职能同事呢？高管呢？

• • 沟通。 他们是不是好的倾听者，能听懂别人的观点？能不能把自己的想法讲清楚？能不能用你们公司依赖的形式（文字、口头等）沟通？

• 培养他人。 他们周围的人有没有成长？他们负责领域的“组织板凳深度”是变厚了还是变薄了？坏掉的系统和流程有没有被清理掉？

有意思的是，很多人不会把这些明确看作技术能力。领域专长在做好所有这些事上都是重要因素，但把专长和其他关键能力和行为结合起来用，才是从资深 Senior 工程师跨到 Staff-plus 的关键。

形式与结构

设计面试流程时，永远要问自己的两个关键问题是：

1. 这个人要做好日常工作，需要完成哪些任务、展现哪些行为？

2. 我们怎样让他现场做出来，而不是只听他说？

越资深的候选人越 diplomatic，_问_他们做过什么，永远不如_看_他们做。Mentorship 如果是最重要的工作，就别只听他们谈 mentorship，而是想办法_看_他们带人。如果是架构，就拿出你们现在的系统，看他们怎么提问、遇到不同意的设计怎么反应——远离含糊抽象的空谈。

除了典型的一对一聊天和编程面试，我发现下面这些面试形式和结构对评估 Staff-plus 信号特别有效：

• 结构化演讲。 让候选人准备一个窄话题，给一组同行讲二十到三十分钟。这种形式能很好地考察结构化思考、表达、听取和回答问题。选题不同，还可以有针对性地考察一到两个你关心的领域。这种形式特别适合听候选人怎么谈论自己的同行和同事。

• Code review。 准备一个 pull request，请候选人给反馈，重点看同理心、清晰度和有用性。

• 数据建模、接口和架构。 让候选人走一遍系统设计，通常重点是系统如何演进以满足变化的需求。这类面试常常想一次做太多：收窄范围、逐层加码，让走得远的候选人可以一直深入。

• 领域专长。 考察他们专长领域的面试。例如，前端工程师可以和设计师、产品经理协作，讨论技术约束怎么影响 proposed 设计和上线时间。后端工程师可以给候选人一段坏掉的软件或环境，让他一路 debug 到修复。

• Mentorship panel。如果面试团全是偏初级的人，很难招到 Staff-plus 候选人，但如果候选人没展现出带初级同事的成功经验，招进来风险也很大。找三到四位他未来可能要带的人，带着问题来。特别要看他们怎么把粗糙的问题引导成有用的讨论，这能很好地看出他在新角色里带人的能力。

如果这些形式还不够，那就去问问同行！大多数公司都给 Staff-plus 设计过 bespoke 流程，和他们聊聊能学到很多。

如何整合起来

你可能以为最后会给出一套拿来即用的 Staff-plus 面试流程，很抱歉要让你失望了，我认为大部分价值来自想清楚什么信号对你重要、并设计出能触达这些信号、又和你及你们公司气质相符的形式。

无论最后用什么面试，都要测试、收集候选人反馈、持续迭代得更好！

Staff-plus 职级阶梯

现在公开分享的职级阶梯_so_多，设计自己的阶梯之前没理由不先读个五六份。

特别值得一读的有：

• Rent the Runway

• Kickstarter

• Patreon

更多收集在 progression.fyi。

我认为重要的是认识到，职级阶梯只对人群有效，几乎永远不能干净地套到某个人身上。这种效应在 Staff-plus 尤为明显，这类角色常常只有一两个人。阶梯必不可少，但别把它当成现实运作的地图，它只是讲述应该如何运作的神话。

Charity Majors 还写过一篇关于工程级别的有用指南 things to know about engineering levels。