KPMG Data Engineer Interview Guide

The failure mode that recurs in KPMG loops isn't technical weakness, it's overconfidence on scope. Candidates who dive immediately into implementation without asking what the client actually needs, or who propose greenfield architecture when the client is mid-migration with 3 years of legacy tooling, signal poor consulting instincts regardless of their SQL fluency. The pass behavior is the inverse: you treat every problem statement as incomplete information, you surface assumptions before you solve, and you size your answer to what's deliverable under real constraints. Given that 29 reports and a compressed ladder mean the interview pool here is smaller than at large product companies, the interviewers rely more heavily on behavioral read than quantitative screening, so your communication about tradeoffs carries more weight per minute than it would at a firm with a structured coding rubric.

KPMG's loop is designed to filter for engineers who can operate without a stable platform under them. At a product company, you inherit guardrails: a defined stack, an established data model, colleagues who built the system. At KPMG, each engagement drops you into a client's environment with partial documentation, inherited technical debt, and a delivery timeline set by contract. The interview is calibrated to surface whether you can make sound architectural calls under those conditions. Interviewers are watching for how you handle underspecified problems: do you ask the right scoping questions, do you flag risks clearly, do you build something defensible rather than something clever? The consulting context also means client communication is a real evaluation axis. Engineers who can translate pipeline decisions into business impact for a non-technical stakeholder score higher here than at most product-company loops.