Accenture Data Engineer Interview Questions 2026: SQL, Spark, Data Modelling and Cloud (30 Q&A)

Accenture's data engineering openings in India come mostly from client migrations: on-premise warehouses moving to Databricks, Snowflake, Synapse or Redshift, and batch pipelines being rebuilt on Spark. The interview reflects that. Candidates report being judged on PySpark, SQL and data-warehouse fundamentals first, then on cloud services and how they handled real pipeline problems. This page covers the 2026 process, what the panel tests, and 30 questions with sample answers for candidates from one to about six years, with notes for freshers moving into data roles.

How the Accenture data engineer process works in 2026

As of September 2026, candidate reports on Glassdoor, Exponent and 2026 preparation guides describe the following.

Screening. Resume shortlisting against the job description, which usually names a primary stack such as PySpark plus Azure Databricks, or SQL plus AWS Glue. Some drives add a HackerEarth or Accenture-portal assessment with SQL and Python questions.

Technical round 1 (about an hour). Opens with a brief discussion of your current work, highest qualification and self-introduction, then moves into PySpark, SQL and data-warehousing concepts. Reported questions include how a data engineer differs from a data analyst, the architecture of your most recent project, what Medallion architecture is, and how you implemented change data capture (CDC). SQL joins and window functions, and how you would optimise a slow query, are asked in nearly every report.

Technical round 2 (when held). Deeper: pipeline design for a given scenario, Spark performance, cloud services, data quality and orchestration. Senior openings may replace this with a client or delivery-manager round.

HR. Notice period, CTC, location, shift flexibility, reasons for switching. Short but decisive on flexibility.

Freshers. Fresher data roles at Accenture typically come through the general fresher assessments and are then trained; the SQL and modelling groups below are the ones to master first.

Compensation. Not published on the job posts and dependent on level, city and skill. Confirm the level in the offer and compare it for that level; third-party salary sites give wide ranges and should not anchor a negotiation.

What the Accenture data engineering interviewer is testing

• SQL you can write on a whiteboard. Joins, aggregation, window functions, CTEs, and reasoning about performance.
• Spark understanding, not just API recall. Lazy evaluation, shuffles, partitions, joins, caching, skew.
• Warehouse and modelling basics. Star schema, slowly changing dimensions, Medallion layers, CDC.
• A cloud stack in depth. The services on your resume, how they connect, and what they cost.
• Pipeline judgement. Idempotency, backfills, late data, data quality checks, orchestration.
• Delivery. How you handled a failed nightly load at 6 am and told the client.

30 Accenture data engineer interview questions with sample answers

SQL

1. Write a query for the top five customers by revenue in the last 30 days.

"SELECT customer_id, SUM(amount) AS revenue FROM orders WHERE order_date >= CURRENT_DATE - INTERVAL '30 days' GROUP BY customer_id ORDER BY revenue DESC LIMIT 5; I would ask whether refunds should be subtracted and whether 'last 30 days' includes today, because both change the result. If ties matter, DENSE_RANK in a CTE instead of LIMIT."

2. Explain the difference between RANK, DENSE_RANK and ROW_NUMBER with an example.

"For salaries 100, 100, 90: ROW_NUMBER gives 1, 2, 3; RANK gives 1, 1, 3; DENSE_RANK gives 1, 1, 2. I use ROW_NUMBER to pick one row per key in deduplication, DENSE_RANK for 'top n distinct values', and RANK when the gap itself is meaningful."

3. Find duplicate records in a table and delete all but the latest.

"Identify with GROUP BY key HAVING COUNT(*) > 1. To delete, use a CTE with ROW_NUMBER() OVER (PARTITION BY key ORDER BY updated_at DESC) AS rn and delete where rn > 1. On a warehouse without DELETE from a CTE, I would rebuild the table with rn = 1 rows. I would take a backup or run in a transaction first."

4. Inner, left, right, full and anti joins. When does a left join silently produce wrong counts?

"When the right side has multiple matching rows, the left rows multiply; a count of customers becomes a count of customer-orders. Fix by aggregating the right side first or using EXISTS. An anti join, LEFT JOIN ... WHERE right.id IS NULL or NOT EXISTS, finds rows without a match; I use NOT EXISTS because NOT IN breaks on nulls."

5. Compute a seven-day moving average of daily sales.

"SELECT day, AVG(sales) OVER (ORDER BY day ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS ma7 FROM daily_sales; I would mention that missing days need to be filled first, otherwise 'seven rows' is not seven days, and that RANGE with an interval handles that on databases that support it."

6. A query on a 200-million-row table takes ten minutes. How do you approach it?

"Read the execution plan for full scans, spills and skewed joins. Check partition pruning: is the date filter hitting the partition column? Check the join order and whether a small dimension can be broadcast. Replace SELECT * with needed columns, push filters before joins, and consider a materialised aggregate if the query runs daily. Measure after each change rather than guessing."

7. What is a CTE, and when would you use a temporary table instead?

