咖啡聊天就是 30–45 分钟的非正式对话，在咖啡馆或视频通话里都行。没有白板，没有面试官团，没有陷阱题。我讲我们在做什么、为什么做，对方讲自己在做什么、接下来想要什么，聊完双方就知道值不值得继续深谈。招聘与其说是筛选问题，不如说是匹配问题，而要交换匹配所需的信息，我不知道还有什么比这更快的办法。

我为什么坚持做这件事

#

我已经不把这些聊天当成招聘了。它们就是聊天，只是每隔一阵子，其中一场会变成一次入职——有时是十八个月之后，对方的处境变了。能稳定产出好员工的管道，是靠这样的关系一点点垒起来的，不是靠职位广告。

它还解决了职位描述的老问题。JD 天生只能写得笼统。喝着咖啡，候选人可以问真正要紧的问题：头六个月做到什么算成功？我会和谁一起工作？团队眼下最棘手的技术难题是什么？听到诚实回答的人，会自己做出正确的取舍。

另外，聊天是在“演示”你的文化，而不是“描述”它。你有没有做功课、是不是真的好奇、尊不尊重对方的时间，这些比任何招聘页面都有说服力。反过来也一样——一个人在放松的对话里的样子，比排练过的面试更能告诉你和他共事是什么感觉。

咖啡聊天最见效的几个场景：接触没在找工作的人；在正式流程之前给内推热热身；以及和正在考虑职业转向的人聊聊——从 IC（个人贡献者）转管理、从创业公司去大厂，或者反过来。在人才紧张的市场里，你想要的人多半都属于其中一类。

我怎么安排一场咖啡聊天

#

第一条消息决定一切。模板化的开场白只会被删掉。先做功课，再坦白来意：

“你好 Sarah，我看了你在 QCon 上关于分布式系统的演讲，也读过你写事件溯源的博客。我们在 [公司] 扩展支付基础设施时正遇到类似的挑战。愿不愿意来一场 30 分钟的咖啡聊天？没有面试议程——只是想听听你的看法，也分享一下我们在做的事。”

这样写有效，是因为它具体、不藏目的，而且给出了价值（一次关于有趣问题的交流），而不是单方面索取时间。接下来是把麻烦留给自己：多给几个时间选项，选对方方便的地点（线上就用不需要下载的视频工具），发一封信息完整的日历邀请，别让对方猜。

聊天本身有个松散的形状就够了。开头几分钟是真诚的寒暄，说清楚为什么找对方。然后听对方讲：现在的工作、喜欢什么、烦什么、下一步想要什么——这一段你的任务主要是听。再讲你们的事：使命、团队真实的难题，包括难啃的部分，因为候选人尊重坦诚，而且对推销的味道极其敏感。最有价值的是接近尾声的开放环节：什么条件成立，对方才会考虑挪动？最后把下一步说清楚，哪怕下一步只是“保持联系”。

聊完 24 小时内发一条简短的感谢，提到对话里某个具体细节；答应过的东西——引荐也好、链接也好——尽快兑现。这段无聊的收尾，才是公司文化的现场演示。

如果你打算长期做，就用一个简单的表格记下聊过的人，隔段时间问候一下，哪怕手上没有空缺。这也不必是管理者的专利——很多最好的聊天，发生在你的工程师约自己圈子里厉害的人喝咖啡的时候。好的内推往往就是这么来的。

值得一问的问题

#

我常问的：

• “你最近做过的最有意思的问题是什么？”
• “下一份工作里，你希望有什么不一样？”
• “你喜欢怎样学习？希望怎样在职业上成长？”
• “有什么问题是你想问的、能帮你判断这里合不合适的？”

如果我坐在候选人那一侧，我会问：

• “团队现在面临的最大挑战是什么？”
• “这个职位的成功怎么衡量？”
• “晋升路径是什么样的？”
• “你当初为什么加入？为什么留下来？”
• “关于在这里工作，有什么事是会让我意外的？”

如果你是被邀请的那一方

#

搜“咖啡聊天是什么”的人，大多其实坐在我对面：有人约了他们，他们想知道自己要面对的是什么。下面是我站在发邀请这一侧，想告诉你的话。

它不是面试。没人给你打分，也没有测试，所以不用准备标准答案。但它终究是第一印象，所以把它当成见一位未来的同事，而不是朋友的朋友。和面试不同的是，你可以尽管好奇，而且对方期待你问的和答的一样多。

