Target Data Engineer Interview Guide

Target's interview loop is compact (five rounds, about two weeks), but the System Design round is where most rejections happen. Candidates who can write clean Spark jobs still freeze when asked to design a pipeline with explicit SLA windows, fault tolerance, and cost constraints tied to real retail operations like overnight inventory replenishment or promotional pricing updates.

Target Data Engineer Role

You're joining a team that builds and operates data pipelines on a hybrid platform spanning legacy Hadoop clusters and a growing GCP/BigQuery footprint. Your pipelines feed inventory replenishment, pricing analytics, demand forecasting, and Target Circle personalization. Success after year one means you own a production pipeline end-to-end (ingestion through curated serving layer), your downstream analysts trust your datasets, and you've handled at least one on-call rotation during Q4 without a major SLA breach on overnight batch jobs.

A Typical Week

The infrastructure slice is where your planned coding day goes to die. A stale Power BI dashboard gets traced back to a broken Hive-to-BigQuery sync, and suddenly your afternoon is a manual backfill instead of the Spark job you'd scoped. Cross-functional syncs with Supply Chain and Merchandising teams aren't filler, either. Those meetings are where you learn which schema changes will break a demand forecasting retrain or why a store-cluster dimension matters for same-day fulfillment.

Projects & Impact Areas

Target is actively migrating workloads from on-prem Hadoop to GCP, so you'll write design docs for things like moving batch Hive ETL jobs to near-real-time Dataflow streaming for fulfillment use cases. That migration work sits alongside building curated datasets and feature tables consumed by analytics and data science teams across merchandising, supply chain, and pricing. The variety is real, but so is the operational weight: Target's platform engineering org expects you to own cost visibility for your pipelines through their showback infrastructure, not just correctness.

Skills & What's Expected

Software engineering quality is the most underrated dimension here. Target expects production-grade Scala/Python/Java with proper testing, CI/CD, and code review participation, not notebook scripts. Data architecture and pipeline design (Spark, Hive, BigQuery) is the core competency, scored high alongside SWE practices. Cloud/infra knowledge matters but carries medium weight, so don't over-rotate on GCP certifications. ML and GenAI are scored low. Skip them in your prep.

Levels & Career Growth

The P2-to-P3 promotion hinges on independently owning an end-to-end pipeline domain and demonstrating operational reliability (reducing incidents, hitting SLAs, handling backfills without hand-holding). P3 to P4 is where people stall, because the bottleneck shifts from technical execution to scope of influence: setting standards adopted by multiple teams, leading cross-team initiatives like platform migrations, and mentoring others so outcomes continue without your direct involvement.

Work Culture

Most data engineers work roughly three days a week in-office at Target Plaza in Minneapolis, following Target's hybrid policy. The pace is sustainable on a normal week (most people offline by 5:30 PM), but it ramps around seasonal events like back-to-school and Q4 holidays, when pipeline SLA windows tighten and on-call rotations carry more backfill pressure. The collaboration culture is strong, with blameless postmortems and genuine team ownership of production systems, though "ownership" at Target concretely means you're responsible for the operational health, cost tracking, and incident response for your pipelines, not just the initial build.

Target Data Engineer Compensation

Target communicates RSU grants as a target dollar amount, not a fixed share count. The conversion to actual shares happens at the stock price on or near the grant date, so if TGT dips between your offer letter and the board's routine approval, you end up with more shares (and vice versa). Specific vesting schedules and refresh grant details aren't publicly documented, so ask your recruiter for the exact cliff and annual breakdown before you sign anything.

When negotiating, anchor your base salary counter to the pipeline scale you'd own (inventory replenishment across 1,900+ stores, near real-time pricing feeds into BigQuery) rather than generic market data. Target's offer process moves fast for a Fortune 50, so explicitly request time and a full written breakdown of base, bonus target, equity, vesting, and relocation before countering. The single lever most candidates miss: pushing for a higher level rather than a higher number within the same band, because at Target the jump from P2 to P3 unlocks a roughly 4x increase in annual equity grant value, which compounds far more than a few thousand dollars on base.

Target Data Engineer Interview Process

The one-way recorded video at round two is the sneakiest filter in this loop. There's no live interviewer to read, no back-and-forth to recover from a stumble. Candidates report getting cut before ever reaching a technical round because their recorded answers lacked specifics about operational ownership, incident response, or cross-team collaboration. If your stories don't include real numbers (latency improvements, cost reductions, SLA targets you maintained), the recording won't survive scrutiny.

From what candidates report, the rejection reasons skew toward depth, not breadth. Shallow answers about orchestration and incremental processing sink people in the SQL & Data Modeling round, while the System Design round punishes anyone who can't articulate tradeoffs specific to Target's hybrid Hadoop-to-GCP migration or explain how they'd handle batch-plus-streaming pipelines feeding BigQuery consumers. Knowing the tools matters less than showing you've operated them under real production pressure.

