Lyft AI Engineer Interview Preparation Guide - Junior Level

Direct answer

Downstream accuracy dropping after a dataset merge, with no model code change, points squarely at the DATA: the systematic investigation should compare feature distributions before and after the merge, check for row duplication or fan-out from the join, and verify the merge key itself matched as intended, before looking anywhere else.

Structured elaboration

Systematic investigation plan:

1. Row-count sanity check first: did the merge produce the expected number of rows? A one-to-many join that was intended to be one-to-one silently duplicates rows, which can shift class balance, feature distributions, and effectively give some examples more "votes" during training than intended.
2. Compare feature distributions pre- and post-merge: for every feature that came from (or was affected by) the newly-merged data, compare summary statistics and, ideally, full distributions (histograms, or a Kolmogorov-Smirnov test comparing the two distributions statistically) before and after; a meaningful shift in a feature's distribution that has nothing to do with a real change in the underlying population is a strong signal the merge introduced something unintended.
3. Verify the join key: check for a subtle mismatch (a key that should be an exact string match but has whitespace or casing differences in one of the two tables, causing unexpected non-matches that silently become nulls after the join, or unexpected multi-matches).
4. Unit tests and a shadow run: add an assertion checking the expected row count and null rate immediately after the merge step in the pipeline, and run the NEW merged pipeline in shadow mode (compute its outputs without deploying them) against the OLD data source in parallel, diffing the two feature sets row-by-row to localize exactly which columns and which rows changed.
5. Communicate the finding: once localized, report concretely: which columns changed, by how much, for what fraction of rows, and the most likely root cause (a key-matching issue, an unintended fan-out, a schema change in one of the source tables), rather than a vague "the merge caused it."

Worked example

If the pre-merge dataset had 100,000 rows and the post-merge dataset has 118,000, a fan-out from a one-to-many join is immediately suspected; grouping by the original primary key and counting post-merge rows per key quickly confirms whether some keys are duplicating (say, a customer with multiple addresses in the joined table, each producing a separate output row when only one was intended).

Trade-offs and pitfalls

