FAANG Data Engineer Interview Preparation Guide - Mid Level

Direct answer

Use a broadcast (map-side) join whenever one side is small enough to fit comfortably in every executor's memory, since it eliminates the shuffle of the LARGE side entirely; fall back to a shuffle (sort-merge) join when neither side is safely broadcastable. For a 10 billion-row fact against a 2 million-row dimension, broadcast the dimension explicitly (do not rely purely on the automatic threshold) unless profiling shows its actual serialized size is too large for the cluster's executor memory budget, in which case bucketing both sides or accepting a shuffle join are the real fallbacks.

Structured elaboration

The decision. Spark automatically broadcasts a side whose ESTIMATED size is under spark.sql.autoBroadcastJoinThreshold (default 10 MB, deliberately conservative); a 2 million-row dimension table, at a modest row width (say a handful of string/numeric columns, a few hundred bytes per row), plausibly lands well over that DEFAULT threshold even though it may still comfortably fit in executor memory, meaning the automatic decision alone might choose a shuffle join for data that is genuinely broadcast-safe. The FIX is not always "raise the threshold" (which risks Spark deciding to auto-broadcast something ACTUALLY too large elsewhere in the same job); an explicit F.broadcast(dim_df) hint targets just this one join, overriding the automatic estimate for exactly the case validated to be safe.

Configuration knobs. spark.sql.autoBroadcastJoinThreshold: the automatic size cutoff (raising it broadly affects every join in the session, a blunt instrument); F.broadcast() (DataFrame API) or the /*+ BROADCAST(dim) */ SQL hint: an explicit, PER-JOIN override that does not affect other joins in the same job; spark.sql.shuffle.partitions: governs the shuffle side's parallelism for whatever joins DO shuffle, sized against actual data volume (the heuristic) rather than left at Spark's default (200), which is frequently wrong for either a 10-billion-row fact table's genuine shuffle needs or a much smaller job.

Fallback strategies if the dimension is too large to broadcast. (1) Bucket both tables on the join key with a matching bucket count, so a recurring join runs shuffle-free without needing to broadcast anything, appropriate specifically when this exact join recurs. (2) Bloom-filter pre-filtering: if the fact table has a low match rate against the dimension, pre-filter the fact side before the shuffle to reduce shuffle volume even though a full shuffle join still happens. (3) Accept the shuffle join outright, sized correctly (spark.sql.shuffle.partitions tuned to the actual data volume), when neither broadcasting nor bucketing is viable, a fully legitimate, correct outcome, just a more expensive one than a broadcast would have been.

Runtime fallback: the lookup grows unexpectedly. A dimension table that was safely small when the job was first written can grow over time (new dimension rows added as the business grows); a hardcoded F.broadcast() hint does NOT protect against this the way relying on the AUTOMATIC threshold-based decision would, and Adaptive Query Execution (AQE, enabled by default since Spark 3.x) can additionally choose to broadcast a join PLAN-TIME estimate got wrong, or de-escalate away from an explicit broadcast that turns out to be unsafe, at RUNTIME based on actual observed sizes; still, periodically re-validating a hardcoded broadcast hint against the dimension's current actual size (not just trusting it was correct when first written) is the more deliberate practice, since AQE's runtime adjustments are a safety net, not a substitute for validating the assumption in the first place.

Worked example

A 10 billion-row fact_events table joined against a dim_products table with 2 million rows, each row averaging roughly 300 bytes (a handful of string attributes), giving an estimated serialized size around $2{,}000{,}000 \times 300 \text{ bytes} = 600 \text{ MB}$.

Decision: 600 MB is well over the DEFAULT 10 MB auto-broadcast threshold (Spark would choose a shuffle join automatically without an explicit hint), but well under a typical executor's available memory (executors with, say, 16-32 GB heap comfortably accommodate a 600 MB broadcast with room to spare); explicitly broadcasting with F.broadcast(dim_products) is the right call here, since it is genuinely safe but would NOT happen automatically at the default threshold.

