我在 tech 做了 15 年，参加过很多轮 loop。GitHub 的 behavioral 有个很特别的点，我想专门提出来给正在准备的人。
多数公司都说自己重视文化契合，但最后问的还是那种你在哪都能听到的通用 STAR 格式题。GitHub 不太一样。他们的 behavioral 明显和他们作为 remote-first 公司真实的工作方式绑定。很多问题都在问：当你和任何人都不在同一个房间里时，你怎么工作？
我被问到的，或者同一场 loop 里别人被问到的（我们结束后对了下题）： "Tell me about a time you had to make a significant decision asynchronously, without being able to grab people for a quick meeting.（讲讲你曾经不得不在异步情况下做出一个重要决定的经历，当时你没法随手拉人开个快速会议。）" "Describe a situation where you disagreed with a team direction. How did you raise it, and what happened?（描述一次你不同意团队方向的情况。你是怎么提出的，后续发生了什么？）" "How do you create clarity for your team or stakeholders when the problem is still ambiguous?（当问题仍然很模糊时，你如何为你的团队或利益相关方建立清晰度？）" "Tell me about a time you had to onboard yourself onto a complex existing codebase.（讲讲你曾经需要让自己快速上手一个复杂既有代码库的一次经历。）"
这些问题背后的主线是：异步沟通、书面表达清晰度、自主判断力。GitHub 以异步沟通著称。他们内部做决策会大量依赖 GitHub issues 和 discussions。如果你拿不出在这种模式下工作得好的证据，你会很吃力。
我回答里比较加分的点是：细节。不是「我沟通很清晰」，而是「我写了一份两页的内部文档，三天内收到异步评论，我们没开任何会就对齐了」。他们要的是你确实这么干过的证明，不是你看过这种理念。
我会准备的内容： 3-4 个关于在没有直接汇报关系的情况下影响跨职能伙伴的故事 至少 1 个关于写过某个东西（proposal、design doc、incident retrospective），并且它改变了别人想法的故事 1 个关于接受尖锐反馈并付诸行动的故事
这依然是 behavioral 准备，但要贴合他们的运营模式。如果你的 STAR 故事没有体现 async-first 工作方式，通用故事不太够用。