Target Data Engineer Interview Questions

1/* BigQuery Standard SQL */
2WITH recent AS (
3  SELECT
4    transaction_id,
5    store_id,
6    register_id,
7    transaction_ts,
8    line_id,
9    item_id,
10    qty,
11    net_sales,
12    ingest_ts
13  FROM `raw.pos_transactions`
14  WHERE transaction_ts >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
15)
16SELECT
17  transaction_id,
18  store_id,
19  register_id,
20  transaction_ts,
21  line_id,
22  item_id,
23  qty,
24  net_sales,
25  ingest_ts
26FROM recent
27QUALIFY
28  ROW_NUMBER() OVER (
29    PARTITION BY transaction_id, line_id
30    ORDER BY ingest_ts DESC, transaction_ts DESC, store_id DESC
31  ) = 1;

1import json
2import logging
3import os
4import time
5import uuid
6from dataclasses import dataclass
7from typing import Callable, Optional
8
9from google.cloud import bigquery
10
11logging.basicConfig(level=logging.INFO)
12
13
14@dataclass(frozen=True)
15class LoadConfig:
16    project: str
17    raw_dataset: str
18    curated_dataset: str
19    dt: str
20    max_attempts: int = 4
21    base_backoff_s: float = 5.0
22
23
24def with_retries(fn: Callable[[], None], *, max_attempts: int, base_backoff_s: float, logger: logging.Logger) -> None:
25    attempt = 1
26    while True:
27        try:
28            fn()
29            return
30        except Exception as e:
31            if attempt >= max_attempts:
32                logger.exception("exhausted_retries")
33                raise
34            sleep_s = base_backoff_s * (2 ** (attempt - 1))
35            logger.warning("retrying", extra={"attempt": attempt, "sleep_s": sleep_s, "error": str(e)})
36            time.sleep(sleep_s)
37            attempt += 1
38
39
40def ensure_tables(client: bigquery.Client, curated_dataset: str) -> None:
41    # In real code, manage this via IaC or migrations.
42    client.query(
43        f"""
44        CREATE TABLE IF NOT EXISTS `{curated_dataset}.fact_sales` (
45          dt DATE,
46          order_id STRING,
47          line_id STRING,
48          store_id STRING,
49          sku_id STRING,
50          net_sales NUMERIC,
51          load_run_id STRING,
52          load_ts TIMESTAMP
53        )
54        PARTITION BY dt
55        """
56    ).result()
57
58
59def stage_and_swap_partition(client: bigquery.Client, cfg: LoadConfig, *, run_id: str, logger: logging.Logger) -> None:
60    curated = f"{cfg.project}.{cfg.curated_dataset}"
61    raw = f"{cfg.project}.{cfg.raw_dataset}"
62
63    staging_table = f"{curated}.fact_sales_stg_{run_id.replace('-', '_')}"
64
65    # Step 1: Create staging table for this run.
66    client.query(
67        f"""
68        CREATE TABLE `{staging_table}` AS
69        SELECT
70          DATE(@dt) AS dt,
71          order_id,
72          line_id,
73          store_id,
74          sku_id,
75          CAST(net_sales AS NUMERIC) AS net_sales,
76          @run_id AS load_run_id,
77          CURRENT_TIMESTAMP() AS load_ts
78        FROM `{raw}.sales_line_item`
79        WHERE DATE(order_ts) = DATE(@dt)
80        """,
81        job_config=bigquery.QueryJobConfig(
82            query_parameters=[
83                bigquery.ScalarQueryParameter("dt", "DATE", cfg.dt),
84                bigquery.ScalarQueryParameter("run_id", "STRING", run_id),
85            ]
86        ),
87    ).result()
88
89    # Step 2: Validate uniqueness and basic sanity.
90    dup_check = client.query(
91        f"""
92        SELECT COUNT(1) AS dup_cnt
93        FROM (
94          SELECT order_id, line_id, COUNT(1) c
95          FROM `{staging_table}`
96          GROUP BY 1, 2
97          HAVING c > 1
98        )
99        """
100    ).result()
101    dup_cnt = next(iter(dup_check)).dup_cnt
102    if dup_cnt > 0:
103        raise ValueError(f"staging_has_duplicates dup_cnt={dup_cnt}")
104
105    # Step 3: Atomic partition replace via transaction.
106    # BigQuery scripting transaction keeps delete+insert together.
107    client.query(
108        f"""
109        BEGIN TRANSACTION;
110
111        DELETE FROM `{curated}.fact_sales`
112        WHERE dt = DATE(@dt);
113
114        INSERT INTO `{curated}.fact_sales` (dt, order_id, line_id, store_id, sku_id, net_sales, load_run_id, load_ts)
115        SELECT dt, order_id, line_id, store_id, sku_id, net_sales, load_run_id, load_ts
116        FROM `{staging_table}`;
117
118        COMMIT TRANSACTION;
119        """,
120        job_config=bigquery.QueryJobConfig(
121            query_parameters=[bigquery.ScalarQueryParameter("dt", "DATE", cfg.dt)]
122        ),
123    ).result()
124
125    # Step 4: Cleanup staging.
126    client.delete_table(staging_table, not_found_ok=True)
127    logger.info("load_complete", extra={"dt": cfg.dt, "run_id": run_id})
128
129
130def run_load(cfg: LoadConfig) -> None:
131    logger = logging.getLogger("target_de_load")
132    run_id = str(uuid.uuid4())
133    logger.info("load_start", extra={"dt": cfg.dt, "run_id": run_id})
134
135    client = bigquery.Client(project=cfg.project)
136    ensure_tables(client, f"{cfg.project}.{cfg.curated_dataset}")
137
138    def attempt() -> None:
139        stage_and_swap_partition(client, cfg, run_id=run_id, logger=logger)
140
141    with_retries(attempt, max_attempts=cfg.max_attempts, base_backoff_s=cfg.base_backoff_s, logger=logger)
142
143
144if __name__ == "__main__":
145    # Example: PROJECT=myproj RAW_DS=raw CURATED_DS=curated DT=2026-02-25 python load.py
146    cfg = LoadConfig(
147        project=os.environ["PROJECT"],
148        raw_dataset=os.environ["RAW_DS"],
149        curated_dataset=os.environ["CURATED_DS"],
150        dt=os.environ["DT"],
151    )
152    run_load(cfg)
153

