刚结束一轮 Datadog frontend SWE 流程，想分享一下整体形状，因为我原本以为就是标准 React/JS，结果遇到了比预期更偏基础设施的问题。不坏，只是不同。
我 4 YOE frontend eng，主要是 React + TypeScript，Bay Area。申请的是他们某个产品可视化团队的 senior frontend 岗。
初始 technical screen 后，还有 4 轮。
Technical screen：45 分钟。一道 JS/TS coding（medium 难度，要实现一个自定义 hook，涉及一些比较 tricky 的 async 行为）+ 一段关于 state management 模式的讨论。我的感觉是要深入理解 hooks，不只是会用 useState/useEffect。他们追问了 useReducer 以及你如何处理复杂的 derived state。
On-site 第 1 轮：Frontend systems。他们让我讲我会如何做一个实时 metrics dashboard。不只是「what components would you use（你会用哪些组件）」而是：怎么处理 websocket 连接，怎么平衡更新频率和 DOM thrash，怎么在 UI 里对 time-series 数据做分页。这是一个很 Datadog 风格的问题，我应该准备得更充分。要具体想性能约束。
第 2 轮：Coding。实现一个带 debounce 的搜索输入，并能处理乱序返回的 API 响应。经典题，但他们要完整实现：TypeScript、error 状态、loading 状态、unmount 时 cleanup。我写得很顺。
第 3 轮：Accessibility 和 design system。挺出乎意料。他们问了 ARIA、键盘导航模式、以及我如何做组件库的决策。如果你没认真做过 a11y，花一周补一下。
第 4 轮：Behavioral。标准题。重点在你如何 push back 一个设计决策、如何应对模糊性、或如何处理一次和 frontend 相关的线上事故。
整个过程的感觉是：他们想要在意正确性和性能的 frontend engineers，而不是只追求把 UI 快速发出去的人。结合他们的产品本质上是「展示海量数据但不把浏览器搞崩」，也很合理。