KPMG India Data Engineer Interview: Questions & Prep (2026)

KPMG India is one of the Big Four professional services firms, running data and analytics practices across advisory, tax, and audit engagements. As of July 2026, KPMG India has 233 open Data Engineer positions nationwide, making it one of the most active hirers in this space. The interview process typically spans 2-3 rounds. Candidates report a mix of technical questions covering SQL, Python, and cloud tools, alongside behavioural questions that probe how you handle client-facing situations and ambiguous requirements.

Because KPMG serves regulated industries like banking, insurance, and healthcare, interviewers pay close attention to data governance, data quality, and your ability to communicate technical work clearly to non-technical clients. Coming prepared on both the engineering side and the consulting mindset will set you apart from candidates who only drill algorithms.

Market salary ranges for Data Engineers in India (knok jobradar, July 2026) give useful context for offer expectations:

Actual KPMG India offers fall within this broader market range and vary by practice area, internal grade, and city.

These questions come up frequently in KPMG India Data Engineer interviews, based on candidate reports and the nature of KPMG's consulting work.

1. Walk me through an ETL or ELT pipeline you built end to end. What data sources did you pull from, and which tools did you use?

1. You find that a significant portion of incoming records have null values in a key field. How do you handle this before loading to the warehouse?

1. Explain the difference between a star schema and a snowflake schema. Give an example of when you would choose each.

1. KPMG works across cloud platforms. Describe a real project where you used Azure, AWS, or GCP for data engineering work.

1. How would you optimise a SQL query that is running slowly on a very large table?

1. Describe a situation where you had to explain your pipeline design to a business stakeholder with no technical background.

1. How do you handle late-arriving data in a batch or streaming pipeline?

1. What steps do you take to maintain data lineage and ensure data quality end to end in a project?

1. KPMG handles sensitive data for clients in banking, insurance, and government sectors. How have you dealt with PII or confidential data in your pipelines?

1. Describe your experience with orchestration tools like Apache Airflow or Azure Data Factory. How did you schedule and monitor jobs?

1. How would you design a pipeline for a client whose source data arrives in multiple formats from several different vendor systems?

1. Tell me about a time your pipeline failed in production. What happened, what did you do, and what did you change afterwards?

Q: Tell me about a time your pipeline failed in production. What happened, what did you do, and what did you change afterwards?

*Situation:* I was owning a daily ingestion pipeline that pulled transaction data from a third-party payment API and loaded it into our data warehouse. One morning the job failed silently: no alerts fired, and the downstream reporting team only noticed when their dashboard showed stale numbers.

*Task:* I needed to find the root cause quickly, restore the missing data, and make sure silent failures could not happen again.

*Action:* I checked the logs and found the third-party API had changed a field name in its response without notice. Because the pipeline had no schema validation at ingestion, it had been loading empty records. I wrote a backfill script to re-pull and reload the affected data, added schema validation at the ingestion layer, and configured Airflow alerts so any future failure would notify the team within minutes.

*Result:* The downstream team had corrected data within four hours. We rolled out schema contracts to all external integrations after that, and the pattern of silent failures stopped completely.

---

Q: Describe a situation where you had to explain your pipeline design to a business stakeholder with no technical background.

*Situation:* I was building a centralised data platform for a retail client. The project sponsor was the CFO, who was funding the work but had no data or engineering background. She kept asking why 'just moving data' was taking so long and was losing confidence in the timeline.

*Task:* I needed to rebuild her confidence by making the architecture understandable to her without oversimplifying the real complexity.

*Action:* I drew a diagram comparing the pipeline to a supply chain: raw data came in like raw materials, quality checks worked like factory floor inspection, and the warehouse was the finished goods store that reports pulled from. I highlighted risks we had already handled and the one that was still open. I avoided jargon and tied each pipeline stage to a business outcome she cared about.

*Result:* She told me afterwards that she finally understood what we were building. She approved the additional testing time we had been requesting, and the project launched on the revised schedule without issues.

---

Q: How would you design a pipeline for a client whose source data arrives in multiple formats from several different vendor systems?

*Situation:* I faced almost exactly this at a previous role supporting a healthcare analytics client. Data arrived from an EHR system in HL7 format, a claims processor in CSV, and a lab vendor via a JSON API, each on a different schedule with different field naming conventions.

*Task:* I needed to build a unified ingestion layer that handled all three sources reliably and produced a clean, consistent schema in the warehouse.

*Action:* I built a separate ingestion module for each source. Each module was responsible only for pulling data and converting it to a standard internal Parquet format. A single transformation layer downstream applied business rules and merged the data. Apache Airflow orchestrated all three ingestion jobs with independent retries, so a failure in one source did not block the others.

*Result:* The pipeline ran reliably for over a year with minimal intervention. When the lab vendor updated their API, only one module needed to change. The modular design made the whole system far easier to maintain.