穿你平时在那家公司上班会穿的衣服。拿不准的话，商务休闲永远不会错。如果是视频通话，打开摄像头，找个安静的房间，这比穿哪件衬衫重要得多。

准备大约半小时就够了。看看这家公司做什么，以及对方写过或做过的东西。准备一个两分钟的版本，讲讲你现在在做什么、接下来想做什么，因为这个问题一定会来。再带上两三个自己的问题，上面那份清单就是个不错的起点。

至于聊什么：你的工作、你喜欢它哪里、你对他们的工作好奇什么。薪资先放一放，除非对方主动提起。问一句他们心里有没有具体的职位、如果有的话流程会是怎样，完全没问题。

一般是发起邀请的人买单。你可以主动提一下，但别为这个推来推去。一天之内发一条简短的感谢，提到你们真正聊过的某件事，你就已经比大多数人做得好了。

如果你自己也想约一场，那就开口。消息写短一点，说清楚为什么找的是这个人，让对方容易答应：“我一直在关注你们团队做的新搜索功能，我自己也在考虑转去做平台工程。接下来几周你有没有 30 分钟，喝杯咖啡或者打个电话？时间按你方便来。”这么具体的请求，大多数人都会答应。

把它搞砸的几种方法

#

最快的一种是把它变成暗中面试。一旦开始考察技术能力、往里塞行为面试题，那份默契就破了——这些留给正式流程。其次是用力过猛地推销：留得住的员工，都是把难处看清楚之后才加入的人。毫无准备地出现，或者聊完就消失，伤害更隐蔽——每一场聊天都在决定这个人会怎么向自己的圈子描述你的公司。

站在我这一侧，警报信号是：对什么都没有好奇心的候选人，纯粹交易感的对话，以及用同一种怨气描述每一任前雇主的人。候选人也该有自己的清单：说不清这份工作为什么重要的对接人，谈到流失率或公司方向就闪烁其词的回答，还有那种比起理解你更热衷于推销的人。

不是每场咖啡聊天都有下文，事实上大多数没有，这没关系。关键在于，下次要填一个重要岗位时，你不是从一页空白的招聘启事开始，而是从一摞真实的对话开始。发出去的应该是一句“喝杯咖啡吗”，而不是一份职位描述。

延伸阅读

#

本站相关文章：

• 开发者面试中的 STAR 方法 —— 聊天进入正式面试流程后用得上
• 刚当上工程经理，我先做这三件事 —— 团队靠什么运转，正是你在匹配的东西
• 为什么你应该去创业公司实习 —— 和考虑去创业公司的人聊天时的有用背景

外部资源：

• First Round Review：工程师招聘 —— 经验丰富的创业公司操盘手写的招聘指南
• Lara Hogan 的“第一次 1:1 该问的问题” —— 本是为 1:1 写的，用在咖啡聊天里同样好使
• Patrick McKenzie 谈薪资谈判 —— 值得一读，帮你理解候选人那一侧的处境
• Who: The A Method for Hiring —— Geoff Smart 和 Randy Street 的系统化招聘框架
• 哈佛商业评论：招聘专题 —— 有研究支撑的人才招募文章

Alan 为什么放弃了开会

#

他们的起点你一定不陌生：没人做准备，会议迟迟开不起来，嗓门最大的人不管对错总能拍板。一小时后，你比进会议室之前更糊涂，开始琢磨抽屉里还有没有止痛药。

Alan 一开始也想修好会议这台机器——最长 15 分钟、议程明确、必须产出决策。没用。讨论照样跑题，说过什么没人记得，缺席的和远程的同事干脆被排除在外。于是他们干脆把整件事搬进了文字里。

他们列举的好处我基本都认。写作逼你停下来真正思考，讨论因此更细致、论证更扎实；一切都有记录，不用靠七零八落的记忆；也不再是一场口才竞赛。而且论坛对全公司公开，谁都能参与讨论——不再只属于碰巧坐在会议室里的那几个人。

把 GitHub 当公司论坛用

#

这个"论坛"就是 GitHub。一个本为代码评审而生的平台，被 Alan 理直气壮地挪作他用。搭建过程简单得有点不好意思：

