上个月刚走完 GitHub 的 product designer loop。我申的是他们某个 developer experience team 的 mid-level PD。写下来是因为 developer-tool 公司设计面试信息一直很少，而 GitHub 的流程也有点特别。
portfolio review 这一轮最关键。提前按这个去规划。
recruiter screen（25 分钟）：挺常规。问了我的背景、现在的角色、我偏好的产品方向。有个很具体的问题是「你设计面向高度技术用户的产品有多舒服」，考虑到他们用户主要是 developers，这个很合理。
portfolio presentation（60 分钟，2 个面试官）：我讲了 2 个 case study。他们大部分评估精力都在这轮。我观察到他们在意的点： 你的设计过程，而不只是最终产出。他们会追问比如「为什么选这个方向而不是另一个」以及「这个判断基于哪些用户研究」。 技术约束。他们想知道你是否理解设计背后的工程取舍。有一个面试官是 engineer，不是 designer，这是刻意安排的。 对开发者的共情。我一开始讲的是我重做一个面向开发者的 CLI onboarding flow 的案例，这个很对他们胃口。
design exercise（take-home，3 天）：为某个具体的 GitHub 功能设计更好的体验（给的是真实功能）。brief 很清楚。我把它当成真实项目来做：用户问题、约束、探索 3 个方向、我选择方向的理由、下一步要测什么。别只做得好看，把思考讲清楚。
cross-functional behavioral（45 分钟）：标准 behavioral 和产品思维混合。「你怎么处理和 PM 在 scope 上的分歧」，「讲讲你怎么在紧时间线下和工程师协作」，「你现在回头看会做不同决定的一次设计」。
GitHub 不同在哪：用户（developers）也很大程度上是内部受众。别人会挑战你对「什么容易做、什么难做」的假设。带着你对 developer experience 的真实观点来面。比如「我想过很多怎么降低 code review workflow 的摩擦」会比「我很爱 GitHub 的产品」强得多，后者基本没用。