STAR for behavioural questions (any 'tell me about a time' or 'describe a situation' prompt): open with the Situation in one or two sentences, state your Task (what you personally were responsible for), walk through your Action with enough technical detail to show depth, and close with a concrete Result. Avoid vague endings like 'it went well.' Aim for something measurable or at least clearly observable.

Explain-Constrain-Choose for design and architecture questions (any 'how would you design' or 'which tool would you pick' prompt): first Explain what you understand about the problem and its scale, then name the Constraints (data volume, latency requirements, team skills, compliance needs, budget), and finally Choose an approach and explain why those constraints drove the choice. This shows structured thinking rather than jumping straight to a favourite tool.

Diagnose-Fix-Prevent for troubleshooting questions (any 'what do you do when X fails' prompt): walk through how you Diagnose the issue (logs, monitoring, narrowing the scope), what you Fix immediately to restore service, and what you Prevent by changing process or code so it does not recur. KPMG interviewers want to see that you think beyond the immediate fix and build lasting reliability into your systems.

Technical depth in the right tools: Expect strong focus on SQL (window functions, CTEs, query optimisation), Python for data transformation, and at least one major cloud data stack. Knowing the internals of the tools you list on your resume matters more here than breadth across many tools you have barely touched.

Client communication skills: KPMG is a consulting firm. You will regularly present your work to clients who are not engineers. Interviewers listen for whether you can explain technical decisions in plain language without losing accuracy. Candidates who can only talk to other engineers are a risk in a consulting setting.

Data governance and compliance awareness: Many KPMG clients are in regulated sectors. Showing that you understand data lineage, PII handling, role-based access control, and audit trails will set you apart from candidates who focus only on ingestion and transformation logic.

Problem-solving approach over quick answers: Interviewers want to see how you think through ambiguous problems, not just whether you know the answer. Walk through your reasoning aloud even when the answer seems obvious. Asking clarifying questions before jumping to a solution is seen as a strength here, not a weakness.

Ownership and proactive communication: Consulting project timelines are tight and clients expect reliability. Interviewers look for candidates who take ownership of deliverables, flag risks early, and follow through without needing constant direction.

Week 1: Sharpen technical fundamentals

Start with SQL. Practise window functions (ROW_NUMBER, RANK, LAG, LEAD), query optimisation using execution plans and indexing strategies, and complex multi-table joins. Move to Python: focus on clean transformation logic, pandas for mid-size data operations, and PySpark basics. Aim for readable, testable functions rather than clever one-liners.

Week 2: Cloud and pipeline design

Go deep on whichever cloud platform aligns with your experience. If Azure, focus on Data Factory, Synapse Analytics, and Azure Data Lake Storage. If AWS, focus on Glue, Redshift, and S3. Practise designing end-to-end pipeline architectures on paper, including how you handle failures, retries, schema drift, and late-arriving data. Review Apache Airflow concepts: DAGs, task dependencies, and failure alerting.

Week 3: KPMG context and behavioural prep

Read about KPMG India's data and analytics practice to understand the types of clients and projects you might work on. Prepare STAR stories from your own experience covering these themes: a technical failure and recovery, a process you improved significantly, a time you collaborated with a non-technical stakeholder, and a data quality problem you solved. Practise answering these out loud, not just in your head. Hearing yourself reveals gaps that reading notes does not.

The day before: Review the job description for any specific tools mentioned. Write down two or three thoughtful questions to ask your interviewer about the team's current projects and tech stack.

If you are actively applying while you prepare, knok checks 150+ job sites nightly, applies to matching Data Engineer roles, and messages HR for you so the application side does not slow down your prep.

1. Treating it like a product company interview: KPMG is a consulting firm. Candidates who prepare only for DSA problems and ignore pipeline design, data governance, and stakeholder communication typically struggle in later rounds.

1. Giving vague behavioural answers: Saying 'I worked on a data project and it went well' does not show your thinking or your impact. Prepare specific STAR stories with concrete, observable outcomes.

1. Not knowing your listed tools in depth: Interviewers at KPMG drill into whatever you have on your resume. If you list Azure Data Factory or Apache Airflow, expect detailed follow-up questions. Only claim what you can defend at least two levels deep.

1. Skipping data quality and lineage topics in preparation: These come up often because KPMG serves regulated industries. Many candidates focus only on ingestion and transformation logic and miss this area entirely.

1. Saying you have no questions at the end: Candidates with no questions for the interviewer miss a chance to show genuine curiosity about the role and the team. Prepare thoughtful questions about the client projects and the tech stack in use.

1. Overselling tools you have only briefly touched: Interviewers will probe. It is far better to say 'I have used it on one project and know the basics' than to overstate your depth and get caught out mid-conversation.