Spotify AI Engineer Interview Preparation Guide (Mid-Level)

Direct answer

Split the platform into a control plane and a data plane: a shared control plane owns identity, quotas, and policy, while the data plane runs each team's workloads inside an isolated compute and cost boundary, so one team's runaway job cannot exhaust shared capacity or budget. Standardize the artifact contract (model, environment, and metrics) so any team's output, regardless of training framework, is consumable by the rest of the company.

Structured elaboration

flowchart TB
  CP[Control plane: identity, quota, policy]
  PE[Policy engine: ABAC + residency rules]
  TA[Team A namespace]
  TB[Team B namespace]
  GPU[Shared GPU pool]
  MR[Model registry]
  SV[Serving endpoints]
  BI[BI / reporting consumers]
  CP --> TA
  CP --> TB
  PE --> TA
  PE --> TB
  TA --> GPU
  TB --> GPU
  TA --> MR
  TB --> MR
  MR --> SV
  SV --> BI

Worked example

Suppose the platform has a shared pool of 500 GPUs across roughly 40 teams. At parity, each team's fair share is $500 / 40 = 12.5$ GPUs. Setting a hard per-team ceiling at, say, 5% of the pool (25 GPUs) gives about 2x headroom over parity for legitimate spiky workloads, while still bounding the worst case: even if one team claims its full quota, $500 \times 0.95 = 475$ GPUs (95% of the pool) remain available to everyone else. That single number, the fraction of the pool one tenant can claim before hitting a ceiling, is the concrete lever that turns "noisy neighbor" from an open-ended risk into a bounded one.

Trade-offs & pitfalls

• Stronger isolation (a fully dedicated cluster per tenant) costs more and is operationally heavier than namespace-plus-quota isolation; reserve dedicated clusters for tenants with an actual compliance requirement that data cannot share hardware with other tenants' workloads, not as a default.
• A live serving endpoint sharing a node pool with training jobs needs a stricter guarantee than "same team, same priority": priority classes should reflect production versus experimentation, not just team identity, or a batch job can still degrade a production endpoint belonging to the same team.
• Centralizing every policy decision in the control plane recreates the single point of contention the platform was built to avoid; the control plane should audit and set limits, not gate every individual action.
• Compute isolation and data-residency isolation are separate dimensions: a team can be perfectly isolated on compute and cost and still violate a data-residency rule if the policy engine doesn't independently enforce where regulated data is allowed to live.

Direct answer

After a tokenizer or preprocessing update, distinguish "preprocessing changed" from "data genuinely drifted" by checking whether the same RAW inputs, re-run through both the old and new preprocessing, produce embeddings that differ in a way that exactly explains the observed shift: if they do, it's the pipeline, not the world.

Structured elaboration

1. Replay test: take a fixed sample of raw inputs from BEFORE the change, run them through both the old and new preprocessing/tokenizer, and compare the resulting embeddings directly. If the shift you're seeing in production matches the shift between these two replayed versions of the SAME inputs, you've isolated the cause with high confidence: no real-world drift needed to explain what you're seeing.
2. Timing correlation: a shift that begins at EXACTLY the deployment timestamp of a preprocessing change is strong circumstantial evidence on its own; genuine data drift rarely aligns to the minute with a code deployment.
3. Token-ID-level diffing: for a tokenizer change specifically, directly compare the token IDs assigned to a fixed sample of text before and after: if common tokens are now mapping to different IDs, that alone can shift embeddings without any change in user behavior.

Worked example

Concretely: if a tokenizer update assigns different subword splits to common words (previously "checkout" tokenized as one unit, now splits into "check" + "out"), the resulting sentence embeddings shift measurably for essentially every input, all at once, on the deployment date. Replaying last week's raw text through the OLD tokenizer reproduces last week's embeddings; replaying it through the NEW tokenizer reproduces this week's shifted embeddings: confirming the shift is entirely explained by the tokenizer, not by users writing differently.

Trade-offs & pitfalls

