I interviewed for a frontend engineer role at EY earlier this year. Not a typical consulting analyst role, but a direct software engineering position on one of their internal product teams. Figured I'd write this up because most EY interview posts are about consulting tracks.
Context: the role was on a digital products team building internal tooling for audit workflows. React, TypeScript, some design-system work. 4 YOE me, interviewing for what they called a 'Senior Associate' level.
Rounds: Recruiter screen (pretty standard) Technical phone screen with a senior engineer on the team (45 min) Take-home assignment (deadline was flexible, I took about a week) Take-home debrief + behavioral interview (two separate slots on the same day)
The technical screen: mix of JavaScript fundamentals and React-specific questions. Things like: explain the virtual DOM and when reconciliation would be expensive. How does useEffect cleanup work. Describe how you'd handle shared state in a medium-sized React app without reaching for Redux. Not leetcode, more like 'do you actually understand what you're doing when you write this code.'
They also asked about accessibility. Not surface-level, actual questions about ARIA roles, focus management for keyboard navigation, and whether I'd audited a feature for screen-reader compatibility before. I had, which helped.
The take-home was building a small filtered list component with pagination, connecting to a mock API. They gave me a Figma file and expected me to match it reasonably well. Writing tests was mentioned as a plus but I got the sense it was expected, not optional.
The debrief was less 'did you do it right' and more 'walk me through your decisions.' I explained why I chose a certain state management approach and they pushed back. That's the real interview: can you defend your choices without getting defensive.
Process felt slower than most startup loops but less chaotic. More structured, clearer rubrics. If you're coming from startup land, the pace is different.