Amazon Data Scientist (Senior Level) - Comprehensive Interview Preparation Guide

Direct answer
Multi-fidelity methods spend a small, cheap "fidelity" (a few epochs, a data subsample) evaluating many configurations, then progressively promote only the top fraction to the next, more expensive rung; Hyperband/ASHA (Asynchronous Successive Halving) schedule this via successive halving with a chosen halving rate, and BOHB (Bayesian Optimization HyperBand) layers Bayesian optimization on top to make smarter choices about WHICH configurations to try in the first place, rather than choosing them randomly.

Structured elaboration
Successive Halving: start with N configurations at a small resource budget (say 1 epoch each); keep only the top 1/eta fraction (commonly eta=2 or 3), double or triple their resource, repeat, until one (or a small number) survives at the full resource budget. Hyperband runs several such brackets with DIFFERENT starting points on the aggressiveness spectrum (some brackets start with more configurations at lower fidelity, others with fewer configurations at higher fidelity), hedging against not knowing in advance the right balance for a given problem. ASHA (Asynchronous Successive Halving) removes the need to wait for an entire rung to finish before promoting, workers asynchronously promote configurations as soon as enough peers at the current rung have reported, which matters a lot for parallel, heterogeneous compute where some trials finish much slower than others. BOHB replaces Hyperband's random initial configuration sampling with a Bayesian-optimization-guided choice, using the growing pool of (configuration, partial-fidelity result) pairs to propose smarter candidates for the next bracket.
The trade-off: aggressive early pruning (a low eta, meaning you keep only a small fraction each rung) saves the most compute but has the highest risk of discarding a configuration whose learning curve starts slow but eventually overtakes the early leaders (a real phenomenon: some architectures or learning-rate schedules have a slow warm-up before they pull ahead). A less aggressive schedule (higher eta, keeping more configurations longer) hedges against that risk at the cost of spending more compute on ultimately-losing configurations.

Worked example
Tuning 64 configurations with a max budget of 32 epochs and eta=2: successive halving would evaluate all 64 at 1 epoch, keep the top 32, evaluate at 2 epochs, keep the top 16, and so on, reaching a single survivor around 32 epochs, having spent roughly 64x1 + 32x2 + 16x4 + ... epoch-equivalents total, dramatically less than 64x32 if every configuration had been run to completion.

Trade-offs & pitfalls
This mechanism assumes early-fidelity performance is at least weakly predictive of final performance, an assumption that can genuinely fail (e.g. a learning-rate schedule with a long warm-up period, or a regularization technique whose benefit only shows up after many epochs); when you suspect that failure mode for your specific problem, either raise eta (less aggressive pruning) or fall back to Bayesian optimization at full fidelity for the final refinement.

Best design for this problem

I would treat the customer table as a history table with effective start and effective end dates for each segment record. That makes the join logic much safer than trying to guess which duplicate row is current.

Table design

• CustomerID
• Segment
• StartDate
• EndDate

Each order then matches the row where the customer matches and the order date falls inside the effective date range.

Formula approach

=IFERROR(
  INDEX(CustomerHistory[Segment],
    MATCH(1,
      (CustomerHistory[CustomerID]=[@CustomerID]) *
      (CustomerHistory[StartDate]<=[@OrderDate]) *
      (CustomerHistory[EndDate]>[@OrderDate]),
    0)
  ),
"Unknown")

Why this works

• It handles customers who change segments over time.
• It avoids accidental matches to the wrong historical record.
• It gives a clean fallback when no record exists.

If I wanted a simpler model

• I would use Power Query to merge orders to the customer history table and filter by the date range.
• That is often easier to audit than a very long formula.

If there are duplicate history rows with the same date range, I would fix the source data first, because the lookup should not guess between conflicting records.

Direct answer