The distribution rewards candidates who can move fluidly between writing a Spark job, modeling the Hive table it lands in, and defending the code quality of both. Treating those as separate study tracks is the most common prep mistake, because Target's retail pipelines (think: nightly store-SKU inventory snapshots feeding replenishment across 1,900 locations) demand all three skills in a single design conversation. If you've only practiced cloud architecture or behavioral storytelling, you're studying for the minority of the interview.

Drill retail-flavored pipeline, modeling, and SQL scenarios together at datainterview.com/questions.

How to Prepare for Target Data Engineer Interviews

Target pulled in $106.6 billion in revenue last year and has publicly committed to more than $15 billion in additional sales growth by 2030. Its current north-star priorities center on becoming the destination for trend-forward products and making wellness accessible, personalized, and affordable. For data engineers, that translates into pipelines powering product assortment decisions, personalization engines, and the operational infrastructure behind rapid category expansion (like the largest spring beauty assortment the company has ever launched).

What makes Target's engineering org distinct is how it treats infrastructure ownership. The infra showback system means you own cost visibility for your pipelines, not just correctness. And the platform engineering playbook frames data engineering as a product discipline where shared data products serve hundreds of internal consumers.

The "why Target?" answer that actually works ties your experience to a specific engineering challenge described on tech.target.com. Saying "I read your showback post and I've built similar cost-attribution layers for shared compute clusters" is concrete and hard to fake. Contrast that with vague enthusiasm about the shopping experience or the brand, which tells the interviewer nothing about how you think as an engineer. Reference the playbook's emphasis on feature documents and platform thinking, then connect it to a project where you treated a pipeline as a product with defined consumers and SLAs.

Try a Real Interview Question

1WITH ranked AS (
2  SELECT
3    order_id,
4    store_id,
5    order_date,
6    updated_at,
7    status,
8    total_amount,
9    ROW_NUMBER() OVER (
10      PARTITION BY order_id
11      ORDER BY updated_at DESC
12    ) AS rn
13  FROM orders_events
14)
15SELECT
16  store_id,
17  order_date,
18  COUNT(*) AS unique_orders,
19  SUM(CAST(total_amount AS DECIMAL(18,2))) AS gross_revenue
20FROM ranked
21WHERE rn = 1
22  AND status <> 'CANCELLED'
23GROUP BY store_id, order_date
24ORDER BY order_date, store_id;

Target's interview loop, from what candidates report, puts real weight on SQL fluency applied to retail-shaped data. The problems aren't abstract puzzles; they tend to involve the kind of aggregation, windowing, and schema reasoning you'd actually need when working on inventory or sales datasets at scale. Build that muscle consistently at datainterview.com/coding.

Test Your Readiness

Drill data modeling and pipeline design scenarios at datainterview.com/questions, focusing on retail patterns like slowly changing dimensions for product catalogs and fact tables for transactional data.