我今年早些时候在 EY 面了一个 frontend engineer 角色。不是典型的咨询 analyst 轨道，而是他们内部产品团队的一个直接 software engineering 岗位。写下来是因为大多数 EY 面试帖都在讲咨询路线。
背景：团队是 digital products，做审计流程的内部工具。技术栈 React、TypeScript，还有一些 design-system 相关工作。我 4 年工作经验，面的是他们叫“Senior Associate”的级别。
轮次： Recruiter screen（挺标准） 和团队里一位 senior engineer 的技术电话面（45 分钟） Take-home 作业（deadline 比较灵活，我用了大概一周） Take-home debrief + behavioral 面试（同一天两段不同时间）
技术电话面： JavaScript 基础加 React 相关问题混合。比如：解释 virtual DOM，什么时候 reconciliation 会很贵。useEffect cleanup 怎么工作的。你会怎么在一个中等规模的 React app 里做 shared state，又不直接上 Redux。不是 leetcode，更像是在问“你写这段代码时到底懂不懂你在干什么”。
他们还问了 accessibility。不是泛泛而谈，而是 ARIA roles、键盘导航的 focus management，以及你有没有做过 screen-reader 兼容性审计。我做过，这点帮了不少。
Take-home 是做一个带筛选的 list 组件，加 pagination，连一个 mock API。他们给了 Figma 文件，希望你能比较贴近还原。写 tests 被说成加分项，但我感觉其实是默认期待的，不是可选。
Debrief 更不像“你做对了吗”，而是“带我走一遍你的决策”。我解释了我为什么选某种 state management，然后他们会 push back。那才是真正的面试：你能不能为自己的选择辩护，但又不变得 defensive。
整体流程比大多数 startup loop 慢，但也没那么混乱。更结构化，rubric 更清晰。如果你来自 startup，节奏确实不一样。