CPython (the standard, C-implemented Python interpreter most people mean when they say "Python"; other implementations, like PyPy, are free to manage memory differently, which matters here since the guarantees below are implementation-specific, not language-mandated) is what actually manages memory: its primary strategy is reference counting, every object carries a count of how many references point to it, and the moment that count hits zero, the object is freed immediately and deterministically. Reference counting alone cannot reclaim a reference cycle (two or more objects that reference each other, directly or through a chain, with no reference from outside the cycle), because every object in the cycle always has a count of at least one from another object inside the cycle, so it never reaches zero on its own. CPython adds a separate generational cyclic garbage collector (GC) specifically to find and reclaim these cycles by tracing reachability from program roots rather than counting references. As of Python 3.4 (PEP 442), objects in a collected cycle that define __del__ are finalized safely by the cyclic GC and then reclaimed like any other cycle; this is a change from older Python (2.x and early 3.x), where such objects could not be safely finalized and were left permanently uncollected in gc.garbage instead.

Structured elaboration

Reference counting, the default path: every PyObject has a refcount field. Assigning a reference increments it; deleting a name, rebinding it, or a scope ending decrements it. When it reaches zero, __dealloc__ runs immediately, memory is freed right away, not on some later pass. This is why most Python objects are reclaimed promptly and predictably.

Why cycles defeat it: consider two objects, A and B, where A.other = B and B.other = A. Even after every external name pointing at A and B is deleted, A still has a reference from B and B still has a reference from A. Neither refcount ever drops to zero, so neither is freed by reference counting alone, even though nothing outside the pair can reach either of them anymore.

The generational cyclic GC: CPython tracks container objects (things that can hold references to other objects, such as lists, dicts, and most user-defined class instances; simple scalars like int, str, and bytearray are never cycle-tracked because they cannot reference anything else) across three generations (0, 1, 2). New objects start in generation 0; objects that survive a collection are promoted to the next generation. Younger generations are scanned more often, since most garbage dies young, older generations less often, since long-lived objects are less likely to become garbage. A collection pass finds groups of objects that are unreachable from any root except each other, and reclaims the whole group at once.

__del__ in cycles, before and after PEP 442: in Python versions before 3.4, the cyclic GC could not safely decide the order to call __del__ on multiple objects in a cycle (finalizing A might need B to still be valid, and vice versa), so it refused to guess and instead moved such cycles into gc.garbage, where they sat uncollected until the program handled them manually or exited. Since Python 3.4, __del__ (technically tp_finalize) is called safely as part of collecting the cycle, each object's finalizer runs at most once, and the objects are then reclaimed normally. gc.garbage in modern Python is essentially always empty in practice; it is no longer where finalizer-bearing cycles routinely end up.

Worked example

Verified on CPython 3.12, confirming both that a cycle with __del__ finalizes correctly and that gc.garbage stays empty:

import gc

class Node:
    def __init__(self, name):
        self.name = name
        self.other = None
    def __del__(self):
        print(f"__del__ called for {self.name}")

a = Node("a")
b = Node("b")
a.other = b
b.other = a          # a <-> b: a reference cycle
del a, b              # neither refcount reaches zero; both still ref each other

found = gc.collect()  # cyclic GC finds and reclaims the unreachable cycle
print("objects collected:", found)
print("gc.garbage:", gc.garbage)

Output:

__del__ called for a
__del__ called for b
objects collected: 8
gc.garbage: []

Both finalizers ran and gc.garbage came back empty, confirming that on current Python, a __del__-bearing cycle is not stuck the way it would have been on Python 2 or early Python 3.

Trade-offs & pitfalls

