Question 1

Tell me about yourself and your experience.

Accepted Answer

**Situation**: I joined the data org when our pipelines were monolithic, causing 4+ hour delays and frequent outages affecting downstream dashboards and ML models.

**Task**: I was tasked with redesigning the data platform to support real-time decisioning while improving reliability and cost efficiency.

**Action**: I led a cross-functional team of 5 engineers to architect a medallion (Bronze/Silver/Gold) architecture on Delta Lake....

Question 2

What is the difference between groupByKey and reduceByKey in Spark?

Accepted Answer

**groupByKey()**: Shuffles all (key, value) pairs to group values per key. Transfers O(total_values) over the network. No local aggregation—you combine values afterward. High memory and network cost.

**reduceByKey(func)**: Performs local reduce (e.g., sum) on each partition before shuffle. Shuffles only O(unique_keys) aggregated values. Combines locally first, then across partitions.

**Architectural Logic (Why reduceByKey Wins)**: Shuffle is the bottleneck....

Question 3

What is the difference between narrow and wide transformations in Apache Spark? Explain with examples.

Accepted Answer

**Narrow transformations**: Each input partition maps to at most one output partition. No shuffle. Examples: map, filter, flatMap, mapPartitions.

**Wide transformations**: Require data from multiple input partitions to produce one output partition. Trigger shuffle. Examples: groupByKey, reduceByKey, join, distinct, repartition.

**Architectural Logic (Why This Matters)**: Spark pipelines narrow transformations and executes them in a single stage....

Question 4

What architecture are you following in your current project, and why?

Accepted Answer

**Section 1 — The Context (The 'Why')**
The primary challenge in choosing and justifying an architecture is alignment between technical complexity, operational cost, and business latency requirements. A naive monolithic pipeline fails when schema evolution hits, when a single component becomes a bottleneck, or when teams scale—causing coordination overhead and deployment risk....

Question 5

Handling Large-Scale Data Ingestion in AWS Pipelines

Accepted Answer

Architectural options: (1) Kinesis Streams/Firehose—streaming, auto-scale, batch to S3. (2) Glue—batch, scale DPUs. (3) DMS—DB migration, CDC. (4) S3 multipart—large files. (5) Shard/partition for parallelism. Scalability: Firehose for throughput; Glue for batch....

Question 6

Data Shuffling Causes and Techniques

Accepted Answer

**Causes**: groupBy, join create shuffle. Wide dependencies; skew (one partition huge). **Techniques**: Repartition; salting for skew; broadcast small tables. Filter early to reduce data. **Monitor**: Spark UI for shuffle read/write....

Question 7

Graph Databases - explain

Accepted Answer

**What**: Nodes (entities) + edges (relationships). Optimized for traversal. Neo4j, Neptune.

**Use Cases**: Social (friends), recommendations (user-item), fraud (transaction networks), knowledge graphs. Cypher: MATCH (a)-[:FRIEND]->(b).

**Trade-off**: Efficient multi-hop; flexible schema. Not ideal for heavy aggregations....

Question 8

Cloud Architecture - explain

Accepted Answer

**Section 1 — The Context (The 'Why')**
The primary challenge for this design in SQL is balancing scale, cost, and reliability. At scale, naive approaches fail: single points of failure cause cascades, schema evolution breaks consumers, and over-provisioning explodes cost. Failure modes include silent data loss from non-idempotent writes, cascading job failures from tight coupling, and operational burden from manual intervention....

Question 9

Converting SCD0 to SCD3

Accepted Answer

**Architectural Logic**: SCD0 (no history) to SCD3 (current + previous value) adds limited history without full Type 2 complexity. **Migration**: Add prev_value and effective_from columns; on update, shift current→previous before applying new value. **SQL**: `UPDATE dim SET prev_value = current_value, current_value = new_value, updated_at = NOW() WHERE key = X`. Or MERGE with equivalent logic....

Question 10

Facts and Dimension Tables Properties

Accepted Answer

**Fact properties**: Additive/semi-additive measures; clear grain; FKs to dims; time-series; often partitioned. **Dimension properties**: Descriptive; SCD Type 1 or 2; role-playing (same dim, different roles). **Grain is critical**: One row per order vs. per line-item = different measures. **Trade-off**: Mixed grain in one fact = wrong aggregations....

Nagarro Data Engineer Interview Questions

Companies asking these questions

All 22 Questions

More Interview Prep Guides

Get All Answers in PDF Format

Nagarro Data Engineer Interview Questions

Companies asking these questions

All 22 Questions

More Interview Prep Guides

Get All Answers in PDF Format