1. 注册一个 GitHub 账号。
2. 建一个没有代码的私有仓库（他们的叫"Topics"）。
3. 建一套标签体系，给对话分类。
4. 用 Issues 标签页：open 的是进行中的讨论，closed 的是已定的决策。

他们的 issue 已经超过 17,000 个。这意味着 17,000 场没必要开的会，而最让我心动的是：每一个决策为什么这么定，都留下了可搜索的历史。想推翻一个老决定？先去读读上次是哪些论据赢了。

什么时候开 issue

#

不是每个决策都配得上一个 issue。他们的过滤器是四个问题：谁会受影响？可逆性如何？急不急？做决定前还需要更多背景吗？

大体上，影响大、难回头的决策进论坛，其余留在 Slack。他们也用"单向门/双向门"的说法：单向决策（撤销代价太大，他们举的例子是涨价）走完整的书面流程；双向决策（撤销便宜，最坏不过损失点精力）就不必兴师动众。

LOCI：谁干什么

#

每场讨论都按 LOCI 模型分配角色——Lead、Owner、Consulted、Informed。

Lead 对决策的成败负责，确保决策背后的来龙去脉在团队里讲清楚。他会在讨论开头说明自己想介入到什么程度，之后信任 Owner、为团队的产出兜底，只在强烈反对时才出声。每场讨论只有一个 Lead。

Owner 拍最终的板，推着项目往目标走。他要保证每个参与者知情并按时发言，调查问题、收集答案、跟进进展，负责开 issue 也负责关 issue，最后做出决定并公之于众。碰到自己迈不过去的坎，就去找 Lead。每个决策也只有一个 Owner。

Consulted 是那些意见真正影响权衡的人。他们必须按时发言——哪怕只是一句"我没有补充"——如果认为决策错得离谱，就要拉响警报，最坏的情况上报给 Lead。Alan 把这个群体控制在六人左右，再多，进度就要付出代价。

Informed 通常在决策定了之后才被告知。沟通是单向的，不需要他们做任何事。通知谁，由 Owner 根据影响范围来定。

这是针对单个决策的做法。放到整个项目上，我会把同样的事一次性写成一份项目沟通计划：谁需要知道什么、多久一次、由谁来告诉他们。

一个 issue 的解剖图

#

每个 issue 都用同一套模板。这既能磨利思路，也悄悄教会了初级同事怎么拆解问题：

• 范围——讨论的"为什么"，其中最被低估的一行是"这个 issue 不讨论……"
• 背景和材料——链接到之前的讨论和文档
• LOCI——谁是 Lead、Owner、Consulted、Informed
• 截止时间——发言截止日、issue 关闭日、必须拿出方案的日期
• 方案提议——推荐一个方案，或列几个供选择
• 提问——把具体的问题抛给具体的人，去证实或推翻具体的假设，免得 issue 变成一只"漂流瓶"

让讨论不拖沓的写作规矩

#

文字辩论拖起来一点不比口头的差，所以他们有规矩。首先是简洁——他们引用布瓦洛：“构思清晰的内容，表达也清晰。“写不简单，说明你自己还没想清楚。其次，每写一段都做一次"那又怎样？“测试：如果你这条评论的言下之意不明显，就把它写明白。

对 Owner 来说，开完 issue 之后的经营同样重要。让讨论始终对准那个"百万美元问题”——真正要紧的那一个卡点——别让它溶解在细节的海洋里；定期总结哪些已达成一致、哪些还悬着；Slack 提醒留作最后手段，只用于发言逾期或真正紧急的情况。

Owner 还可以隐藏那些没有推动对话的评论。另外，标题、脚注、表格、键盘快捷键这些 GitHub 排版功能，默认人人都要会用——在书面世界里，形式和内容几乎同等重要。

不搞共识，不养观众

#

有两条规矩防止这套系统沦为"委员会决策”。

第一，Owner 以 Alan 所说的"开明专制者"身份做决定。他去调研新想法、衡量风险、分析数据、追问同事——但不寻求共识，也没义务采纳听到的每一条建议。Alan 说得很直白：公司不是民主制。人人都是股东，公司利益排在团队和个人之前。当然他们也不要孤立、仓促、拍脑袋的决定。当 Owner 对这一注有了足够把握，就拍板，大家一起试；等影响逐渐清晰，再回头复盘，看下次怎么做得更好。