• The most common outdated claim (worth actively correcting if you have older reference material in mind): "a reference cycle with __del__ cannot be garbage collected." That was true pre-3.4 and is no longer true; citing it as a current fact is a dated answer in an interview.
• gc.garbage is not gone as a concept, it can still be non-empty in rarer cases, for example if a __del__ call itself raises an exception during finalization (the exception is reported but the object may not finalize cleanly), or with certain legacy C extension types that predate safe finalization support.
• Edge case: relying on __del__ for anything time-sensitive (closing a file, releasing a lock) is risky even now, because a cycle is only reclaimed when the generational GC actually runs a collection on the generation holding it, which is not immediately after the last external reference disappears, the way pure reference counting is. Prefer explicit close() methods or context managers over relying on __del__ timing.
• Complexity: reference counting overhead is $O(1)$ per assignment/deletion, paid continuously; a generational GC pass costs $O(\text{live objects in that generation})$, paid periodically rather than per-operation, which is the whole point of only tracing occasionally instead of tracing on every reference change.
• gc.disable() removes the periodic cyclic-collection cost entirely and can help latency-sensitive code that allocates heavily and rarely forms cycles, but it means genuine cycles accumulate unreclaimed until you call gc.collect() yourself, trading a latency win for a memory-growth risk that has to be managed deliberately.

