我上个季度面了 Square（senior engineering 岗），今年也辅导了几个走完整套流程的人。Square 的 behavioral 面比我见过的大多数公司都更结构化，他们很明显是在对照自己的 operating principles 来评估。
Square 会讲自己「customer obsessed」和「moving with urgency」。这在面试里不是口号。behavioral 题基本就是：给我一个例子，证明你在压力下也能按这些原则做事。
我自己被问到、或听别人反馈的题： "Tell me about a time you had to make a decision with incomplete data and something significant was at stake.（讲讲你在信息不完整、而且影响很重大的情况下，必须做决策的一次经历。）" "Walk me through a project where you disagreed with the direction but had to execute anyway. How did you handle it?（带我梳理一个你不认同方向但还是必须执行的项目。你是怎么处理的？）" "Describe a time you failed to ship something on time. What happened and what would you do differently?（描述一次你没能按时交付的经历。发生了什么？你会怎么做得不一样？）" "Tell me about a situation where you had to push back on a product requirement for technical or ethical reasons.（讲讲一次你因为技术或伦理原因，必须对产品需求提出反对意见的情况。）" "When have you had to communicate a complex technical tradeoff to a non-technical stakeholder?（你什么时候需要把复杂的技术取舍讲给非技术干系人听？）"
我观察到的几个规律：
他们很爱问失败。不是「give me a challenge you overcame（给我讲一个你克服过的挑战。）」那种，而是真的失败。要具体，并且把结果承担下来。那些把失败题硬拗成「谦虚炫耀」成功故事的候选人，评分会更低。
跨团队协作被反复提到，尤其因为 Square（现在是 Block）有多个产品面。他们想知道你能跨 org 合作。
速度和质量的取舍是常见主题。支付系统不能出 bug，但交付也很重要。他们想看到你是有意识地承受这种张力，而不是假装它不存在。
STAR 方法结构上完全够用。只是要确保你的 T（Task）足够具体，你的 A（Action）细节足够可信。很多候选人会快速带过 S 和 T，急着讲自己做了什么。但面试官很看重上下文，因为那能显示你真的理解你所处的情境。