The automatic rollback trigger for this specific case should NOT be the same drift alert used for real data drift: a genuine tokenizer/preprocessing regression should trigger an immediate, high-confidence rollback (you have near-certain evidence of the cause and a known-good previous state to return to), whereas a real data-drift alert should trigger investigation, not an automatic rollback (there's nothing to "roll back" to when the world itself has changed). Conflating the two into one alert path means either real drift gets treated as a code bug (wasted rollback with no fix) or a genuine preprocessing regression gets treated as "just drift" and left to accumulate.

Direct answer

When an urgent security issue and a sales-critical demo land the same day, the deciding factor is exposure, not who asked more forcefully: what could go wrong if the security issue waits, and what can still be preserved for the demo without touching the risky path. Usually both can be partially served: contain or fix the security issue first, and give sales something real to show that doesn't depend on the vulnerable code.

Structured elaboration

1. Triage both in parallel, fast

Read the security bulletin and the demo request together. Identify exactly which services, data, or endpoints the vulnerability touches, and exactly what the demo needs to show.

2. Weigh exposure, not urgency of the ask

A security issue usually carries broader exposure (any affected customer, potential data risk) than a single demo (one prospective deal). That asymmetry is normally the tiebreaker, but it should be checked rather than assumed: a demo that's the last step before a major renewal can occasionally weigh more than a low-severity, well-contained finding.

3. Look for a path that serves both

A scoped hotfix with a canary rollout (releasing the fix to a small slice of traffic first, watching it closely, then rolling out to everyone once it looks clean) for the security issue, paired with a sandboxed or stubbed version of the feature for the demo, often means sales isn't actually blocked on the mainline fix landing first.

4. Communicate the decision and the reasoning immediately

Both sides need a concrete plan with timestamps, not just a priority call: what's happening, by when, and what the other side gets in the meantime.

Worked example

The patch ships to a small share of traffic first while being monitored, then rolls out fully once confirmed clean. In parallel, a second engineer builds a stubbed version of the requested feature specifically for the demo environment, so sales can present it without depending on the code currently under remediation. Both sides get an update within a couple of hours: security gets an ETA for full rollout, sales gets confirmation the demo will work and exactly how.

Trade-offs and pitfalls

• Defaulting to whichever request comes from the louder or more senior stakeholder, rather than actual exposure, is the most common failure mode here.
• Building a demo-only workaround without labeling it clearly as temporary risks it quietly becoming the real implementation, skipping the proper fix.
• Failing to give both sides a concrete timeline turns a reasonable prioritization call into a trust problem, even when the call itself was correct.
• Treating this as strictly either/or, instead of looking for a path that partially serves both, wastes an option that's usually available.

Decision framework (criteria, weight): accuracy potential (35%), compute cost (20%), inference latency (15%), maintenance burden (15%), rollout risk (15%). Compare options:

1. Full retrain on 6 months of data

• Accuracy potential: High. Model can learn new distribution & interactions end-to-end; best for distributional shifts or label changes.
• Compute cost: Very high (GPU hours for full fine-tune, storage of checkpoints).
• Inference latency: Unchanged vs baseline (no extra overhead).
• Maintenance burden: High — retrain pipelines, data validation, monitoring, scheduled retrains.
• Rollout risk: Higher — catastrophic regressions possible; requires shadow testing and rollback plan.

2. Input-side adaptation (adapters / prompt-tuning)

• Accuracy potential: Medium. Good for personalization and fast domain adaptation; may not capture deep representational shifts.
• Compute cost: Low — small parameter updates, cheaper to train and store.
• Inference latency: Slight increase (adapter layers add minimal compute) or zero if using prompt tokens depending on implementation.
• Maintenance burden: Lower — per-user/per-cohort adapters, simpler CI; but more artifacts to manage (many adapters).
• Rollout risk: Lower — scoped changes, easier to A/B and rollback.

Recommendation: If shift is moderate and primary goal is personalization + cost reduction, start with input-side adaptation. If data shows systemic distributional change (new labels/behaviors), prefer retrain.

Experiment plan (pilot)

• Duration: 4 weeks
• Cohorts: holdout baseline, adapter cohort, retrain cohort (if budget allows) OR adapter vs baseline.
• Data: last 6 months split into train/val/test with time-based holdouts and user-level splits.
• Implementation: train adapters per cohort; for retrain, fine-tune full model on same data.
• Deployment: shadow evaluation for 1 week, then randomized A/B test (50/50) with gradual traffic ramp to 10k requests/day.

KPIs & success criteria

• Primary: model quality — delta in task metric (e.g., accuracy/F1/CTR) vs baseline; target: ≥+2% absolute or statistically significant at p<0.05.
• Secondary: latency — p95 increase ≤5% (or latency threshold < X ms).
• Cost: training GPU-hours and inference cost per 1M requests; target: adapter reduces compute cost by ≥50% vs retrain lifecycle.
• Stability: rollback rate, % of requests with prediction changes, calibration (Brier/CE) within tolerance.
• Operational: number of artifacts to manage, time-to-update per personalization (target <24h), storage overhead.
• Safety/fairness: monitor subgroup performance; no subgroup degradation >1% absolute.

Gating rules to scale

• Require statistical significance on primary KPI and meeting latency/cost targets.
• Run 95% CI on metric deltas; if adapter meets targets, proceed phased rollout by risk segments; otherwise, escalate to full retrain assessment.

Direct answer: Making an expensive or budget-constrained feature affordable, whether it's rarely-needed-but-costly-to-materialize or gated by a paid third-party API's usage cap, comes down to the same core levers: a tiered storage/compute strategy that only pays full cost where it's actually needed, caching to avoid redundant recomputation, and a defined fallback for when the budget or tier can't be used.

Structured elaboration:

• Tiered (hot/warm/cold) storage and serving: keep the small fraction of frequently-accessed values in a fast, immediately-available tier (hot, e.g. an in-memory key-value store); keep less frequently accessed values in a cheaper, slightly-slower tier (warm, e.g. a disk-backed key-value store or cache with a longer TTL); and compute rarely-needed values on demand or from a cold archive (e.g. object storage, recomputed on a cache miss) rather than keeping them all resident.
• Eviction policy: an LRU (least-recently-used) or LFU (least-frequently-used) policy promotes a value to a hotter tier as it's accessed more, and evicts back down as access frequency drops, so the hot tier stays small and cheap while still capturing most of the actual read traffic.
• Sampling and hybrid materialization: for a feature depending on a rate-limited or costly external call, sample which entities actually get the live call (rather than calling for every entity), backed by a cached or approximated fallback (e.g. the last successfully computed value, or a cohort-level average) for entities not selected in a given period.
• Caching: once a value is computed (whether via the expensive path or the API call), cache it for a duration appropriate to how quickly the underlying signal actually changes, so repeated requests for the same entity don't repeatedly pay the cost.

Worked cost/latency estimate:

Scenario 1 - expensive-to-materialize feature needed by a small fraction of queries. Assume the feature costs 200ms to compute fresh (e.g. a multi-table join plus an aggregation) and is needed by 5% of 1,000,000 daily queries (50,000 queries/day). Materializing it for every entity up front (100% coverage) costs roughly 1,000,000 x 200ms = ~55.6 compute-hours/day. A tiered design that only computes it on-demand for the 5% of queries that actually need it, with a warm cache (e.g. 1-hour TTL) capturing repeat lookups for the same entity within that window, costs closer to 50,000 x 200ms = ~2.8 compute-hours/day before cache hits, and materially less once the cache absorbs repeat lookups for popular entities - roughly a 20x reduction in compute spend for this feature, at the cost of a 200ms cache-miss latency penalty only on the 5% of queries that need it (versus 0ms for those queries under full materialization, since the value would already be resident).

Scenario 2 - paid third-party enrichment API under a strict monthly budget. Assume the API costs $0.002 per call and the traffic is 1,000,000 entities/day needing the enrichment. Calling it for every entity would cost 1,000,000 x $0.002 x 30 days = $60,000/month. Sampling 10% of entities for a live call each day, with a 30-day cache for the rest (falling back to the most recent cached value, or a cohort default for entities never sampled), reduces this to roughly 100,000 x $0.002 x 30 = $6,000/month, a 10x reduction, at the cost of up to 30 days of staleness for a given entity's enrichment value between live refreshes - an acceptable trade-off if the underlying signal changes slowly relative to that window, and not acceptable if it doesn't (in which case the sampling rate or cache TTL needs to be tightened, raising cost back up until the staleness budget is actually met).

Trade-offs and pitfalls: A tiered or sampled approach necessarily serves some requests with a slightly stale or approximated value; the discipline is making that trade-off deliberately, with a monitored bound on how stale or how approximated is acceptable (tracked as an explicit staleness metric, not just assumed fine), rather than an accident of whatever the caching or sampling logic happens to produce under load. The dollar and compute-hour figures above are illustrative estimates to demonstrate the arithmetic, not measured production numbers; the actual break-even point between sampling rate, cache TTL, and acceptable staleness needs to be computed from the real traffic distribution and the real per-call cost for any given deployment.

Direct answer: Apache Beam, Spark Structured Streaming, and Flink differ mainly in programming model and how natively they support event-time semantics and exactly-once guarantees: Beam is a portable abstraction layer that runs on multiple backends, Spark Structured Streaming is the most operationally familiar to teams already running Spark batch jobs, and Flink has historically had the strongest native support for low-latency, stateful, event-time streaming.

Structured elaboration:

• Programming model. Beam offers a unified batch-and-streaming API that is portable across runners (Dataflow, Flink, Spark), which is attractive if you want to avoid runner lock-in, but adds an abstraction layer that can obscure runner-specific tuning knobs. Spark Structured Streaming reuses Spark's DataFrame API and micro-batch execution model, which is easy to adopt for teams already writing Spark batch jobs, since the mental model and much of the code can be shared. Flink's DataStream API is built streaming-first (with batch as a special case), giving it a more natural fit for genuinely continuous, low-latency processing.
• Event-time support. All three support event-time windowing and watermarking; Flink's implementation is generally considered the most mature and lowest-latency, since it processes events one at a time (true streaming) rather than in micro-batches, giving lower latency for the same watermark configuration.
• Exactly-once guarantees. Flink's checkpointing (based on the Chandy-Lamport distributed-snapshot algorithm, a classical technique for taking a consistent global checkpoint across many machines without stopping them) combined with transactional sinks gives strong exactly-once end-to-end guarantees. Spark Structured Streaming achieves similar guarantees for many sinks via its own checkpointing and idempotent-write support, though its micro-batch model means end-to-end latency is typically higher (hundreds of milliseconds to seconds, versus Flink's ability to get into tens of milliseconds).
• Operational complexity. Spark Structured Streaming benefits from operational familiarity if the team already runs Spark; Flink requires learning a separate system and operational model, but rewards that investment with better latency and state-management ergonomics for complex stateful jobs; Beam's portability is valuable if the org anticipates needing to switch runners, but is often unnecessary complexity if there is no near-term plan to do so.
• Integration. All three integrate with common feature-store and warehouse targets via connectors; Flink and Spark both have mature Kafka connectors, and Beam's connector ecosystem depends on which runner is underneath.