The reason "no change to the model code" is a red herring, not evidence the model is somehow at fault: a model retrained on distributionally-shifted input data (from an unintended fan-out, or a feature that's now null more often due to a key-matching gap) will genuinely perform differently even with byte-identical training code, so the investigation should treat the merge itself as the prime suspect from the start rather than re-auditing the model.

Direct answer

Tracking visited state is what turns a graph traversal from something that can loop forever on a cycle into something guaranteed to terminate; the choice of mechanism (in-memory set, color marking, parent pointers, persisted marking, bitsets, or a probabilistic structure) is really a trade between memory footprint, durability across restarts, and concurrency safety, not a correctness choice, since any of them is correct if applied consistently.

Structured elaboration

In-memory visited set (a hash set of node ids). O(1) expected membership checks, simplest to reason about. Cost: memory grows linearly with the number of visited nodes, and everything is lost if the process crashes mid-traversal.

Color marking (white, gray, black), the classic depth-first search bookkeeping. White means undiscovered, gray means discovered but its subtree is still being explored, black means fully finished. This is strictly more informative than a plain visited set: a gray node currently on the call stack signals "in progress," which is exactly what lets you detect a back edge (an edge into a gray node) and therefore a cycle. A plain boolean visited set cannot distinguish "in progress" from "finished," so it cannot support cycle detection on its own.

Parent pointers. A small map from each node to the node that discovered it. Adds only O(1) extra state per node but enables reconstructing the actual path (not just "was this reachable"), which a bare visited set cannot do.

Persisted marking (a database column or table). Trades speed for durability: a traversal can survive a process crash and resume, and multiple worker processes can share visited state. The cost is added latency per check (a round trip instead of a hash lookup) and the need for transactional or optimistic-concurrency semantics so two workers do not both claim the same unvisited node and duplicate work, or worse, disagree about which one "owns" it.

Bitsets. One bit per node id, extremely compact and cache-friendly when node ids are dense integers in a known range. Poor fit when ids are sparse, non-integer, or the range is unknown ahead of time, since you either waste space over-allocating for the theoretical max id or need an id-to-index remapping layer.

Probabilistic structures (Bloom filters). A Bloom filter answers "have I possibly seen this node" with no false negatives but a tunable false-positive rate; it uses far less memory than an exact set for large node counts. The trade is real: a false positive means the traversal SKIPS a node it has not actually visited yet, silently under-exploring the graph. This is only acceptable when occasional missed nodes are tolerable (for example, an approximate reachability estimate) or when a Bloom-filter "maybe visited" result is always followed by a cheap authoritative check before being trusted.

Worked example

Consider a backend service that persists a large dependency graph in a relational database and needs to run reachability queries against it. Three concrete options, same graph, different constraints:

• Ad hoc single request, small subgraph: in-memory hash set. The traversal starts and finishes within one request; there is nothing to persist and nothing to coordinate.
• Long-running batch traversal over millions of nodes, must survive a deploy or crash: persisted marking, a visited_at timestamp column updated via an atomic compare-and-set ("claim this node if visited_at IS NULL"), so a restarted worker picks up exactly where an earlier one stopped, and two concurrent workers cannot both claim the same node.
• Interactive approximate "is this node probably already covered" check across a huge, mostly-static graph, where an occasional false positive is acceptable and always followed by a real check before acting on it: a Bloom filter sized for the expected node count and a target false-positive rate (say 1%), rebuilt periodically as the graph changes.

Trade-offs and pitfalls

• In-memory vs. persisted is fundamentally a durability and sharing trade, not a speed trade alone: in-memory is faster per check but confined to one process and ephemeral; persisted is durable and shareable across workers but every check now costs a network or disk round trip unless you layer a cache in front.
• Concurrency for persisted visited state needs an explicit protocol, not just "check then write": two workers checking the same unvisited node at nearly the same time can both decide to process it unless the claim step is atomic (compare-and-set, a lease with expiry, or a distributed lock). Idempotent processing (safe to redo a node's work if a duplicate claim slips through) is a cheaper fix than perfect locking in many systems.
• Common mistake: using a plain visited set when the actual requirement is cycle DETECTION, not just termination; a set alone tells you "seen before," not "currently on the path back to me," which is the distinction color marking exists to capture.
• Common mistake: reaching for a Bloom filter as a default memory optimization without checking whether the algorithm can tolerate its false positives; silently skipping a not-yet-visited node is a correctness bug, not a performance one, in most traversal use cases.
• Hybrid approach worth naming: keep an in-memory cache of the hot frontier (nodes actively being expanded) backed by periodic checkpoints to persisted storage; this gets most of the speed of in-memory tracking with a bounded amount of resumability if the process dies.

Direct answer
A learning curve plots error against training-SET SIZE at fixed model settings; a validation curve plots error against a single HYPERPARAMETER's value at a fixed training-set size. They answer different questions: "would more data help?" versus "is this hyperparameter set well?"

Structured elaboration
For ridge regression, a validation curve sweeps the regularization strength (alpha) from very small to very large, plotting training and validation error at each value. At very small alpha, the model is nearly unregularized: training error is low (near zero if the model can interpolate the training set), validation error is higher (overfitting end). As alpha increases, both errors rise, and validation error typically dips to a minimum before rising sharply as alpha grows large enough to force coefficients toward zero (underfitting end, since the model is now too constrained to fit even the true signal). The alpha at that validation-error minimum is the value you'd read off as the good choice.

Worked example
On a synthetic regression dataset (120 samples, 80 features, 15 truly informative, noise std 25, split 72 train / 48 validation), sweeping alpha across [0.001, 0.01, 0.1, 1, 10, 100, 1000, 10000] with scikit-learn's Ridge gave: train MSE of 0.0 at alpha=0.001-0.01 (the model has more features than training rows here, so it interpolates), rising to 30.1 at alpha=1, 910.5 at alpha=10, 11,639.8 at alpha=100, and 48,009.5 at alpha=10000. Validation MSE was 8,399.9 at alpha=0.001, dipped to a minimum of 8,376.0 at alpha=0.1, then rose to 8,892.0 at alpha=1, 14,649.6 at alpha=10, 34,667.9 at alpha=100, and 59,040.7 at alpha=10000. The minimum validation MSE sits at alpha=0.1, right where training and validation error are still close together, before the gap widens (overfitting easing) and then both errors climb together (underfitting) at high alpha; alpha=0.1 is the value you'd read off from this curve.

Trade-offs & pitfalls
It's easy to confuse the two curve types when skimming a plot quickly; always check the x-axis label. A validation curve tells you nothing about whether more DATA would help, only whether the current hyperparameter is well chosen for the data you have. Also, the exact location and depth of the minimum is dataset-specific (dimensionality, noise level, and how many features are truly informative all shift it), so don't treat any single sweep's numbers as universal, always regenerate the curve on your own data.

Direct answer
Build the rubric around whether the writing actually works for its reader: does it state its point clearly, fit the audience it's for, give the reader something to do with it, and use a tone appropriate to its purpose, then justify each criterion by what a failure on it costs the reader.

Structured elaboration
Proposed criteria, with the reasoning for each:

1. Clear main point: can a reader state the document's core message in one sentence after reading it? Justification: this is the single biggest failure mode in unclear writing, so it anchors the rubric.
2. Appropriate structure: does the important information come early, with supporting detail after, rather than requiring the reader to read to the end to find the point?
3. Audience fit: is the level of jargon and assumed background knowledge appropriate for who's actually going to read this, rather than written for the author's own level of familiarity?
4. Concision: is there padding, hedging, or restatement that could be cut without losing meaning?
5. Actionable next step: if the document implies an action or a decision, is that action stated explicitly, rather than left for the reader to infer?
6. Precision: are claims specific and checkable, or do vague quantifiers stand in for actual numbers where numbers were available?
7. Tone fit: is the tone appropriate to the stakes and relationship, neither over-casual for a high-stakes audience nor needlessly formal for a quick internal note?
8. Honesty about caveats: does the document surface real limitations or risks, rather than smoothing them over to look cleaner?

Worked example
Applying this to a short vendor-status email: main point ("vendor is delayed two weeks") is clear in the first sentence; structure is fine; audience fit is appropriate (no unnecessary jargon for a business reader); concision is good at three sentences; the next step (approve a revised deadline) is explicitly stated; precision holds (a specific date is given, not "soon"); tone is appropriately direct without being alarmist; and the caveat (a small risk of a further one-week slip) is honestly included rather than hidden. That's 8 for 8, which is a genuinely well-written status update by this rubric.

Trade-offs and pitfalls

• A rubric with too many criteria becomes tedious to apply consistently; six to eight, as here, is usually enough to catch the failure modes that matter most without turning review into a lengthy checklist exercise.
• Some criteria trade off against each other (concision versus caveats, for instance); the rubric should make clear that cutting a genuine caveat to satisfy concision is a failure, not a win, on this rubric.
• A rubric like this works best as a discussion tool during review, not as a rigid pass/fail gate; a document can reasonably fail one criterion (say, tone) for a good reason specific to its context.

Direct answer

Frame the move as pursuit of something specific this role has that your current one doesn't (scope, problem type, company stage, technical depth), stated in one sentence, and keep any negative context brief, factual, and forward-looking. The interviewer is listening for whether you'll badmouth an employer and whether "why now" has a real trigger or is just restlessness.

The framework

1. Name the pull factor first and make it specific to this role, not generic ("growth", "new challenges" with no content). Tie it to something concrete this role offers that you can point to in the JD or your research.
2. If there's a push factor (something about the current role or company driving the move), state it once, factually, without editorializing, then pivot immediately back to the pull factor. One sentence of push, several of pull.
3. Address timing directly if asked "why now." A real trigger (a reorg, a role plateau, a personal milestone, a deliberate stage-of-career move) reads as intentional; "I've just been thinking about it" reads as drift.
4. If you've already left your current role (the past-tense framing, "why did you leave"), the structure is identical; narrate in past tense and be ready to state how long you've been searching and why.

Worked example

I've spent [timeframe] at my current company, where I [one concrete accomplishment, no invented precision]. The next step I want is [specific pull factor, e.g. "to own a problem end-to-end instead of a slice of one", or "to work at a different scale or stage"]. My current role doesn't have that path available in the near term: [one factual sentence, e.g. "the team's scope has been fixed for the last year and isn't expanding"]. That's what made now the right time to look, and this role's [specific JD detail] is exactly that next step.

(Domain swap: a Systems Administrator might cite wanting to move from maintenance-heavy scope to architecture input; a Product Manager might cite wanting ownership of a full product line rather than a feature area.)

Trade-offs and pitfalls

• Naming a specific person (a manager, a colleague) as the reason for leaving is a red flag to interviewers even when true; keep it at the structural or role level.
• Leading with the push factor and spending most of the answer on it reads as bitterness, regardless of how justified; keep push to one sentence and let pull dominate.
• "Why now" with no real trigger is weaker than a specific one, even a small one (a project wrapped up, a milestone passed).
• If compensation or location is a real driver, it's fine to be honest about it as one factor, but pair it with a substantive reason too; comp-only answers read as mercenary regardless of how common the real motivation is.

Framework: turn requests into scored items and solve a constrained optimization (knapsack-like) to maximize total expected value under instructor-hour and budget limits.

Required inputs (per request):

• Expected Impact (I): estimated business value score (0–100) or expected KPI lift %
• Urgency (U): deadline or time-sensitivity score (0–100)
• Readiness (R): how prepared the team is (infra, data, participants) (0–100)
• Cross-team Benefit (C): number of additional teams/likelihood of reuse (0–100)
• Cost: instructor hours and monetary cost
• Dependencies: must-run-before or after constraints
• Uncertainty: confidence interval or probability p of achieving impact

Scoring & weighting:

• Normalize each metric to 0–1. Compute an expected-value score:
  Score = p * (wI * I + wU * U + wR * R + wC * C)
• Suggested initial weights: wI=0.45, wC=0.25, wR=0.2, wU=0.1 (prioritize impact and reuse; tune later)
• Apply penalty for low readiness: multiply Score by (1 - alpha*(1-R)) to avoid spending on unprepared teams
• Use Score/Cost (value per hour) as ranking metric.

Optimization:

• Solve 0/1 knapsack maximizing sum(Score) subject to total hours ≤ H and budget ≤ B; incorporate dependencies via precedence constraints. Use greedy for large N (by Score/Cost) and ILP for exact optimal.

Validation & refinement:

• Track outcomes post-training: realized KPI change, attendance, follow-up adoption rate. Compute realized_value and compare to predicted Score to get calibration factor.
• Use Bayesian updating: update p and w* based on observed errors (e.g., reduce weight on I if systematically overestimated).
• A/B test: randomly allocate a small fraction of slots to lower-scoring requests to measure underestimated potential.
• Periodically (quarterly) re-fit weighting via regression: realized_value ~ wII + wUU + wRR + wCC to minimize prediction error.

Governance & practicalities:

• Keep transparent scoring rubric; allow requesters to supply evidence for each input.
• Cap per-team hours to ensure breadth.
• Provide “readiness bootcamps” for low-R teams to convert them into viable candidates.

This approach balances expected impact with cost, accounts for uncertainty, enforces constraints, and continuously improves with real outcome data.

Direct answer. Sort once by score and sweep the cumulative TP/FP/FN counts across all candidate thresholds simultaneously, rather than looping over each candidate threshold and rescanning the labels; this turns an O(n · number_of_thresholds) naive sweep into a single O(n log n) pass.

Code (executed and verified below, including a brute-force cross-check).

import numpy as np

def find_best_threshold(probs, y_true, beta=1.0):
    probs = np.asarray(probs)
    y_true = np.asarray(y_true)
    order = np.argsort(-probs)
    probs_sorted = probs[order]
    y_sorted = y_true[order]
    P = y_true.sum()
    tps = np.cumsum(y_sorted)            # TP if we predict positive down to this rank
    fps = np.cumsum(1 - y_sorted)
    fns = P - tps
    precision = np.where(tps + fps > 0, tps / (tps + fps), 0.0)
    recall = np.where(tps + fns > 0, tps / (tps + fns), 0.0)
    b2 = beta ** 2
    denom = b2 * precision + recall
    fbeta = np.where(denom > 0, (1 + b2) * precision * recall / denom, 0.0)
    best_i = np.argmax(fbeta)
    return probs_sorted[best_i], precision[best_i], recall[best_i], fbeta[best_i]

Worked example (recomputed, cross-checked against a brute-force sweep). On 2,000 synthetic points, the sweep above found threshold = 0.4784, precision = 0.7800, recall = 0.8146, F1 = 0.7969. A brute-force loop over every distinct candidate threshold independently found the identical F1 = 0.7969 at the identical threshold, confirming the fast version isn't silently skipping the true optimum.

Structured elaboration. Sorting once costs O(n log n); everything after that (the cumulative sums, the precision/recall/F-beta arrays, and the argmax) is O(n), so the whole routine is O(n log n) rather than the naive O(n · k) you'd get from looping over k candidate thresholds and recomputing precision/recall from scratch at each one. At tens of millions of rows this is the difference between one sort-and-sweep and a job that doesn't finish overnight.

Trade-offs and pitfalls. F-beta with beta > 1 weights recall more heavily than precision (beta=2 is a common choice when missing a positive is costlier than a false alarm); with beta < 1 it's the reverse. The threshold returned is the exact score value of the best-scoring example at the optimal cut, so in production you'd typically predict positive for score >= threshold; make sure the serving code uses the same inequality direction the threshold was chosen with, or you'll silently flip which side of the boundary counts as positive.

Direct answer
Layer Normalization computes each sample's own mean and variance across its feature dimensions (not across the batch), so there is nothing to accumulate across training batches the way BatchNorm's running statistics do; each example is normalized entirely using its own values, at both training and inference time alike.

Structured elaboration
For input $x$ of shape $(N, *\text{features})$, LayerNorm flattens the feature dimensions per sample, computes that sample's own mean $\mu$ and variance $\sigma^2$ across just those features, normalizes, then applies a learnable per-feature gain $\gamma$ and bias $\beta$:

import numpy as np

class LayerNorm:
    def __init__(self, normalized_shape, eps=1e-5):
        self.normalized_shape = (normalized_shape,) if isinstance(normalized_shape, int) else tuple(normalized_shape)
        self.eps = eps
        self.gamma = np.ones(self.normalized_shape, dtype=np.float64)
        self.beta = np.zeros(self.normalized_shape, dtype=np.float64)

    def forward(self, x):
        N = x.shape[0]
        feat_shape = x.shape[1:]
        x_flat = x.reshape(N, -1)
        mean = x_flat.mean(axis=1, keepdims=True)
        var = x_flat.var(axis=1, keepdims=True)
        invstd = 1.0 / np.sqrt(var + self.eps)
        x_norm = ((x_flat - mean) * invstd).reshape((N,) + feat_shape)
        return self.gamma * x_norm + self.beta

Why no running statistics: BatchNorm's running mean/variance exist specifically to give a STABLE, batch-independent estimate at inference, since its normalization is otherwise defined per-BATCH; LayerNorm's normalization is already per-SAMPLE by construction, so it behaves identically at training and inference with no batch dependence to compensate for in the first place, and accumulating a "running" statistic across samples would be meaningless (and would reintroduce the exact batch-dependence LayerNorm was designed to avoid).

Worked example
Run against a random (4, 8) input with $\gamma=1,\beta=0$: every one of the 4 samples' output mean was within $10^{-16}$ of exactly 0 and variance within $10^{-4}$ of exactly 1 (matching the theoretical guarantee for identity gain/bias parameters). Cross-checked against PyTorch's own nn.LayerNorm on the identical input with matching parameters: the maximum absolute difference between this implementation's output and PyTorch's built-in was on the order of $10^{-7}$, confirming the implementation is correct, not merely plausible-looking.

Trade-offs & pitfalls
A common bug is normalizing across the wrong axis, mixing up "per-sample across features" (LayerNorm, correct here) with "per-feature across the batch" (BatchNorm); the two produce a completely different-shaped statistic ($(N,1)$ versus $(1,C)$-style shapes) and getting this backward is the most common implementation error. GroupNorm sits between LayerNorm (normalize over ALL features per sample) and InstanceNorm (normalize over spatial dims per CHANNEL per sample): it splits channels into groups and normalizes within each group per sample, recovering some of BatchNorm's per-channel character while staying fully batch-independent, at the cost of one additional hyperparameter (the number of groups) to choose.

Direct answer: A production feature-store architecture at real scale needs a dual-store design (a batch-optimized offline store and a latency-optimized online store) fed by both batch and streaming ingestion, unified behind a serving API and a shared metadata/lineage layer, with the hardest engineering constraint being keeping the two stores consistent, not building either one in isolation.

Structured elaboration:

• Ingestion: batch jobs for slow-changing, high-volume sources (a nightly warehouse ETL); streaming jobs (a framework like Flink or Spark Structured Streaming) for features that need near-real-time updates.
• Offline store: a columnar warehouse or data lake table, optimized for large scans over history for training-set construction; this is where point-in-time-correct joins between features and labels happen.
• Online store: a low-latency key-value store (in-memory or a fast KV database), optimized for single-entity lookups under sub-50ms targets at high query volume.
• Materialization: the job(s) that populate both stores from the same underlying transformation logic, so the two stores are two VIEWS of one computation, not two independent implementations.
• Serving API: the client-facing interface (see the client-library-API question elsewhere in this topic) that abstracts which store is being read.
• Versioning and lineage: every feature value traceable to the code and data version that produced it.
• Access control: role-based restrictions, particularly for personally-identifiable-information (PII)-adjacent features.

Worked example: A recommendation model needs both batch-computed features (a user's lifetime purchase history, updated daily and used heavily in training) and low-latency online features (what the user clicked in the last 5 minutes, needed for real-time re-ranking). The architecture computes both from the same event stream: the streaming path continuously updates the online store for the fast-moving signals, while a batch job periodically materializes the offline store's historical snapshots for training, and both derive from the same underlying transformation definitions so a change to the feature's logic updates both paths together rather than requiring two separate code changes.

Trade-offs and pitfalls: The single most consequential design decision is technology choice at each layer (which key-value store, which warehouse format), and the trade-offs are genuinely workload-specific: a KV store optimized for point lookups is a poor fit for the offline store's scan-heavy access pattern, and vice versa, which is exactly why the dual-store split exists rather than one store trying to serve both needs.

Direct answer

Before committing to a plan, spend the first days mapping every team your work actually depends on, get an explicit, dated commitment from each one on what they will deliver, and track those commitments in one visible place so a slip surfaces the moment it happens instead of at the deadline.

Structured elaboration

Map the dependency graph early, not incidentally

Run a short cross-functional session at kickoff specifically to list what you need from other teams: what, by when, and in what form. Treat this as a deliverable of the kickoff, not a side conversation that happens if someone remembers to ask.

Get commitments, not assumptions

"They know we need this" is not a commitment. A commitment has an owner, a date, and an explicit acceptance criterion, meaning what "done" looks like from your side, not just theirs. Ambiguous handoffs are where dependencies quietly slip.

Make status visible continuously, not just at standups

A shared dependency tracker, checked weekly at minimum, with a clear ready, at risk, or blocked status per item, turns a hidden slip into a visible one while there is still time to react.

If you are joining an initiative already in motion

The mapping happens differently. Your first days are spent finding out who currently owns each piece, which may not match the org chart or what the original plan assumed, and estimating the time-to-impact for each dependency, meaning how long before a slip there would actually hit your own critical path (the specific chain of dependent tasks whose delay would directly delay your own delivery date, unlike a dependency that has slack to spare), before you commit to a timeline of your own. Committing to a date before doing this is committing to someone else's assumptions.

Worked example

A project depends on three other teams: one providing a new data feed, one exposing an API endpoint, and one delivering a design system component. At kickoff, the team runs a short dependency-mapping session and gets each provider to commit to a specific date and a specific definition of ready, for the API that means a documented contract and a staging environment, not just "the code exists." These commitments go into a shared tracker with a status column, reviewed weekly.

In week two, the API team's status moves to at risk because their own upstream dependency slipped. Because the tracker surfaced this immediately rather than at the original deadline, there is still time to either help unblock the API team or replan the timeline around a slower path, instead of discovering the problem in the final week when no good options remain.

For the joining-in-progress case: an engineer joins a multi-team initiative already underway. In the first few days, instead of accepting the existing plan at face value, they interview each team named in the plan to confirm who currently owns each dependency, since ownership has quietly shifted since the plan was written, and estimate the time-to-impact of each one: the API dependency would only hurt the timeline if it slipped more than two weeks, while the data-feed dependency has almost no buffer at all. Only after that mapping do they commit to a delivery date of their own, rather than inheriting the original plan's assumptions unchecked.

Trade-offs and pitfalls

A heavy dependency-tracking process on a small, low-risk project wastes more time than it saves; scale the rigor to the size and risk of the dependency rather than applying it uniformly everywhere.

The most common failure is treating the mapping as a one-time kickoff exercise instead of a living tracker. A dependency list that is accurate on day one and never updated again is exactly as useless as never having made one, because the whole point is catching drift as it happens.