If dim_products instead grew to 50 million rows (roughly 15 GB estimated), the calculus changes: 15 GB broadcast to EVERY executor (not once cluster-wide) risks exceeding a typical executor's memory budget, especially alongside that executor's other memory needs (both apply); at this size, falling back to a shuffle join (with correctly-sized spark.sql.shuffle.partitions) or bucketing both sides (if this join recurs) is the safer choice, and forcing a broadcast here risks the executor-level OOM as the direct failure mode of over-forcing a broadcast.

Trade-offs and pitfalls

• Common mistake: relying purely on the DEFAULT auto-broadcast threshold and assuming Spark "would have broadcast it if it were safe"; the default (10 MB) is deliberately conservative and frequently misses genuinely safe cases like this question's own 2-million-row dimension, making an explicit hint the more reliable choice once the size has actually been validated.
• Common mistake: raising autoBroadcastJoinThreshold globally to cover one specific join's needs, inadvertently causing Spark to auto-broadcast something ELSE in the same session that is actually too large; a targeted F.broadcast()/SQL hint on the SPECIFIC join is the more surgical fix.
• Detecting a spilled or failed broadcast. A broadcast that turns out too large for executor memory manifests as an OOM specifically during the broadcast/build phase (visible in executor logs and the Spark UI's failed-stage detail, often distinguishable from a shuffle-stage OOM by WHICH stage fails and at what point in its lifecycle), the concrete signal that the broadcast-safety assumption for that specific join needs re-validating, not a signal to blindly retry with more memory.
• A hardcoded broadcast hint is a point-in-time decision, not a permanent guarantee; re-validate periodically for any dimension table whose size is not fixed by design, since the cost of getting this wrong (an executor OOM in production) is more disruptive than the cost of an occasional size re-check.

Direct answer

Build a standing information diet from what the partner function already produces for itself, its goals or planning document, the metrics it is measured on, and its retro or release notes, and pair that with a recurring informal check-in with one counterpart in that function. You are not trying to get invited into their planning meeting; you are trying to read what they optimize for, and occasionally confirm your read against a real person.

Structured elaboration

The habit that ties these together: translate their metric into one sentence you could say back to them and have them agree it is accurate, then test that sentence the next time you talk. If you cannot state their current priority in a sentence they would sign off on, your information diet has a gap.

Worked example

Suppose you regularly partner with a support or customer-success function but are not in their planning. Their quarterly goals page (a document they publish for their own team) states the goal is "reduce median response time." Reading that before proposing a change that would meaningfully increase inbound volume lets you flag the likely trade-off to your counterpart ahead of launch, rather than finding out after the fact that you worked against their stated goal. The artifact told you what they were measured on; the counterpart conversation confirmed it was still current.

Trade-offs & pitfalls

• Relying only on artifacts risks reading a goal that is stale or aspirational and no longer reflects what the team is actually prioritizing day to day.
• Relying only on a single counterpart's opinion risks mistaking one person's take for the function's actual priority, especially if that person is not close to how the team's metrics are reviewed.
• A common miss: reading the dashboard but never validating the interpretation with anyone in that function, which produces confidently wrong assumptions that only surface when a decision already went the wrong way.
• The senior differentiator on an easy-sounding question like this is treating it as a standing habit built before you need it, rather than something you scramble to learn only after a conflict has already surfaced.

Direct answer
Most large employers that codify their interview values name broadly similar underlying traits, even when their specific vocabulary differs: a customer or user-first orientation, taking ownership beyond a narrow scope, moving with appropriate urgency, holding a high quality bar, and being trustworthy and transparent recur across nearly every published framework, just under different labels.

Structured elaboration

Worked example
The table above is itself the worked example. A strong candidate should be able to reproduce a table like this from memory for whichever specific company's list they are asked about, translating each of that company's named principles onto one of these five underlying traits, rather than treating an unfamiliar company's vocabulary as an entirely new set of ideas to learn from scratch.

Trade-offs and pitfalls
Treating every company's list as identical is itself a mistake; the values differ in emphasis, and in what is explicitly left off the list. A company whose published list omits any explicit ownership language may culturally deprioritize individual initiative in favor of process, for example, and that is worth noticing rather than flattening away. A candidate who can only speak the vocabulary of one company, fluent in one set of terms but unable to translate the same underlying trait into a different company's language, reads as having memorized rather than internalized the competencies involved.

Title: {{job_name}} ETL — Overview
Short description:

• Purpose: {{one-line purpose}}
• Owner: {{team/person}} | SLA: {{e.g., hourly/daily}} | Last updated: {{YYYY-MM-DD}}

Inputs

• Source system(s): {{source_name}} (type: {{db/stream/file}})
• Input schema / sample record:

-- Example: source table schema
SELECT column1, column2, column3 FROM {{source_table}} LIMIT 1;

• Ingestion frequency: {{cron or event}}
• Data volume: {{rows/day | GB/day}}

Outputs

• Destination: {{warehouse/table/path}} (format: {{parquet/csv/table}})
• Output schema / primary keys:

-- Example: target DDL
CREATE TABLE {{target_table}} (
  id BIGINT PRIMARY KEY,
  ts TIMESTAMP,
  metric DOUBLE
);

• Consumer(s): {{analytics/model/team}}

Transformation Logic

• High-level steps:
  1. Extract from {{source}} with filters: {{filter_conditions}}
  2. Clean/enrich: {{dedupe, null-handling, type-casting}}
  3. Business rules: {{rule_1; rule_2}}
  4. Load to {{target}} with partitioning: {{partition_column}}
• Sample implementation (Spark):

# spark: read -> transform -> write
df = spark.read.format("parquet").load("s3://{{source_path}}")
df = df.filter("{{filter_expr}}") \
       .withColumn("metric", col("value").cast("double")) \
       .dropDuplicates(["{{dedupe_key}}"])
df.write.mode("overwrite").partitionBy("{{partition_col}}").parquet("s3://{{target_path}}")

Monitoring & Alerts

• Metrics: rows_in, rows_out, success_flag, runtime_seconds
• Alert thresholds: {{e.g., rows_out < expected → PagerDuty}}

Edge Cases & Data Quality

• Nulls in {{col}} -> action: {{drop/fill/default}}
• Late-arriving data: {{allow/ignore/backfill_policy}}
• Schema evolution: {{fail/auto-cast/notify}}
• Duplicate records: {{dedupe_key}} strategy

Testing & Validation

• Unit tests: {{test cases}}
• Reconciliation query:

-- row count sanity check
SELECT COUNT(*) FROM {{target_table}} WHERE ds = '{{date}}';

Run / Deploy

• Trigger: {{airflow DAG / cron / event}}
• Config parameters: {{param1=.., param2=..}}

Change log

• {{date}}: {{summary of change}}

Direct answer. Compare Snowflake, BigQuery, and Redshift on five axes: architecture model (how compute and storage separate), concurrency handling, pricing model, storage format support, and operational overhead. There is no universal winner; the right choice depends on your team's existing cloud, your query concurrency profile, and how predictable your workload is.

Structured elaboration.

Three platform-specific units in that table are worth defining plainly, since the question is explicitly asking about concurrency handling and pricing: a Snowflake compute credit is its per-second billing unit for warehouse compute, so a bigger or longer-running warehouse simply burns credits faster. A BigQuery slot is the platform's unit of parallel query-processing capacity; the "shared slot pool" is the pot of these units Google draws from to run your query, and a slot reservation just reserves a guaranteed number of them for you instead of sharing the pool with every other BigQuery customer. A Redshift WLM (Workload Management) queue is a named lane that routes a query to a specific, bounded share of the cluster's memory and concurrency; hitting a concurrency limit means that particular queue's lane is full, not that the whole cluster is out of capacity.

Worked example. For a fast-growing team with roughly 500 analysts running around 10,000 BI queries a day against a 10TB active dataset, concurrency handling is the deciding factor more than raw performance: Snowflake's ability to spin up independent warehouses per team or workload avoids one group's heavy queries starving another's dashboard, and its per-second billing means idle warehouses cost nothing when auto-suspended. BigQuery is an equally strong fit if the team is already GCP-native and wants zero cluster management, especially if the query pattern is bursty rather than continuously heavy, since on-demand pricing avoids paying for idle capacity at all. Redshift becomes the stronger choice when the workload is large and steady enough that reserved/provisioned capacity is cheaper than pay-per-use, or when the team already has deep AWS-ecosystem integration (IAM, Glue, Lake Formation) that reduces the value of switching platforms. At petabyte scale with a high-concurrency BI user base, total cost of ownership becomes the deciding axis rather than raw price-per-query, since the storage-versus-compute separation and auto-scaling behavior of Snowflake or BigQuery tend to avoid the manual capacity-planning overhead that a large provisioned Redshift cluster requires, while a spiky, bursty query pattern specifically favors either platform's auto-scaling over a fixed-size cluster.

Trade-offs and pitfalls. Benchmarking these platforms fairly is hard: comparing default settings without tuning distribution/clustering keys, using a dataset too small to expose real concurrency behavior, or ignoring egress and data-transfer cost between your existing systems and the new platform will all produce misleading conclusions. Vendor lock-in is real in all three directions (proprietary SQL extensions, proprietary storage formats, ecosystem integrations), so weigh switching cost alongside today's price and performance, not just today's benchmark numbers.

Situation: At my last data platform role we had repeat incidents where upstream schema changes broke ETL jobs, causing analyst outages and costly re-runs.

Task: I needed a postmortem process that didn't just record lessons but converted them into measurable, team-wide capability improvements to prevent recurrence.

Action:

• Immediate postmortem within 48 hours (blameless) led by the on-call engineer (owner) and facilitated by me as tech lead.
• Template captured timeline, root cause, contributing factors, and proposed action items with clear owners and due dates.
• For every action item we created a tracked ticket in our backlog (Jira) with type tags: policy, automation, test, documentation, training. Example tickets: "add schema-contract enforcement CI" (owner: infra engineer), "add transformation unit tests and sample fixtures" (owner: pipeline owner), "runbook: schema-change checklist" (owner: data steward).
• Small changes (<=3 days) were sprinted; larger work had OKR alignment and roadmap slots.
• We converted lessons into three artifact types: code (PRs), automation (CI jobs), and learning (15-min demo in weekly engineering sync + a short Confluence how-to).
• Quarterly “closure” review: original ticket owners presented status and metrics in a retro; stale items escalated.
• Measurement: defined KPI per action (e.g., number of pipeline failures due to schema changes, mean time to detect, number of downstream broken builds). We set a baseline pre-change and tracked weekly.
• Reinforced via on-call playbooks and automated alerts tied to new CI checks so prevention delivered observable signals.

Result: Within two quarters schema-related incidents dropped 70%, MTTR fell 50%, and the team adopted a contract-first pattern. The combination of owner-assigned tickets, short feedback loops, demonstrable automation, and quantitative KPIs ensured learnings became sustained capability improvements.

Phased rollout vs big‑bang for migrating a 10 TB warehouse (200 dashboard users, nightly ETL):

Phased rollout

• Benefits: Lower blast radius, incremental validation (schema, queries, ETLs), easier user feedback, you can migrate high‑value/low‑risk datasets first. Allows parallel run (dual reads/writes) and gradual optimization.
• Risks: Longer project duration, increased operational overhead (maintaining two systems), potential data divergence if replication lag or schema drift occurs.
• Sequencing implications: Start with noncritical tables/popular read‑only dashboards -> replicate and reconcile -> move downstream ETL jobs and materializations -> cut over critical reports last.
• Rollback complexity: Lower per-phase; you can stop at a phase and revert traffic to source if reconciliation fails. Global rollback is still possible but requires careful cutover flags and idempotent pipelines.
• Monitoring recommended: replication lag, row-level reconciliation metrics (counts/hash), query latency and error rates, ETL success/failure, user-facing data freshness, anomaly/delta detectors, resource utilization.

Big‑bang

• Benefits: Fast single cutover, no long dual-run overhead, simpler long‑term architecture and fewer temporary connectors.
• Risks: High blast radius—possible widespread dashboard breaks, ETL failures impacting all consumers, hard to debug under pressure.
• Sequencing implications: Requires exhaustive pre-cut validation (end‑to‑end tests, synthetic workloads), full dress rehearsal and strict freeze windows.
• Rollback complexity: High — reversing 10 TB of changes and restoring ETL state is slow and error‑prone; requires backups and point‑in‑time recovery readiness.
• Monitoring recommended: same metrics but with aggressive pre/post baseline comparisons, synthetic queries, end‑to‑end acceptance tests immediately after cutover, and alerting on any divergence.

Recommendation (constrained engineering resources): Phased rollout. Although it costs more operational overhead, it reduces risk and allows smaller incremental work items that fit limited resources. Prioritize: migrate high‑value, low‑complexity datasets first, automate reconciliation and smoke tests, use feature flags for consumer switching, and schedule small cutovers outside business hours. This approach minimizes user impact and gives time to fix issues without a catastrophic rollback.

Direct answer

Decide by weighing the cost of a false block (delaying or dropping a probably-fine record) against the cost of a false pass (letting a genuinely bad record reach every consumer of a shared dataset), not by a single fixed rule. Checks on a hard, structural guarantee that downstream logic actually depends on, like a required key being present or a value violating a constraint the rest of the pipeline assumes, should block. Checks that are really statistical health signals, like a metric drifting outside a normal range, should let the record through and raise an alert instead. Placement follows the same logic: put blocking checks as early as possible, before the data reaches anything shared, and put statistical checks wherever there's enough context to compute a meaningful baseline, which is often necessarily later.

Structured elaboration

Decision criteria, block versus alert-and-pass:

Placement follows the same reasoning, not convenience. Hard, structural, cheap-to-evaluate checks belong as early as possible, ideally at ingestion, before a record can be joined, aggregated, or shared with anyone, because catching a violation before it's mixed into downstream state is strictly cheaper than unwinding it afterward. Statistical checks (drift, anomaly detection against a baseline) often need enough accumulated data to be meaningful, which can genuinely push them later in the pipeline; their outcome should still go to an alert rather than a block, since blocking on a probabilistic signal risks stalling the pipeline on a false positive.

A useful middle option: quarantine-and-continue. For a check that's borderline, confident enough to worry about but not confident enough to trust blindly, setting the record aside (not passed downstream, not silently dropped) while the rest of the batch proceeds avoids both a hasty block and a silent pass.

What kinds of checks tend to fall where. A null check on a required key or a duplicate-key check is usually the hard, deterministic, blocking kind. A range or distributional check on a numeric field is usually the softer, alert-worthy kind, precisely because it's inferring "unusual" rather than checking a fact the schema guarantees.

Worked example

A shared orders table feeds 12 downstream consumers. A schema check finds 0.4 percent of a day's 1,000,000 incoming records missing the required customer identifier, a value every downstream join assumes is present:

Even at a small fraction of the batch, this is treated as blocking, because those 4,000 rows would otherwise silently break joins for all 12 downstream consumers at once, and the check itself is unambiguous (the key is either present or it isn't).

Separately, a statistical check on average order value shows a shift from a baseline mean of $85 to $102:

This could be a genuine promotion-driven spike or a data problem; it goes to alert-and-pass rather than blocking, because the check is probabilistic (not every deviation is a defect) and the cost of being wrong in the blocking direction (halting real data from a legitimate business event) is worse here than the cost of a few hours where a chart looks slightly off before a human confirms it either way.

flowchart LR
    A[Raw ingestion] --> B[Hard structural checks: block on failure]
    B -->|pass| C[Transform and aggregate]
    C --> D[Statistical or drift checks: alert, let pass]
    D --> E[Shared dataset]
    E --> F[Downstream consumers]
    B -->|fail| G[Quarantine, do not propagate]

Trade-offs & pitfalls

• Blocking on every check, including soft statistical ones, trades away data availability for a false sense of safety, and will eventually stall the pipeline on a legitimate anomaly like a real traffic spike.
• Letting every check through as alert-only, including hard structural violations, means a genuinely broken record (a missing key that breaks every downstream join) propagates to all 12 consumers before anyone even reads the alert.
• Placing every check right before a report renders catches problems far too late, after the data has already been joined and aggregated into shared state that's expensive to unwind.
• A common wrong turn is picking one block-or-alert policy for the whole pipeline instead of deciding per check, based on that specific check's own confidence and blast radius.

Start with a hypothesis-driven, correlational instrumentation plan: collect resource-level metrics, database/query-level metrics, network metrics, and tracing so you can correlate spikes with the p99 latency jump during ETL windows.

Key metrics to capture

• CPU: %util, user/system/idle/iowait/steal, load average, per-core utilization, context-switches/sec. (iostat/pidstat/perf/Node exporter metrics)
• IO: disk IOPS, bytes/sec, avg wait time (await), service time (svctm), queue length (avgqu-sz), fsync latency, read/write latency distributions. (iostat, blktrace, Prometheus node exporter)
• Locks/DB contention: lock wait time, number of blocked queries, longest-waiting lock, deadlocks, pg_stat_activity, pg_locks, wait_event_types, MySQL INFORMATION_SCHEMA.INNODB_LOCK_WAITS, query wait histogram, slow query log, EXPLAIN ANALYZE. For Spark/Hive: task skew, GC pauses, shuffle write/read waits.
• Network: interface throughput (tx/rx), errors, drops, retransmits, RTT, packet loss, TCP retransmits, connection counts, NIC queue depth. (ifstat, ethtool, netstat, tc, Prometheus node exporter)
• Application/Query: p50/p95/p99 latency per query id, QPS, rows processed, plan changes, cache hit ratio, memory usage, GC pauses. (APM or query-level metrics, pg_stat_statements, Spark UI)
• End-to-end tracing: distributed traces to see which span (DB, network, disk) inflates during ETL (OpenTelemetry, Jaeger, Zipkin).

Tools and how to use them

• Metrics ingestion + dashboards: Prometheus + Grafana to chart p99 alongside CPU/iowait/IOPS/net throughput. Add alerts on correlation thresholds.
• Host tools for detailed capture: vmstat, iostat, pidstat, atop, dstat for real-time; blktrace or perf for deep IO.
• DB diagnostics: pg_stat_statements, EXPLAIN ANALYZE, auto_explain, slow query logs, MySQL Performance Schema.
• Tracing/APM: OpenTelemetry/Jaeger or Datadog APM to attribute latency to spans (DB read, network, serialization).
• Network: tcpdump/iftop/iperf for reproducing network saturations and validating retransmits.

Investigation steps

1. Baseline: capture metrics before/during/after ETL window. Plot p99 overlayed with CPU%, iowait, disk queue length, network throughput, lock wait counts.
2. Correlate spikes: if p99 aligns with high iowait/disk queue → IO bottleneck. High CPU% with low iowait → CPU. Increased lock waits/blocked queries → contention. High network tx/rx or retransmits → network saturation.
3. Drill-down: run EXPLAIN ANALYZE on slow queries, enable trace sampling to see span breakdown, use iostat/blktrace to measure disk latency distribution, and check DB lock tables for waiting locks.
4. Controlled experiments: run ETL with throttled IO (ionice/blkio), reduced parallelism, or on separate network path to confirm causality.
5. Remediation targets: add indexes, tune query plans, increase IO capacity or use faster storage, reduce ETL concurrency, optimize network path or offload heavy shuffles, or introduce resource isolation.

Example: if p99 spikes with iowait and disk avgq grows during ETL, but CPU is low, root cause = IO. If pg_stat_activity shows many queries waiting on locks at same time, root cause = locking. Use tracing to confirm which component's span grows most during the latency window.

Approach

Walk both dictionaries key by key. When a key exists in both and both values are themselves dicts, recurse into them; otherwise, the second dictionary's value wins outright (this covers overwriting a scalar, a list, or a value whose type changed between the two inputs).

Code (Python 3.12)

def deep_merge(a: dict, b: dict) -> dict:
    """Merge b into a. Nested dicts are merged recursively;
    any other type in b overwrites the corresponding value in a.
    Returns a new dict; does not mutate a or b.
    """
    result = dict(a)
    for key, b_val in b.items():
        a_val = result.get(key)
        if isinstance(a_val, dict) and isinstance(b_val, dict):
            result[key] = deep_merge(a_val, b_val)
        else:
            result[key] = b_val
    return result

a = {"db": {"host": "localhost", "port": 5432}, "debug": False}
b = {"db": {"port": 5433, "user": "admin"}, "debug": True}
print(deep_merge(a, b))
# {'db': {'host': 'localhost', 'port': 5433, 'user': 'admin'}, 'debug': True}

What | (3.9+) gets you, and where it falls short

| (and |=) is a genuine, readable improvement over dict(a, **b) or {**a, **b} for a shallow merge: it is one operator, it clearly reads as "merge these two mappings," and |= mutates in place when you want that. But it merges exactly one level deep: for any key present in both, b's value replaces a's value wholesale, even when both are dicts, so it cannot express "merge these nested config sections together" at all:

print(a | b)
# {'db': {'port': 5433, 'user': 'admin'}, 'debug': True}

Notice db.host is gone entirely: | replaced the whole nested db dict with b's db dict instead of combining them, which is exactly the behavior this question asks you to avoid. | is the right tool when you know your structures are flat, or when "later fully replaces earlier" is the actually-intended semantics for nested values too; it is the wrong tool the moment nested merging matters, which is why deep_merge above cannot be replaced by it.

Key points

• isinstance(a_val, dict) and isinstance(b_val, dict) is the single branch point deciding "recurse" vs. "overwrite"; every other type (list, str, int, a value that changed type between a and b) falls to the overwrite branch, by design.
• result = dict(a) creates a shallow copy so the top-level of a is not mutated; nested dicts that are NOT touched by a merge (a key only present in a) are still the same nested object as in the original a, since this is a shallow copy at each level, not a full copy.deepcopy. If the caller needs the result to share no mutable structure with the inputs at all, wrap a/b in copy.deepcopy before merging, at the cost of that copy's own time and memory.

Complexity

Time: $O(n)$ where $n$ is the total number of keys across both structures (every key is visited exactly once, at whatever depth it lives). Space: $O(n)$ for the new dicts constructed along the way (one new shallow dict per merged nesting level).

Trade-offs & pitfalls

• Overwrite vs. combine, the choice this question absorbs from 'sum the values instead' variants: hardcoding "b always wins" is only one policy. A parametrized version threading a combine callback through the recursion generalizes to "add the numbers instead of replacing them":

def deep_merge_with(a, b, combine=lambda old, new: new):
    result = dict(a)
    for key, b_val in b.items():
        a_val = result.get(key)
        if isinstance(a_val, dict) and isinstance(b_val, dict):
            result[key] = deep_merge_with(a_val, b_val, combine=combine)
        elif key in result:
            result[key] = combine(a_val, b_val)
        else:
            result[key] = b_val
    return result

print(deep_merge_with({"counts": {"x": 3}}, {"counts": {"x": 4, "y": 1}}, combine=lambda old, new: old + new))
# {'counts': {'x': 7, 'y': 1}}

• Merging more than two dicts, the other absorbed variant: deep_merge is associative enough (left-to-right) to fold over an arbitrary number of dicts with functools.reduce, rather than needing a special many-way version (associative here just means merging A-then-B-then-C gives the same result as merging A-then-(B-then-C), so it is safe to fold the whole list left to right without special-casing more than two dicts at a time):

import functools
dicts = [{"a": 1}, {"a": 2, "b": 3}, {"b": 4, "c": 5}]
print(functools.reduce(deep_merge, dicts, {}))
# {'a': 2, 'b': 4, 'c': 5}

• Lists are treated as scalars here (b's list replaces a's list entirely); if list concatenation or per-index merging is the intended behavior, that needs its own explicit branch, since there is no single "obviously correct" way to merge two lists.
• Cyclic or self-referential nested structures would recurse without terminating; this is an edge case worth naming rather than silently handling, since typical configuration-merge inputs (JSON/YAML-shaped dicts) cannot contain cycles.