Worked example: A team already running nightly Spark batch jobs for feature engineering that now needs a near-real-time version of a similar computation will often reach for Spark Structured Streaming first, since it reuses existing Spark expertise and much of the transformation code, accepting a few-hundred-millisecond-to-second latency floor; a team building a genuinely latency-critical service (sub-100ms feature freshness for fraud scoring) is more likely to reach for Flink specifically for its lower-latency event-at-a-time processing model, accepting the cost of a new operational skillset.

Trade-offs & pitfalls: Choosing Spark Structured Streaming purely for team familiarity without checking whether its micro-batch latency floor actually meets the use case's freshness requirement is a common mistake; the fit needs to be validated against the actual SLA (service-level agreement), not just against what the team already knows. Beam's portability promise is real but the actual runtime behavior and performance characteristics still depend heavily on the underlying runner, so "portable" does not mean "identical performance everywhere," and a job tuned for one runner may need retuning after a runner switch despite using the same Beam code.

Direct answer

A credible "why this team" answer names something structural about the team, what it owns, the shape of its problems, how it's run, and something specific about the manager, not just a title, and explains why now fits your trajectory. If the answer would apply equally to any team at the company, it hasn't actually answered the question.

The framework

1. Team scope: what does this team own, and what stage is it at (0-to-1, meaning building something new from scratch rather than scaling an existing product; scaling; or maintaining a mature system)? Different stages reward different strengths; say which one you want and why.
2. Working style: how does the team actually operate day to day, autonomy versus process, how decisions get made, review cadence? Pull this from real sources, public talks, blog posts, informational conversations, not the job posting's adjectives.
3. The manager, specifically: cite something concrete you learned about how they lead, how they give feedback, what they optimize for, a talk or writing of theirs, rather than "I heard they're great to work for."
4. Why this team over other teams at the same company, and why now: connect the team's current problems to where you specifically want to grow next, on a timeline that makes sense for your career stage.