"A CTE is a named subquery for readability and recursion. It is not necessarily materialised, so a CTE referenced three times may run three times. For a heavy intermediate result used repeatedly, or one I want to index, I use a temporary table."

8. Write SQL to pivot monthly sales per product into columns.

"Conditional aggregation: SUM(CASE WHEN month = 'Jan' THEN sales END) AS jan, and so on, grouped by product. Databases with PIVOT syntax can do it directly, but conditional aggregation is portable and what I write in Spark SQL too."

Spark and PySpark

9. Explain lazy evaluation, transformations and actions in Spark.

"Transformations like filter, select and join build a logical plan and do not run. Actions like count, collect and write trigger execution. Lazy evaluation lets Catalyst optimise the whole plan, for example pushing filters below joins. The practical consequence is that an expensive DataFrame reused in two actions is computed twice unless cached."

10. What is a shuffle, and which operations cause it?

"A shuffle redistributes data across partitions by key, writing to disk and moving over the network; it is the most expensive thing in a Spark job. groupBy, join on non-co-partitioned data, distinct, repartition and orderBy cause it. I reduce shuffles with broadcast joins for small tables, pre-aggregation, and sensible partitioning on the join key."

11. How do you handle data skew in a join?

"Identify the hot keys from a count per key. Options: broadcast the small side if it fits; salt the skewed key by appending a random suffix on the large side and exploding the small side to match; or enable adaptive query execution with skew join handling in Spark 3. I choose based on the size of the small side and whether the skew is a few keys or many."

12. Difference between repartition and coalesce, and how do you choose the number of partitions?

"repartition does a full shuffle to any number of partitions; coalesce merges existing partitions without a shuffle, only reducing. Target partition sizes around 128 MB, roughly two to three partitions per core, and avoid thousands of tiny output files by coalescing before write."

13. When do you cache a DataFrame, and what is the risk?

"When it is reused by several actions or iterations, such as a cleaned base table feeding three aggregations. The risk is memory pressure causing eviction or spills, and stale caches if the source changes. I unpersist when done and check the storage tab in the Spark UI."

14. Write PySpark to deduplicate records keeping the latest by updated_at per id.

"from pyspark.sql import Window, functions as F; w = Window.partitionBy("id").orderBy(F.col("updated_at").desc()); df.withColumn("rn", F.row_number().over(w)).filter("rn = 1").drop("rn"). dropDuplicates would keep an arbitrary row, which is wrong when order matters."

15. Explain the Spark execution model: driver, executors, jobs, stages and tasks.

"The driver runs the main program and builds the plan; executors run tasks on partitions. An action creates a job, split into stages at shuffle boundaries, each stage into tasks, one per partition. When a job is slow, I look at which stage is slow in the Spark UI and whether one task is much longer than the rest, which points to skew."

16. How do you read a large CSV with a bad schema safely?

"Define the schema explicitly instead of inferring it, which avoids a full pass and wrong types. Use mode='PERMISSIVE' with a _corrupt_record column, or badRecordsPath on Databricks, to capture malformed rows instead of failing. Then convert to Parquet or Delta once so downstream jobs never read CSV again."

Data modelling and warehousing

17. How does a data engineer's role differ from a data analyst's? (a reported Accenture question)

"The engineer builds and operates the pipelines, models and platforms that make trustworthy data available; the analyst uses that data to answer business questions with SQL, dashboards and statistics. In practice the engineer owns ingestion, transformation, quality, performance and cost; the analyst owns interpretation. I have done both and I explain the difference by who gets paged when the nightly load fails."

18. What is Medallion architecture? (a reported Accenture question)

"A layered lakehouse design: Bronze holds raw ingested data as-is, Silver holds cleaned, deduplicated and conformed data, Gold holds aggregated, business-ready tables for reporting. Each layer is reproducible from the one below, which makes reprocessing and auditing simple. In Databricks the layers are usually Delta tables with separate schemas."

19. Explain star schema versus snowflake schema.

"Star: a fact table surrounded by denormalised dimension tables; simple joins, fast for BI. Snowflake: dimensions normalised into sub-dimensions; less redundancy, more joins. I default to star for reporting and snowflake only when a dimension is large and shared across many facts."

20. What are slowly changing dimensions? Implement Type 2.

"SCD handles attribute changes in dimensions. Type 1 overwrites, losing history; Type 2 adds a new row with effective_from, effective_to and is_current flags. Implementation: compare incoming rows with current rows on a hash of tracked columns, expire changed rows by setting effective_to and is_current = false, insert new versions. In Delta this is a MERGE with two WHEN MATCHED clauses."

21. How did you implement change data capture in your project? (a reported Accenture question)

Describe what you actually did. "Source was SQL Server; we enabled CDC tables and read the change tables incrementally by LSN into Bronze, then merged into Silver with MERGE keyed on primary key and operation type. Deletes were soft-deleted with a flag. For sources without native CDC we used a watermark column and a daily full reconciliation to catch missed updates." Mention Debezium or Kafka if you used them.

