finished the McKinsey frontend engineer interview process for one of their client-delivery tech roles and it was a mix of 'totally expected' and 'huh, didn't see that coming.'
context
the role was frontend engineer on a team that builds internal analytics tools for McKinsey's consulting engagements. so it's more product-like than what you might imagine at a consulting firm. React stack, TypeScript, some data visualization work.
the technical rounds
two technical rounds. the first was a live coding session in a shared editor. they gave me a prompt to build a small component from scratch: a sortable data table with filtering. vanilla React, no external libraries. they cared about: component structure, state management, edge cases (empty state, loading, error). i used functional components and hooks which was fine, no complaints. they asked me to explain trade-offs if i'd reached for a library instead.
the second technical round was more architectural. how do you manage client state vs server state? how do you think about performance for a dashboard that's rendering 10k rows? when would you reach for a virtual list? i didn't get to write code, just talked through approaches. knowing the difference between React Query, SWR, Zustand, and Redux and when you'd use each was relevant.
the non-technical stuff
this is where McKinsey differs from product companies. they asked a version of 'tell me about a time you had to explain a complex technical decision to a non-technical stakeholder.' multiple times across rounds. the consulting context means your engineers sometimes present to clients. they want to know you can communicate. they also asked about a time i had to push back on a design direction. PEI format.
there was no case component in my loop, which surprised me given what others report. maybe it's role-dependent.
overall
the technical bar felt like a strong mid-level SWE interview at a product company, maybe slightly lower on the pure algo side and higher on architecture + communication. if you're a frontend person who can hold a conversation about trade-offs and explain your reasoning clearly, you'll be fine. the consulting-firm expectation of 'client-ready communication' is real though.