Worked example

I looked at [Team X]'s public roadmap talk and two blog posts their lead published on how they run planning, and two things stood out: the team is past the 0-to-1 stage and is now working on scaling problems, which is the kind of problem I want next, and their planning process is explicitly lightweight, weekly written updates instead of long meetings, which matches how I work best. I also had a short call with a recent hire on the team, who described the manager as someone who pushes for written proposals before a big decision rather than deciding in the room, which tells me disagreement is expected to be argued on paper, not on politics. That combination, the problem stage and the decision-making style, is why this team specifically, not just this company, and why now: I've spent the last stretch of my career on 0-to-1 work and want the scaling problem next.

Trade-offs and pitfalls

Watch the other failure direction too: over-researching to the point of reciting someone's public profile back to them reads as unsettling rather than diligent, so use two or three specific, verifiable details rather than everything you found.

Goal: compare memory and wall-clock of three join methods on two large disk-resident tables.

A concrete illustrative scale, to make the deliverable tangible (placeholder numbers for the experiment's INPUT sizes, not a claimed result; the actual measured numbers only come from running it): joining a 5,000,000-row table to a 50,000,000-row table on a shared user_id column, on a machine with 8 GB of RAM available to the process. That size difference (10x) is deliberately chosen so a hash join (build an in-memory lookup table keyed by the join column from the SMALLER side, then scan the larger side and look up each row's match against it, rather than one built from the bigger side) has an obvious "small side" to build its lookup table from.