第二，控制参与人数。贝佐斯的"两个披萨"规则在异步世界照样成立：人越多，每个人的贡献越少。超过六个参与者，旁观者效应就开始冒头，参与质量随之下滑。通知也遵循同样的哲学，渐进式来——Alan 信任每个人都配置好了自己的 GitHub 通知（Settings 里把"Participating"和"Watching"下的"Web and Mobile"勾上），所以 issue 提问区里的 @ 能省则省。

我打算带走什么

#

一场会议的内容，永远没法向缺席的人复述完整；但一份写下来的决策，谁都能读。Alan 自己也说，这不是最好的、更不是唯一的方案，只是最合他们脾性的那一个：打断变少了，旁观者效应变淡了，做决策时能先退一步，事实也都写在纸面上。我不打算把团队的每个决定都搬进 GitHub issue，但下面这个模板，马上就进我们的仓库。

做成 GitHub issue 模板

#

把下面这段存成 .github/ISSUE_TEMPLATE/decision.md，放进你拿来当论坛的那个仓库，以后每次有人新建 issue，GitHub 都会把它列出来供选择。各个部分是 Alan 的，LOCI 那几行和标签是我加的。

---
name: 决策
about: 提出一个决策，以书面形式收集意见
title: "[决策] "
labels: decision
---

## 范围
- 这个 issue 的目标是……
- 这个 issue **不**讨论……

## 我为什么开这个 issue

## LOCI
- Lead：
- Owner：
- Consulted：
- Informed：

## 时间线
- 发言截止日：
- 决策截止日：

## 背景和材料

## 方案提议

## 提问

GitHub Issues 还是 GitHub Projects？

#

如果你在更大的范围里考虑拿 GitHub 做项目管理，这两样东西分工不同。Issues 承载讨论，关闭之后承载的就是决策本身。GitHub Project 则是铺在一个或多个仓库的 issue 之上的看板或表格，状态、负责人、截止日期这些字段都可以自己定义。像 Alan 这样的决策论坛，标签加上 issue 列表就够了。等你想把所有还没定的决策放在一个屏幕上、按必须拍板的日期排好序，或者开始在同一个地方跟踪交付工作时，再加一个 Project。大多数团队最后都是走到这一步，两样一起用。

想法本身

#

韩国的路边摊没有地址。布帐马车想支在哪就支在哪，除非你本来就知道那个摊位，否则在网上根本搜不到。我们的应用做的事，就是把摊位真真正正地标到地图上。摊主受益，深夜到处找辣炒年糕的人也受益。

那个周末

#

活动由 Lunit Global 主办，场地也是他们的办公室。各种背景的队伍聚在一起，大部分人通宵干活，主办方把一切安排得井井有条。就是那种一抬头发现已经凌晨四点的活动。

我们的队伍

#

队友是 Sharon Levy、Jonothan Sue、我，还有 Tiaan van der Riel。每个人的长处都不一样，所以分工毫无摩擦。路演能打动评委，我想是因为这个问题根本不需要解释——“路边摊在网上是隐形的"这句话一说出口，答案自己就冒出来了。

接下来

#

我们正在准备把这个应用上架应用商店。它起于一个周末项目，但它要解决的问题足够真实，现在停手反而觉得可惜。

如果这是你的第一次黑客马拉松

#

如果你还没参加过黑客马拉松，我很推荐去试一次。和素不相识的人快速做出点东西，顺便看清自己在压力下到底是什么样，偶尔还能带走一个值得继续做的产品。最坏的结果，也不过是一个零食管够的周末，外加一个没人要求你做的、但能跑起来的原型。

去之前，有几件事值得知道：

• 选一个一句话就能讲清楚的问题。评委要是花了第一分钟才弄明白问题是什么，你的解决方案他们就听不进去了。
• 尽早分工，最好在第一个小时内定好：谁写代码，谁做设计，谁负责路演。拖到凌晨两点再商量，代价大得多。
• 先把演示路径做出来。台上要展示的那一条流程先从头到尾跑通，再往上加别的东西。
• 路演要带着真实的 demo 大声排练，至少两遍。路演几乎总会比你预想的长。
• 睡一会儿。哪怕只睡两三个小时，第二天早上的判断和路演都会明显更好。

链接：

#

https://lnkd.in/drMXUgPB