Direct answer: Formulate this as: minimize the variance of the interaction-effect estimator, $\text{Var}(\hat{\theta}_{AB}) = \sum_{i=1}^{4} \sigma_i^2/n_i$ (the four-cell +1/-1/-1/+1 contrast estimator's variance, assuming independent cells with per-cell variance $\sigma_i^2$), subject to a total-cost budget constraint $\sum_i c_i n_i = B$, where $n_i$ (the sample size in cell i) are the decision variables, $c_i$ the known per-user cost or complexity weight of cell i, and B the fixed budget.

Deriving the allocation rule: using a Lagrangian, $L = \sum_i \sigma_i^2/n_i + \lambda\left(\sum_i c_i n_i - B\right)$, setting $\partial L/\partial n_i = -\sigma_i^2/n_i^2 + \lambda c_i = 0$ gives $n_i \propto \sigma_i/\sqrt{c_i}$: allocate MORE sample to cells that are noisier (higher $\sigma_i$) and LESS to cells that are more expensive (higher $c_i$), the classic Neyman-allocation rule generalized to cost-weighted variance minimization.

Worked numeric example (executed): suppose all four cells have the same outcome variance ($\sigma_i=0.14$ for all i, e.g. a conversion-rate-like metric), but cell 4 (both treatments simultaneously on) is 5x costlier per user, for instance because it requires manual QA/concierge support, so $c = [1, 1, 1, 5]$, budget B = 400,000 cost-units.

• EQUAL allocation (n=50,000 in every cell, spending the budget evenly): $\text{Var}(\hat{\theta}_{AB}) = 1.568 \times 10^{-6}$.
• NEYMAN-OPTIMAL allocation ($n_i \propto \sigma_i/\sqrt{c_i}$): n* = [76,393, 76,393, 76,393, 34,164] (budget check: $\sum c_i n_i^* = 400{,}000$, exact), giving $\text{Var}(\hat{\theta}_{AB}) = 1.343 \times 10^{-6}$.

That is a 14.3% variance reduction versus equal allocation for the SAME total cost budget, purely from shifting sample away from the expensive cell 4 toward the three equally-noisy, cheaper cells.

Practical simplifications: (1) if per-cell variances are genuinely similar (the common case for conversion-rate-like metrics with similar baseline rates), the allocation collapses to pure cost-weighting, $n_i \propto 1/\sqrt{c_i}$, which is easy to compute without needing pilot-data variance estimates; (2) if BOTH cost and variance vary substantially and in the SAME direction (e.g. the noisier cell is also the pricier one), the two effects partially cancel and the gain from optimizing over equal allocation shrinks, in a version of this example with cell 4 at both 3x cost AND roughly 2x the SD, the improvement dropped to about 1%, so it is worth checking numerically rather than assuming Neyman allocation always helps a lot; (3) in practice, run this as a one-time pre-launch calculation using pilot-period variance and known engineering-cost estimates, not as a live-adjusting allocation, since re-allocating traffic mid-experiment reintroduces the kind of assignment-pipeline risk the sibling topic's A/A-test validation content is designed to catch.

Operating models for data science:

Central platform team:

• Definition: A dedicated centralized team builds tools, pipelines, shared models, governance, and provides analytics as a service to product teams.
• Strengths: Standardization, economies of scale, strong governance, faster cross-project reuse.
• Weaknesses: Potentially slow to respond to product needs, risk of being perceived as a service bottleneck.

Embedded teams in product squads:

• Definition: Data scientists sit inside product teams, owning metrics, experiments, and models for that product.
• Strengths: Close to domain, high velocity, tight feedback loops, better product alignment.
• Weaknesses: Duplication of work, inconsistent standards, harder to share expertise.

Hybrid model:

• Definition: Central team provides platform, tooling, governance and specialist expertise; embedded DS handle product-specific work.
• Strengths: Balances speed and consistency; enables reuse and product alignment.
• Weaknesses: Requires clear boundaries, investment in communication and APIs.

Recommendation:

• Fast-scaling startup: Start with embedded DS (or generalist central small team that embeds temporarily) to prioritize speed and product-market fit. Move to hybrid as headcount and number of products grow.
• Established enterprise: Hybrid is ideal — central platform for governance/compliance and cost efficiency, embedded DS for domain knowledge and delivery. Pure centralization works only for analytics-heavy orgs with stable priorities.

Transition considerations:

• Define clear responsibilities (RACI) between central and embedded teams.
• Invest in shared tooling (feature stores, model registry, CI/CD) and documentation.
• Create SLAs and intake processes to avoid bottlenecks.
• Hire or rotate "platform liaisons" to bridge teams.
• Start small: pilot hybrid with one domain, measure reuse, latency, and business impact, then iterate.

Direct answer

When rider wait time, platform revenue, and driver earnings genuinely pull against each other and each has its own stakeholder, the right move is to make the trade-off explicit and negotiated rather than letting a single team's optimization implicitly decide it, since whoever builds the system otherwise ends up making a policy choice that isn't theirs to make alone.

Structured elaboration

1. Make the conflict visible first. Show stakeholders concretely how the three objectives move against each other (a change that improves one measurably worsens another), rather than presenting a single blended number that hides the trade-off.
2. Establish who has a legitimate stake in each objective. Wait time affects the rider-facing team's goals, revenue affects the business's financial targets, and driver earnings affect driver retention and the marketplace's long-term health; each deserves a real voice in setting the trade-off, not just the team that happens to own the system.
3. Represent the trade-off explicitly rather than burying it in one score. Set minimum acceptable floors for each objective (driver earnings can't drop below X, wait time can't exceed Y) and optimize the remaining objective within those floors, rather than a single weighted blend that can quietly sacrifice one objective for the others without anyone deciding to.
4. Defend the landing point with the actual reasoning, not just the number. When the objectives genuinely conflict and a choice has to be made, document why that specific point was chosen and who signed off, so it's a deliberate business decision, not an artifact of whichever loss function the modeling team picked.

Worked example

Setting a floor on driver earnings (a per-hour minimum the system will not optimize below) while allowing wait time and revenue to trade off against each other within that floor turns an implicit three-way optimization into an explicit two-way trade-off with one protected constraint, which is usually easier for stakeholders to reason about and agree to than a single blended score they can't easily interpret.

Trade-offs and pitfalls

The common mistake is letting the engineering team pick the weights or floors unilaterally because "someone has to," when the actual business trade-off deserves an explicit decision from the people accountable for each objective. The other risk is setting floors so conservatively that the system has little room left to optimize anything, which can make the whole exercise pointless; the floors need real business input, not just a defensive default.

Direct answer
try marks a block whose exceptions you want to intercept; except runs only if a matching exception is raised inside the try; finally always runs, whether or not an exception occurred and whether or not it was caught, and it runs even if the exception propagates past this block entirely.

Structured elaboration

• No exception: the try block runs to completion, every except clause is skipped, then finally runs. Nothing unusual happens.
• Exception raised and caught: execution jumps out of the try block the instant the exception is raised (any code after the raising line in try does NOT run), the first matching except clause runs, then finally runs.
• Exception raised and NOT caught (no except clause matches its type): the matching-except search fails, finally still runs (this is the part people get wrong: finally is not conditional on being caught), and only after finally completes does the exception continue propagating up to the caller.
• The consequence that matters in practice: finally is the correct place for resource cleanup that must happen unconditionally, closing a file handle, releasing a lock, rolling back a partially-started operation, precisely because it is the one block guaranteed to run on every exit path from the try.

Worked example

def no_exception():
    order = []
    try:
        order.append('try')
    except ValueError:
        order.append('except')
    finally:
        order.append('finally')
    return order

def caught_exception():
    order = []
    try:
        order.append('try')
        raise ValueError('boom')
    except ValueError:
        order.append('except')
    finally:
        order.append('finally')
    return order

Running both (verified): no_exception() returns ['try', 'finally'] (the except clause never runs), caught_exception() returns ['try', 'except', 'finally']. A third case with a TypeError raised where only ValueError is caught confirms finally still runs before the TypeError propagates out to the caller, exactly as described above.

For the file-I/O case, opening a file and guaranteeing it closes even on a mid-read failure:

def read_lines(path):
    f = open(path, 'r')
    try:
        return f.readlines()
    finally:
        f.close()   # runs whether readlines() succeeds, raises, or the caller's except re-raises

This is exactly what a with open(path) as f: block (or Java's try-with-resources) does under the hood, they are sugar over a try/finally that closes the resource. In this pattern, whether to re-raise the error after logging it or return a sentinel value to the caller depends on whether the caller can meaningfully continue: propagate (let the exception continue, possibly after logging) when the caller cannot proceed without the data; return a sentinel only when the caller has a genuine, documented fallback.

Trade-offs & pitfalls
The most common mechanical mistake is assuming finally only runs when an exception was caught, when in fact it runs on every exit from try (normal completion, caught exception, uncaught exception, even a return inside the try block). The second most common mistake is putting cleanup code after the try/except instead of in finally, which silently skips cleanup on any path that doesn't hit that exact line, exactly the bug that finally exists to prevent.

Direct answer. Segmentation and cohort analysis both slice a population, but along different axes. Segmentation cuts users by a shared attribute observed at (or near) the moment you look, such as platform, plan, or geography. Cohort analysis groups users by a shared starting event, such as signup week or first purchase date, and then tracks that group's behavior forward through time. Segmentation answers "who looks different right now"; cohort analysis answers "how does behavior evolve after a shared starting point."

Structured elaboration.

• Segmentation is a snapshot cut. A user's segment membership can change over time (a free-tier user upgrades to paid), and segmentation is typically used to compare groups at the same point in time to explain a difference in a current metric.
• Cohort analysis is a longitudinal cut. Membership in a cohort is fixed at the moment the cohort is defined (everyone who signed up in the week of March 3rd stays in that cohort forever), and the analysis tracks the cohort's metric (retention, revenue) as a function of time since the anchor event, not calendar time.
• The two combine naturally: you can segment cohorts (compare the week-4 retention curve of the March signup cohort broken out by acquisition channel), which is why interviewers sometimes ask for "both."

Worked example. A product question best answered by segmentation: "Is our checkout conversion rate lower on mobile than on desktop this month?" You compare two attribute-defined groups at the same point in time; no notion of an anchor event is needed. A product question best answered by cohort analysis: "Did the onboarding redesign we shipped in March improve 4-week retention compared to users who joined before the change?" Here the anchor event (signup date, which falls before or after the redesign) is the whole point, and you are comparing how retention evolves over the weeks after that anchor, not a single snapshot.

Trade-offs and pitfalls. A common junior mistake is comparing cohorts as if they were segments, for example comparing "this week's active users" to "last week's active users" as if that were a cohort comparison. It isn't: unless you fix the starting event, you are not controlling for how long each user has had to convert or churn, and any difference could simply reflect cohort maturity rather than a real behavior change. The reverse mistake is trying to segment inside a single cohort snapshot when the real question is longitudinal, which throws away the time-since-anchor signal that would explain the pattern.

Both forms filter to the same rows; the difference is readability and, in a few dialects, how the optimizer treats a long list.

Structured elaboration

WHERE category IN ('electronics', 'appliances', 'furniture') and WHERE category = 'electronics' OR category = 'appliances' OR category = 'furniture' are logically equivalent. IN is shorter and scales better as the list grows; a 20-value OR chain is genuinely hard to scan. Most optimizers treat IN over a short literal list identically to the OR chain (both typically become an index range scan or a series of equality lookups), so there's no reliable performance edge for large literal lists, though very large IN lists (thousands of values) can behave differently across engines and are sometimes better served by a temp table or VALUES join.

Worked example

Given products(product_id, name, category) with categories electronics, appliances, furniture, and toys, both forms return the first three products and exclude the toys row.

Trade-offs and pitfalls

IN is the standard choice for a fixed list. Watch for the NULL trap, though it's sharper for NOT IN than for plain IN: column NOT IN (subquery) silently returns ZERO rows for the ENTIRE query if the subquery can return even one NULL, because x <> NULL evaluates to UNKNOWN for every row's comparison against that NULL, and NOT IN needs every comparison in its OR-chain to be definitively TRUE to include a row; one UNKNOWN poisons the whole chain to UNKNOWN (never TRUE), so nothing is ever returned, not even values that clearly aren't in the list. Plain column IN (subquery), by contrast, is not similarly poisoned: a NULL in the list only affects rows that don't match any real value anyway, and those rows are excluded either way (UNKNOWN and FALSE are both "not included" in a WHERE clause), so IN with a NULL in the list returns exactly the same rows as IN without one. The guard, when it matters, is the same either way: filter the subquery explicitly (... WHERE customer_id IS NOT NULL) or use NOT EXISTS/EXISTS, which never has this problem because it tests row existence rather than comparing against a list of values. For a dynamically-sized list supplied by an application, prefer parameterized array binding or a values join over string-concatenating an IN list.

Direct answer. INTERSECT returns only the rows that appear in BOTH result sets. EXCEPT (MINUS in Oracle) returns the rows that appear in the FIRST result set but not the second. Both compare whole rows, need the same number of columns with compatible types on each side, and both dedup their output.

Structured elaboration. Think of them as set arithmetic over two same-shaped result sets rather than as joins: there's no join key to specify, the entire row IS the comparison unit. That makes them a natural fit for comparing two snapshots or two populations directly, without writing an explicit join condition.

Worked example. customers_2023(customer_id): 1, 2, 3. customers_2024(customer_id): 2, 3, 4.

-- customers present in BOTH years (returning customers)
SELECT customer_id FROM customers_2023
INTERSECT
SELECT customer_id FROM customers_2024;
-- returns 2, 3

-- customers present in 2023 but not 2024 (lost customers)
SELECT customer_id FROM customers_2023
EXCEPT
SELECT customer_id FROM customers_2024;
-- returns 1

Trade-offs and pitfalls. Both operations dedup by default (like UNION, not UNION ALL), so if you need to know HOW MANY TIMES a row appeared rather than just whether it appeared, INTERSECT/EXCEPT are the wrong tool and you need an explicit join or GROUP BY instead. NULLs in the compared columns are handled specially: unlike an ordinary equality comparison, most engines treat two NULLs in the same position as equal for the purposes of this row comparison, which is the opposite of how NULL behaves in a join predicate, and is a common source of confusion when you've internalized "NULL never equals NULL" from working with joins.