Metrics:

• Peak RAM (process) via psutil
• Total wall-clock and CPU time
• I/O throughput and disk usage
• Return correctness (row counts, spot checksums)

Fairness:

• Same machine, same storage medium, same join keys/indexes
• Fixed dataset snapshots and repeat runs per method
• Use warm/cold cache measurements (warm cache: the operating system already has the file's data sitting in memory from a previous read, so the next read is fast; cold cache: the OS has to actually go to disk, which is slower and closer to a fresh, worst-case run; measuring both matters because a method that looks fast on a warm cache can look very different the first time it touches a cold file)

Experiment plan:

• Prepare synthetic datasets with controlled sizes and cardinalities, using the illustrative 5M/50M scale above (or whatever scale matches the real workload) as a concrete starting point
• Method (1): pandas: read table A in chunks, build index on join key for B or stream smaller table and use dict-based hash join (build an in-memory Python dict keyed by the join column from the smaller table, then scan the larger table row by row and look each row's key up in that dict, an $O(n + m)$ approach instead of an $O(n \cdot m)$ nested comparison)
• Method (2): SQLite: load both tables into temp DB, create indexes, run JOIN
• Method (3): Dask (a library that mirrors the Pandas API but splits data into partitions and runs the same operations, including merge/join, across them in parallel, so a join too large for one machine's memory can still complete by processing partitions and spilling intermediate results to disk when needed): persist datasets on disk, execute dask.dataframe.merge with appropriate partitions

Presentation:

• Plot peak memory vs runtime per method (error bars from repeats)
• Table with throughput, disk I/O, and CPU
• Discuss trade-offs: simplicity, indexing cost, parallelism, disk spill behavior (disk spill: what happens when an operation's intermediate data no longer fits in RAM and the engine starts writing partial results to disk to keep going instead of crashing with an out-of-memory error, trading speed for the ability to finish at all)

Success criteria: lowest peak memory with acceptable runtime; reproducible scripts + configs

Direct answer

A code review surfaced a concern about our feature-engineering pipeline (feature engineering: transforming raw data into the input variables, or "features," a model actually trains on) that turned out to need a real structural refactor, not a quick fix. I triaged the reviewer's concerns by how much risk of silently corrupting results each one carried, planned an incremental refactor rather than a rewrite, added tests and CI (continuous integration, automated checks that run against every change before it merges) checks targeting the specific failure class, and the result was measurably fewer silent data bugs and an easier pipeline to extend afterward.

Structured elaboration

Reviewer concerns on a feature-engineering pipeline usually fall into a few recognizable buckets: duplicated or copy-pasted feature logic across scripts, which risks silent drift when one copy gets updated and the other doesn't; train and serve skew, where a feature is computed slightly differently in the batch training path than in the real-time serving path; and missing test coverage over transformation logic, which makes it easy to break silently.

Prioritizing and planning: rank concerns by how likely each is to silently corrupt downstream model results, which is the hardest category to detect after the fact, above concerns that are real but mainly developer-experience friction. Plan the refactor incrementally rather than as one large rewrite: extract shared feature logic into a single reusable module first, since that fixes the highest-risk drift issue with the least churn, then layer in tests, then address any remaining path-specific inconsistency. An incremental sequence is easier to review and far less risky to ship than a single big-bang change.

Tests and CI checks worth adding: unit tests per feature-transformation function against known input and output pairs; a regression test that runs the whole pipeline against a fixed sample dataset and compares the output feature values to a stored reference snapshot, so an unintended change is caught before merge; and, specifically for train/serve skew, a CI check that runs both the batch and serving code paths against the same sample records and fails the build if their outputs diverge beyond a small tolerance.

Worked example

A reviewer flagged that a churn-prediction feature-engineering script recomputed a "days since last purchase" feature slightly differently from the version used at serving time: one used calendar days, the other used a rolling 24-hour window based on timestamp, producing subtly different values for users near a day boundary. I prioritized this above two minor style comments in the same review, since it directly risked silently degrading real predictions without any visible failure. I planned the refactor as three pull requests: first, extract the shared feature calculation into a single function that both the batch and serving code import; second, add a unit test with edge-case timestamps right at a day boundary; third, add a CI check that runs both code paths against the same sample records and fails the build if their outputs diverge beyond a small floating-point tolerance. After merging, the specific drift was fixed, and the new divergence-check CI job later caught two further, unrelated feature mismatches introduced by later changes before they reached production, concrete evidence the pipeline had become measurably harder to silently break.

Trade-offs and pitfalls

A big-bang rewrite is tempting once a real structural problem is visible, but it is harder to review, riskier to ship, and blocks other work longer than an incremental sequence. Sequencing by risk, fixing drift risk before addressing style or readability concerns, matters more than working through the reviewer's comments in the order they were raised. Adding tests only for the specific bug reported, and not for the general class of bug it represents, tends to leave the door open for the next instance of the same category. A pitfall specific to feature pipelines is a regression test with a snapshot that is too broad or too tightly coupled to exact values, since that kind of test breaks, and gets ignored or deleted, on every legitimate data update, so tolerance and scope need to be chosen deliberately.

Direct answer: In both cases the asymptotic time complexity is $O(n)$ and space is $O(n)$ for the output (or $O(1)$ extra if written back in place) - looping over $n$ elements is linear regardless of container type. The practical performance, however, differs by one to two orders of magnitude because a NumPy vectorized operation executes the loop in compiled C over a contiguous memory block, while a Python-level for loop over a list re-enters the Python interpreter for every element.

Structured elaboration

for i in range(n):
    x = arr[i] * 2

(a) Plain Python list: each iteration does a bytecode-level index lookup, a multiplication, an assignment, and a loop-control check, all through the CPython interpreter's eval loop. Each of these steps has real per-element overhead (dynamic type dispatch, reference counting, bounds checking) that a compiled language wouldn't pay. Complexity: $O(n)$ time, with a relatively large constant factor $c_{\text{python}}$.

(b) NumPy ndarray with a vectorized op (arr2 = arr * 2): the multiplication is dispatched once to a compiled C loop (ufunc) that iterates over contiguous memory with no per-element Python overhead, benefiting from CPU-level SIMD instructions and predictable cache access. Complexity: still $O(n)$ time (you still touch every element once), but the constant factor $c_{\text{numpy}}$ is dramatically smaller.

Worked example

Both are $\Theta(n)$, so the ratio of actual runtimes is roughly $c_{\text{python}} / c_{\text{numpy}}$, a constant independent of $n$ (for $n$ large enough to amortize any fixed overhead). Timing this on a representative machine (n = 5{,}000{,}000):

import numpy as np, time

n = 5_000_000
lst = list(range(n))
arr = np.arange(n)

t0 = time.perf_counter()
out = [x * 2 for x in lst]
t_list = time.perf_counter() - t0

t0 = time.perf_counter()
out2 = arr * 2
t_numpy = time.perf_counter() - t0

print(t_list, t_numpy, t_list / t_numpy)

Running this snippet and timing both versions confirms the qualitative claim without needing to trust a specific number: the vectorized version is consistently, dramatically faster (comfortably an order of magnitude or more, driven by interpreter overhead per element versus one dispatch into a compiled loop), and - this is the part worth actually checking - if you double $n$ and re-time both, each individual runtime roughly doubles while their ratio stays about the same. That last observation is the real proof that both are $\Theta(n)$: the growth pattern with $n$ is identical for both, only the constant multiplier differs. Any specific wall-clock multiplier is machine- and Python-version-dependent and should not be treated as a portable fact; the reasoning (interpreter dispatch overhead vs compiled contiguous-memory execution) is what transfers.

Trade-offs & pitfalls

• Never claim vectorization changes the Big-O class - it doesn't; it changes the constant factor, sometimes dramatically, which is exactly why "same asymptotic complexity" and "wildly different real performance" are not contradictory.
• The gap narrows as per-element work grows (if each element required a complex, branchy computation not expressible as a NumPy ufunc, the interpreter-loop version's relative overhead shrinks).
• Never state a specific wall-clock multiplier as a portable fact; only the qualitative order-of-magnitude and the underlying reason (interpreter overhead vs compiled contiguous-memory execution) transfer across machines.