22. What is data partitioning in a warehouse, and how do you pick the partition column?

"Physically splitting a table by a column so queries scan only relevant parts. Pick a column that most queries filter on with moderate cardinality, usually a date. Partitioning on a high-cardinality column creates thousands of small files. In Delta I would also mention Z-ordering on a second frequent filter column."

Cloud, pipelines and quality

23. Walk me through your current pipeline architecture end to end. (asked in most reports)

Source, ingestion tool, storage layers, transformation engine, orchestration, serving layer, monitoring, and your part. "Sources: SAP and a Postgres app database. Azure Data Factory copies to ADLS Bronze nightly; Databricks jobs transform to Silver and Gold Delta tables; Synapse serverless exposes Gold to Power BI; ADF orchestrates with alerts to Teams. I own the Silver transformations and the data-quality checks." Practise this until it takes under three minutes.

24. How do you make a pipeline idempotent and support backfills?

"Write with overwrite by partition or MERGE on keys, never blind append. Parameterise the run date so a rerun for any day produces the same result. Keep raw data immutable so backfills reprocess from Bronze. Log run metadata so I can see what was processed and reprocess a range."

25. How do you handle late-arriving data?

"Watermarks in streaming to bound how late is accepted; in batch, reprocess a trailing window, for example the last three days, on each run. Gold aggregates are recomputed for affected partitions rather than the whole table. I would confirm with the business how late is acceptable, because that decides the window."

26. What data-quality checks do you run, and what happens when one fails?

"Row counts against source, null checks on keys, uniqueness on primary keys, referential checks between fact and dimension, and freshness. Implemented as Great Expectations suites or Delta constraints, run after each layer. A failed critical check stops the downstream load and alerts; a warning check logs and continues. Every check has an owner who is told."

27. Compare Azure Data Factory, Databricks and Synapse, or their AWS equivalents.

"ADF is orchestration and copy; Databricks is Spark compute for transformation and ML; Synapse is the warehouse and serving layer. On AWS: Step Functions or MWAA for orchestration, Glue or EMR for Spark, Redshift or Athena for serving. I pick Databricks for heavy transformations and the warehouse for BI queries, and I keep orchestration in one tool."

Scenarios and HR

28. A key metric dropped 15 percent this week. How do you diagnose it? (a reported Accenture question)

"First check the pipeline: did any load fail or partially load, did source counts change, did a schema change break a join. Then check the definition: did a filter or dimension mapping change in Gold. Only then treat it as a business change. I would compare row counts by day across Bronze, Silver and Gold to locate where the drop appears."

29. The nightly load failed at 3 am and the client's 9 am dashboard is empty. What do you do?

"Check the failure cause from the orchestrator logs; if it is transient, rerun the failed step with the same run date. If it is a data issue, decide with the lead whether to serve yesterday's data with a banner or delay. Tell the client before 9 am with a time for the next update, then write a root-cause note and add a check or retry so it does not repeat."

30. Why are you leaving, and what is your notice period and expected CTC?

"My current project is in support mode; I want to build lakehouse pipelines on Databricks, which this role is. Notice period 60 days, negotiable with leave adjustment; buyout allowed." For CTC, ask for the level and band first and then give a range.

Mistakes that get data engineering candidates rejected at Accenture

• Weak SQL. Window functions and joins by hand are non-negotiable; PySpark fluency does not excuse them.
• Spark API recall without the execution model. If you cannot explain a shuffle, you cannot fix a slow job.
• A pipeline you cannot draw. Every report mentions the architecture walkthrough; rehearse it.
• No data-quality or idempotency story. Accenture panels ask what happens when things fail.
• Cloud services named but not understood. Know what each one costs and where it sits.
• A vague notice period. Managers plan client allocations around it.

How to practise the Accenture data engineer round

The decisive answers in this interview are spoken explanations: your pipeline architecture, why a Spark job is slow, how you handled CDC. Writing them in notes does not prepare you for the follow-up questions; saying them aloud under pressure does.

In MockMate Practice, attach your resume and paste the Accenture data engineer job description, choose a technical round and run an adaptive session in the browser. The interviewer persona opens with your background and current project the way Accenture panels do, follows up on the SQL, Spark and cloud answers you give, and sets a SQL or PySpark problem you write in the built-in editor. The report shows each answer, response timing, coaching evidence and recurring weaknesses, with a recommended next practice. Eligible accounts get three free Practice starts of up to ten minutes each as of September 2026. Use MockMate Live assistance only in interviews or meetings where the organisation or interviewer permits it; Accenture selection rounds do not, so stay with Practice for this interview.

A one-week plan: two days of SQL by hand, especially window functions and deduplication; two days of Spark explanations spoken aloud (shuffle, skew, partitions, caching); one day drawing and narrating your pipeline; a Practice round, a report read, and a second round on the weakest group. For the broader Accenture process see the Accenture hub, and for the manager conversation the Accenture managerial round page.