This is a behavioral + technical screen. The interviewer is checking three things at once: communication (can you explain ETL clearly and connect it to real projects), technical depth (do you understand schema handling and data integrity), and ownership (can you debug a real failure and prevent it from recurring). Because the role is at a bank, lean on data correctness, reconciliation, auditability, and reliability — these matter more in a financial-data context than raw throughput. A good overall structure for the whole screen: - 30-90 second self-introduction - 2-3 relevant skills from your master's program, translated into capabilities (not course names) - A systematic answer for handling schema differences - A multi-stage framework for data integrity - One STAR-format story for a real pipeline difficulty --- **1. Self-introduction** Use a present-past-future format (60-90 seconds): - Present: what you are studying now and your focus (data engineering, analytics engineering, backend data systems). - Past: the most relevant projects, tools, and impact — SQL, Python, ETL, orchestration, cloud, data modeling. - Future: why this internship fits your goal of building reliable, scalable data platforms. Example: "I am currently pursuing a master's focused on data systems, where I work with databases, distributed processing, and cloud data pipelines. Before this I built ETL workflows in SQL and Python on a few projects. I am drawn to data engineering because I enjoy turning messy source data into reliable datasets that analysts and applications can trust. Long term, I want to design scalable, well-governed data platforms." --- **2. New skills from the master's program** Don't just list course names — translate coursework into practical capabilities, and connect each to business value. Good themes: - Advanced SQL and dimensional / data modeling - Python for data processing and automation - Distributed systems and big-data tools such as Spark - Workflow orchestration such as Airflow - Cloud storage and compute (AWS / Azure / GCP) - Testing, version control, reproducibility, and production monitoring Example: "My program strengthened both my technical depth and my engineering discipline. I improved my SQL and Python, but more importantly I learned to reason about data systems at scale — schema design, partitioning, orchestration, and quality validation — and to build pipelines that are reproducible, monitored, and maintainable in production." --- **3. Handling schema differences in ETL** This is really a schema-evolution and data-contract question. A strong answer covers both prevention and recovery. Step 1 — Profile the source(s): column names, types, nullability, units, timestamp formats, nested structure. Identify breaking differences (int vs string, UTC vs local time, optional vs required). Step 2 — Define a canonical target schema / contract: standard naming, data types, primary/business keys, and business definitions so downstream consumers have one consistent model. Step 3 — Handle differences explicitly: renamed columns, missing columns, new optional columns, type changes, nullability changes. Apply safe casting and validation; standardize timestamps, currencies, enums, and encoding. Step 4 — Route bad records to a quarantine table rather than silently dropping or corrupting them. Step 5 — Plan for schema evolution: version schemas, prefer backward-compatible changes, separate required from optional fields, and use schema registries / data contracts in complex systems. Step 6 — Monitor and alert for unexpected new/dropped columns or type drift: fail fast on critical changes, warn on non-breaking ones. Example: "I first decide whether a change is expected or unexpected. For expected changes I update the mapping and transformation logic. For unexpected ones I fail or quarantine the affected records depending on severity. If an upstream field changes from INT to STRING, I validate whether it can be cast safely; if a new optional column appears, I preserve it in raw storage first and only add it to curated tables after confirming downstream compatibility." Trade-offs to name: - Fail-fast / strict validation protects data quality but reduces availability and can drop more records. - Tolerant ingestion improves robustness and availability but can let bad data propagate if poorly controlled. - Canonical schemas simplify analytics but require more up-front design. The right choice depends on whether the field is critical for downstream reporting or compliance. --- **4. Ensuring data integrity** Interviewers want concrete controls across the whole pipeline, not "I check the data." Cover correctness before, during, and after execution along these dimensions: completeness, accuracy, consistency, uniqueness, referential integrity, and freshness. Ingestion checks: schema validation, required-field checks, file/batch completeness, duplicate detection. Transformation checks: type constraints, business rules, range/domain checks (e.g. status in an allowed set), null thresholds. Load checks: row-count reconciliation between source and target, checksum or aggregate reconciliation (e.g. sum of transaction amounts before and after), referential-integrity checks. Operational safeguards: idempotent loads so reruns/backfills don't create duplicates, retry logic, audit columns (batch_id, ingestion_ts, source_system, job_run_id), lineage, monitoring dashboards, and alerting. Concise interview-ready version: "I ensure data integrity at three levels — input validation, transformation testing, and post-load reconciliation. Before loading I validate schema and required fields; during transformation I enforce type checks, deduplication on a business key, and business rules; after loading I reconcile row counts, distinct key counts, and aggregates between source and target. I make jobs idempotent so reruns don't duplicate data, and I monitor freshness and failures so issues are caught automatically rather than by manual inspection." --- **5. Describing a difficult pipeline issue (STAR)** Use Situation, Task, Action, Result — and be explicit about root cause and prevention. Example: "I built a pipeline ingesting data from several upstream sources into a warehouse. We started seeing failures: an upstream team had changed a field from integer to string without notice, and we were also getting late-arriving and duplicate records from reprocessing. Task: restore the pipeline quickly while keeping bad data out of production tables and downstream dashboards. Action: I traced the failure through job logs and data-quality checks and diffed the old and new schemas, which isolated the root cause to schema drift plus duplicate reprocessed rows. I added explicit type casting and schema validation, routed invalid records to a quarantine path instead of failing the whole job, introduced deduplication on a business key plus event timestamp, backfilled the impacted clean data, and added schema-drift alerts so future upstream changes would be caught early. Result: failures dropped sharply, reruns became safe and idempotent, downstream tables stabilized, and the alerts cut debugging time because they identified whether an issue was schema drift, bad data, or delayed ingestion." Use real metrics if you have them: failure rate reduced from X% to Y%, recovery time from hours to ~20 minutes, duplicate rate eliminated during backfill, latency from hours to minutes. --- **Common mistakes to avoid** - Listing tools without explaining the decisions or trade-offs behind them. - Claiming integrity is "ensured" by manually eyeballing a few rows. - Describing a challenge with no root cause and no prevention step. - A generic self-introduction that never connects back to data engineering. The best answer sounds like someone who can build pipelines, anticipate failure modes, and communicate clearly with both engineers and stakeholders.

Rubric: the screen scores communication (clear, structured, project-grounded answers), technical depth (schema-evolution handling and multi-stage data-integrity controls), and ownership (a real STAR debugging story with root cause and prevention). Strong candidates translate skills into business value, name trade-offs, and explain how they would validate that a fix worked.