2026 年 3 月走完了 HF 的 frontend loop。没看到多少针对 FE 的流程分享，所以写下我的经历。
这是 Hub 产品团队的岗位，也就是 huggingface.co 平台本身。你用来浏览 models、datasets、spaces 的 UI。所以是实打实的产品前端工作，不是 ML tooling。
recruiter screen（30 分钟） 挺标准的。他们想了解我的 react 熟练度、有没有做过大规模 SPA、以及性能优化经验。提到他们的代码库 TypeScript 比较重。
technical screen（75 分钟） 分两部分。第一部分：react + typescript 编码题。我需要做一个 search-as-you-type 组件，包含 debouncing、完善的 loading/error 状态、以及键盘无障碍（回车、esc 清空）。不算刁钻，但他们对无障碍这块特别在意，这是我没预期到的。第二部分：性能调试。他们给了一个模拟的 profiler 输出，让我找出是什么导致 re-render，并提出修复方案。会聊到 react 的 reconciliation 行为，以及什么时候用 useMemo/useCallback，什么时候只是拆组件就够了。
UI/product design sense（45 分钟） 这轮让我意外。不是纯 coding，而是围绕一个功能的讨论。他们讲了一个假设的 model card 页面改动，让我从用户体验和实现角度 critique。他们想知道我怎么理解前端应该负责的边界，以及哪些应该由 design system 去约束。
system design（45 分钟） 设计一个用于编辑 model cards 的实时协作功能。不算特别深，但他们想看到你理解 optimistic updates、冲突解决策略、以及 SSE vs websockets。我觉得很多 FE 候选人会敷衍这一轮：准备好真的往深聊。
behavioral（45 分钟） 常规情景题。他们问到：和一个节奏比我慢的后端团队合作怎么办；以及我什么时候在「快点上线」和「正确上线」之间做过取舍。
timeline：从开始到 offer 3.5 周。无障碍真的很重要：如果你对 WCAG 基础和 ARIA 不熟，screen 前一定要补一补。
5 条回复
apm_aisha (Primly starter)
这个 UI/product design sense 的一轮挺有意思的，更偏 PM 相邻。你感觉他们是想看你有没有设计观点，还是更想测试你会不会对烂设计提出质疑？
由 AI 翻译，查看原文
backend_bekah (Primly starter)
用「real-time collaboration for model card editing」当 system design 题，暗戳戳地很难。你有讲 CRDTs 吗，还是保持在更高层？
由 AI 翻译，查看原文
frontend_fran (Primly starter)
我简单提了一下 CRDTs，但没实现。大部分时间我们都在讲更简单的基于锁的方案，以及什么时候才需要升级到 CRDT。我觉得他们主要是在测你是否知道这片 tradeoff 空间是存在的。
由 AI 翻译，查看原文
corp_refugee (Primly starter)
他们对无障碍（accessibility）的关注挺符合预期。我见过 HF 的职位描述会专门提 a11y。这是他们看起来真的在意的点之一，不像大多数公司写在 JD 里但面试从来不问。
由 AI 翻译，查看原文
Primly Team
One stage people often underestimate in frontend loops at this level is the “narrated debugging” piece. It is not just whether you can land on the fix, but whether you can build a clear hypothesis chain under time pressure: what signal you see, what you suspect, what you’d measure next, and how you’d validate the result.
A useful structure is: (1) restate the symptom and constraints, (2) list 2 to 3 likely causes, (3) pick the cheapest check first (React DevTools, why-did-you-render style reasoning, flamegraph cues), (4) propose a fix with a tradeoff note (memoization vs component boundaries vs state location), and (5) define what “fixed” means (CPU, rerenders, input latency, a11y regressions). Candidates often jump straight to useMemo/useCallback without proving the cause.
In your process, what ended up being the most surprising “signal” that revealed the real root cause?