Mid-Level Research Scientist Interview Preparation Guide (FAANG Standards)

High-level approach
Define a set of orthogonal, measurable proxies that map to intermediate research outcomes (knowledge, capability, adoption potential) and a 6–12 month cadence for measurement and portfolio review. Use mixed quantitative + qualitative signals, validated by retrospective calibration.

Proxies (with rationale)

• Foundational knowledge: number of reproducible experiments + released datasets/code (signals reusability).
• Technical novelty: citations in non-peer-reviewed channels (preprints, patents cited) within 12–24 months.
• Capability lift: internal benchmark delta (%) on core tasks when prototype model is integrated.
• Transfer potential: number of internal teams with active PoCs based on the research.
• Talent & visibility: invitations to collaborate / industry partnerships and top-tier acceptances.
• Strategic alignment: score (1–5) from product stakeholders on problem fit.

Collection

• Automated: repo releases, experiment logs, benchmark dashboards, PoC usage telemetry.
• Manual: biannual research impact reports, stakeholder survey (standardized rubric), collaboration logs.
• External: citation tracking (Semantic Scholar, Google Scholar), patent filings.

Validation

• Retrospective calibration every 2 years: correlate proxies with realized product/business KPIs for older projects to adjust weights.
• Audit samples: reproducibility checks on 10% of published results each cycle.
• Cross-checks: compare internal benchmark improvements with independent external benchmarks.

Cadence & Use

• Quarterly: collect automated metrics; flag projects needing attention.
• Semiannual portfolio review: combined quantitative score + qualitative narrative; decide go/no-go, scale, or sunsetting.
• Annual strategic review: recalibrate proxy weights and publish learnings.

Decision rules (example)

• Continue + scale if capability lift > X% and ≥2 teams running PoCs.
• Maintain if high novelty/visibility but low near-term adoption—fund at baseline to de-risk.
• Deprioritize if reproducibility failures or negative calibration signals.

This framework balances short signals of technical progress with longer-term validation so funding decisions are evidence-driven yet tolerant of exploration.

Direct answer

I would spend most of the compute on a fair comparison, not on tuning the new architecture to exhaustion. A new method that is thoroughly tuned against baselines (existing methods you are trying to beat) that are barely tuned looks better than it is. So: a small pilot search on the new architecture to find a sensible region, then an equal tuning budget for every method, then repeat the best settings with several random seeds.

Terms. A hyperparameter is a setting chosen before training, such as the learning rate. A trial is one training run with one choice of settings. A random seed is a number that fixes the random starting values of a run; the same method with a different seed gives slightly different results, and that run-to-run difference is the seed-to-seed spread.

Illustrative budget: 1,200 GPU-hours; each training trial costs 10 GPU-hours, so 120 trials.

Total 200 + 800 + 150 = 1,150, with 50 held back. The pilot only sets the new architecture's search range and its trials are not counted in the comparison; each baseline's range comes from its published defaults, so every method then gets the same 16 scored trials.

What I am trading

• Rigor: the equal-budget design protects against unfair comparison, but 16 trials will not find the best setting for any method. Report the budget so readers can judge.
• Risk: if the architecture is poor, the pilot stage shows it early and saves most of the compute. If it is only fragile to hyperparameters, spending the pilot budget finds that.
• Breadth versus depth: four baselines tell you where the idea stands against alternatives; one deep search tells you its ceiling. I choose breadth first because a surprise (a baseline matching the new idea) changes the project's direction. If results look promising, a second round spends remaining compute deepening the search.

Deciding rule: continue the architecture only if its best seed-averaged result beats the strongest baseline by more than the seed-to-seed spread (highest minus lowest score across seeds). Example with accuracy: the new method scores 0.830, 0.824, 0.836 on three seeds, mean 0.830, spread 0.836 - 0.824 = 0.012. The best baseline's mean is 0.801. The gap is 0.029, more than twice the spread, so continue. If the new method's mean were only 0.808, the gap of 0.007 would be smaller than the spread of 0.012 and I could not tell it from noise. If it does not clear the bar, report that clearly.

Pitfall: tuning on the test set, or reporting the single best seed. The test set is the held-out data that is supposed to measure performance on unseen cases; if you pick settings by looking at it, you have fitted to it and the reported score is inflated. Choose settings on a separate validation set and touch the test set once at the end.

Making the pilot fair. As written, the new architecture gets 20 pilot trials plus 16 scored trials (36) while each baseline gets 16 and a default range. That tilts the comparison toward the new method, so either report it openly or equalize it: give every method a 2-trial pilot (5 x 2 = 10 trials, 100 GPU-hours), then the equal search (800), then the seed re-runs (150). That totals 1,050 GPU-hours and leaves 150 (15 trials) in reserve.

Limits of the deciding rule. Three seeds give a crude range, and the baseline also has seed-to-seed spread. Treat "gap larger than the spread" as a screening rule: check the baseline's spread too, and run more seeds or a paired test before a claim goes in a paper.

Direct answer

Translate the debt into two things leadership already budgets against: recurring engineering capacity the team is losing to it every sprint, and the probability-weighted cost of a plausible failure it enables. A vague "we should fix this" competes with a feature that has a number attached to it; a debt item stated as "this is quietly costing us a fraction of a team's sprint, every sprint, and rising" competes on the same axis.

Structured elaboration

Two lenses that actually land with a non-engineering audience:

1. Recurring tax, capacity you are already losing: tally the recurring hours spent on workarounds, re-runs, manual steps, or duplicate effort that trace back to the debt. This is discoverable by asking the team directly what they had to work around this week, rather than guessing, and it converts cleanly into a fraction of team capacity.
2. Forward risk, the cost of the failure the debt enables: name the specific failure it makes more likely or more expensive, an outage, a slow rollback, a security gap, a scaling wall at a known volume. Where the org already tracks an error budget or a service-level agreement (SLA), use that as the currency instead of inventing your own; if a fragile subsystem is what is burning the error budget, that ties the debt directly to a number leadership already reviews.
3. Rank, don't ask for one giant slot: score (recurring cost plus risk) against (fix effort) so you can propose the highest-leverage item first, not the whole backlog. The same logic holds when you are not choosing debt versus one feature but weighing debt against a combined backlog of features, security backfills, and other debt items, the ranking mechanism is the same, it just runs across a longer list.

How to make the ask: propose a bounded, time-boxed slice, not open-ended "some time for maintenance," state the capacity or risk reduction you expect to recover, and offer to split delivery, ship the backend fix now, defer only the polish, so the ask reads as a trade, not a stall.

Sequencing across multiple quarters: for debt too large for one sprint, a brittle, high-debt test-automation codebase, or a nightly pipeline degraded enough to cause double-digit-hour delays, do not ask for a whole quarter up front. Fix the highest-leverage slice, show the capacity recovered, and use that as evidence for the next slice. Debt arguments that ask for everything at once tend to lose; debt arguments that show a small proof and compound tend to win.

Worked example

Illustrative, arithmetic shown so it is reproducible, not a claimed historical result. A flaky integration-test suite forces reruns before every merge. Say each rerun costs about 15 minutes of engineer wait time, and the team merges roughly 40 pull requests a week.

$15\text{ min} \times 40 = 600\text{ min} \approx 10\text{ hours per week}$

$10\text{ hours} \div 40\text{-hour week} = 0.25\text{ FTE}$

That is a quarter of one full-time equivalent (FTE), one engineer's time, every week, spent waiting on retries, not a one-off cost. Framed to leadership as "fixing this recovers about a quarter of an engineer's weekly capacity, roughly the size of a small feature, for a one-week investment," the trade-off is now denominated in the same unit as the feature ask, engineer-weeks, instead of the vaguer "the test suite is bad." If the fix is contested, stabilizing the worst 10 percent of flaky tests first lets you show the capacity recovered before asking for the rest.

Trade-offs and pitfalls

• Quantifying capacity lost is honest only if you ask the team what they actually did; a guessed number dressed up as data is worse than no number, because it invites an executive to poke a hole in your one guess and dismiss the whole argument.
• Framing debt purely as risk, a doom scenario, without a recurring-cost number is weak. Risk gets discounted heavily under uncertainty; a concrete weekly capacity number is harder to wave away.
• Asking for an open-ended remediation quarter instead of the highest-leverage slice reads as a stall to product, and is frequently the wrong call anyway, most technical debt has a shape where a small slice removes most of the pain.
• The reverse failure also happens: shipping the feature and setting aside a debt warning because the deadline is real. That can be the right call if the debt's forward risk is genuinely small; the mistake is not making that trade-off explicit and revisiting it, not making the trade at all.

Direct answer
Autonomy should track demonstrated judgment in a specific domain, not tenure or title, and it should be granted and withdrawn through visible, structural mechanisms, not just a private mental model of how much you trust someone. As someone grows from junior to senior, both the default level of guidance and the criteria for changing it should become more explicit, not less.

What determines the level, not just the person's level

• Domain-specific, not global: someone can have earned full autonomy in one area (their core service) and need more guidance in an adjacent one (security-sensitive changes) they haven't touched before. Treating autonomy as a single dial per person rather than per domain misjudges both directions.
• Base it on evidence: track record of decisions in that specific domain, not just general seniority or how long they've been on the team.

The conversation isn't enough, structure it

• Guidance and autonomy shouldn't live only in how much you check in; they should be encoded in the system itself. Concretely: mandatory review gates on certain categories of change, feature flags that let risky work ship dark before it's fully trusted, and automated checks (tests, linting, policy gates) that catch the class of mistake a specific person is prone to, rather than relying on a human remembering to look for it.
• This matters especially early: a junior engineer with a mandatory review gate on production-config changes isn't being distrusted personally, the system is compensating for a domain they haven't yet built judgment in, and that's a much less fraught conversation than "I don't trust your judgment yet."

Moving the dial, in both directions

• Define, in advance, what "graduating" out of a guardrail looks like: a number of changes in that domain reviewed without a significant issue, or a specific type of decision made correctly under supervision. Vague criteria ("when I feel comfortable") makes the process feel arbitrary to the person on the other side of it.
• The dial also needs to move backward cleanly. If someone senior makes a judgment error in a domain, temporarily reintroducing a guardrail (an extra review, a smaller blast radius) shouldn't read as a permanent demotion; it should be scoped to the specific domain and have the same kind of explicit, objective path back out.

How this shifts junior to senior

• Junior: guidance is broad and mostly structural (required reviews, smaller scoped tasks, pairing), because there isn't yet enough track record to know where the real gaps are.
• Mid-level: guidance narrows to the specific domains where judgment hasn't been tested yet, while proven domains get real autonomy.
• Senior: guidance becomes mostly about the highest-blast-radius decisions (irreversible changes, cross-team commitments) rather than day-to-day execution, and the structural safeguards that remain exist because the stakes are higher, not because trust is lower.

Worked example
A mid-level engineer had strong judgment in their core service but hadn't touched the deployment pipeline before. Rather than a blanket "you need approval on everything" or "you're trusted, go ahead," the guidance was scoped to that specific gap: full autonomy on their usual work, a mandatory review plus a feature flag for anything touching the deploy pipeline, with an explicit criterion stated up front (three pipeline changes reviewed cleanly, then the mandatory review comes off for that category specifically). That made the guardrail feel like a scoped, temporary compensation for an actual gap rather than a general judgment about their competence, and removing it was a specific, visible moment rather than something that just quietly happened.

Trade-offs and pitfalls

• Treating autonomy as all-or-nothing per person, rather than per domain, either over-restricts someone who's earned trust in most areas or over-extends them into an area they haven't proven yet.
• Relying purely on personal judgment about who to trust, without structural backstops (review gates, flags, automated checks), doesn't scale past a small team and creates inconsistency that reads as favoritism.
• Leaving the criteria for regaining autonomy vague turns a guardrail into something that feels indefinite and punitive, even when it was scoped and reasonable at the start.

Direct answer

Keep a stalled dependency peer-to-peer as long as direct conversation is still making progress. Escalate when you hit a concrete trigger: a scope change that neither side can unilaterally absorb, genuinely conflicting priorities that only someone with visibility into both roadmaps can arbitrate, or a hard deadline-driven blocker where peer-to-peer conversation has already stalled.

Framework

Default: work it peer-to-peer. Most stalls are under-communication or unclear ownership, and a direct conversation or a short written proposal usually unsticks them without anyone else getting involved.

Concrete triggers to escalate.

• Scope change: the fix now requires work neither team budgeted for, and only a manager can reprioritize that.
• Conflicting priorities: both sides are acting rationally from their own team's goals, and the trade-off needs someone with visibility into both roadmaps to arbitrate.
• Hard blocker with a deadline: a fixed external date is genuinely at risk, and peer-to-peer conversation has already stalled past a reasonable window, for example no movement after two direct attempts over several days.
• Repeated pattern: the same kind of stall keeps recurring with the same team, which means the real issue is the working relationship or process, not this one dependency.

What to bring when you escalate. A short brief: what's blocked, what you've already tried peer-to-peer, the realistic options and their trade-offs, and the specific decision you need.

Worked example (applying the criteria)

Situation: your team's deliverable needs a schema change from another team that they've deprioritized for two weeks despite two direct requests.
Applying the criteria: this isn't just a communication gap, direct conversation was already tried twice with no movement. It's a conflicting-priorities case, the other team's roadmap has no room for this without reprioritizing something else, combined with a hard blocker, a fixed external deadline in three weeks that this schema change sits on the critical path for (meaning if this dependency slips, the final deadline slips by the same amount, unlike a dependency with buffer to absorb delay).
Action: escalated to the shared manager with a one-page brief covering what's blocked, the two peer-to-peer attempts and their outcome, and two options: the other team reprioritizes one sprint of work, or your team ships a temporary workaround with known limitations, along with the deadline risk if neither happens within the week.
Result: the shared manager reprioritized one sprint item, unblocking the schema change with two weeks to spare before the deadline. Both teams also agreed to flag scope-affecting asks earlier next time, so the same dependency doesn't reach this point again.

Trade-offs and pitfalls

• Escalating too early over normal friction burns trust and reads as an inability to work horizontally.
• Escalating too late, repeatedly trying peer-to-peer past the point it's actually working, puts the deadline at real risk and looks like poor judgment in hindsight.
• A vague escalation with no options and no specific ask wastes the leader's time compared with a brief that names the decision needed.

Direct answer

Keep two heaps: a max-heap (a heap that always exposes its largest element at the top) holding the smaller half of the numbers seen so far, and a min-heap (exposes its smallest element at the top) holding the larger half. Insert into one heap, then relay its top across so the two heaps never differ in size by more than one; the median is then either the top of the larger heap (odd count) or the average of both tops (even count), giving O(log n) insert and O(1) median lookup.

Structured elaboration

Approach

• Maintain the invariant that every element in the lower-half heap is <= every element in the upper-half heap, and the lower heap has either the same size as the upper heap or exactly one more element.
• Python's heapq only implements a min-heap, so the lower half is stored as negated values to simulate a max-heap.
• On add_num: always push into the lower (max) heap first, then immediately pop its top and push it onto the upper (min) heap. This guarantees the cross-heap ordering invariant without a separate comparison step, since whatever value the lower heap just received is relayed straight across. Then, if the upper heap has grown larger than the lower heap, move its top back to the lower heap to restore the size invariant.
• On find_median: if the lower heap holds one more element than the upper heap, the median is its top; otherwise it's the average of both tops.

import heapq


class MedianFinder:
    def __init__(self):
        self.lower = []  # max-heap, stored as negated values
        self.upper = []  # min-heap

    def add_num(self, num):
        heapq.heappush(self.lower, -num)
        # move the largest of lower into upper to keep the ordering invariant
        heapq.heappush(self.upper, -heapq.heappop(self.lower))
        # rebalance sizes: lower may hold at most one extra element
        if len(self.upper) > len(self.lower):
            heapq.heappush(self.lower, -heapq.heappop(self.upper))

    def find_median(self):
        if len(self.lower) > len(self.upper):
            return float(-self.lower[0])
        return (-self.lower[0] + self.upper[0]) / 2.0

Key points

• Pushing into the lower heap first and always relaying its top to the upper heap keeps the cross-heap invariant correct after every insert, instead of needing a conditional comparison.
• The size-rebalancing step after the relay keeps the size difference at most one.
• find_median never scans a heap; it only reads the O(1)-accessible top or tops.

Worked example

Stream [5, 15, 1, 3, 8, 7, 9, 2], calling add_num then find_median after each value:

stream = [5, 15, 1, 3, 8, 7, 9, 2]
mf = MedianFinder()
medians = [mf.find_median() for x in stream for _ in [mf.add_num(x)]]
print(medians)

prints [5.0, 10.0, 5.0, 4.0, 5.0, 6.0, 7.0, 6.0]. Checking a couple by hand: after inserting 5, 15, 1, the sorted values seen so far are [1, 5, 15], whose median is the middle value 5, matching the third entry. After inserting 5, 15, 1, 3, sorted is [1, 3, 5, 15], an even count, so the median is the average of the two middle values (3 + 5) / 2 = 4, matching the fourth entry.

Trade-offs & pitfalls

Complexity

add_num: $O(\log n)$, one push and up to two pop/push pairs on heaps of size up to $n/2$.
find_median: $O(1)$, reads heap tops only.
Space: $O(n)$ to hold every element seen so far across the two heaps.

Edge cases

• Empty stream: find_median has nothing to read; guard with a length check before calling it, or raise an explicit error.
• Single element: the lower heap holds it, the upper heap is empty, and the median is that element.
• Duplicate values: heaps handle duplicates with no special casing, since equal keys just compare equal.

This composition is the standard answer whichever way the question is dressed up: a stream of raw numbers, a stream of test-execution durations where the running-median build time matters, or a generic "support insert and delete operations while answering frequent median queries" data-structure prompt. The invariant and the two heaps are identical across all of these framings; only the label attached to the numbers changes. Note, though, that the design shown here only supports insert cheaply: arbitrary deletion from the stream is not handled by this structure and needs either a lazy-deletion marker scheme or an order-statistics tree, which is the natural next question once delete enters the picture.

A self-balancing binary search tree with subtree-size augmentation gives the same O(log n) insert but only O(log n) median lookup (not O(1)), so two heaps are strictly better for this exact query pattern when arbitrary-rank lookups are never needed, only the median. The most common implementation bug is comparing values directly to decide which heap to push into, instead of always relaying through the lower heap's top first; unit-test the invariant after every insert rather than only checking the final median.

Direct answer

The signal that you're explaining from the wrong assumption rarely sounds like disagreement, it sounds like follow-up questions that are individually reasonable but all slightly off-topic from what you just said, or a question that only makes sense if the listener is picturing a different setup than the one you're describing. The recovery move is to name the assumption you were making out loud, confirm the real one, and re-explain from there, rather than trying to patch the existing explanation with corrections.

Reading the signal and recovering

• Watch for questions that are technically reasonable but don't fit the thing you just explained. That mismatch, not confusion or silence, is usually the clearest early signal that a core assumption is wrong, not that the explanation itself was unclear.
• Don't try to bolt a correction onto the explanation already in progress; restart the relevant section from the correct assumption. Patching creates a hybrid explanation that fits neither model and confuses people further.
• Name the assumption explicitly before re-explaining ("I've been describing this assuming X, it sounds like your setup actually uses Y"). This turns an awkward correction into a moment that builds credibility, you caught it and adapted, rather than one that erodes it.
• Afterward, build a habit of confirming the assumption BEFORE it becomes load-bearing next time; a single check-in question near the start of a similar conversation is cheaper than a mid-conversation pivot.

Worked example

Situation: I was walking a prospective enterprise customer's security and platform leads through how our API gateway handles authentication, about twenty minutes in, still assuming they used the same token-based authentication most of our customers use.

Signal: two of the listeners exchanged a confused look, and one asked a question about certificate rotation and certificate authority chains, a question that only makes sense if you're authenticating with mutual TLS instead of tokens. That question was the signal, it was reasonable on its own, but it didn't fit anything I'd just described.

Action: I paused and named the assumption directly: "I've been describing this assuming you use token-based authentication between services, it sounds like you're actually using mutual TLS, is that right?" Once they confirmed, I didn't try to graft mutual TLS onto the token explanation, I restarted that section from scratch: how our gateway validates a client certificate, how certificate rotation works on our side, and where their rotation policy would need to line up with ours, using a fresh, small diagram rather than editing the one already on screen.

Result: the confusion visibly cleared, and the conversation shifted into their actual technical questions, which we were then able to answer directly instead of talking past each other. Afterward, I started opening similar demos by confirming the authentication method in use before describing the flow, rather than assuming the common case, and this specific mismatch didn't come up again in later conversations of the same kind.

Trade-offs and pitfalls

The riskiest moment is right after you notice the mismatch and before you've named it out loud; there's a real pull to keep going and hope it resolves itself, which almost never works and usually compounds the confusion. The other pitfall is over-correcting into re-explaining everything from scratch when only one assumption was wrong, that wastes the audience's patience and buries the actual fix. Isolate exactly which piece depended on the wrong assumption and restart only that piece.

Direct answer

A strong 60 to 90 second project pitch has five beats, in order: a one-line hook that states the problem or its cost, your specific role, the one decision or action that mattered most, the quantified outcome, and a single closing detail that proves technical depth. Everything else gets cut, no matter how proud you are of it.

Framework: the five-beat pitch

1. Hook (1 sentence): state the problem in terms the listener already cares about ("users were dropping off before finishing setup," "a manual process took half a day every week"). Skip the project's internal codename.
2. Your role (1 sentence): "I was the [role] responsible for X." Name the scope, not just a title.
3. The pivotal action (1 to 2 sentences): the ONE decision or trade-off you made, not a chronological list of everything you did.
4. Outcome (1 sentence): a number if you have one, otherwise a concrete before/after description.
5. Proof-of-depth detail (1 sentence): one specific technique or constraint that only someone who actually did the work would mention. This is what survives a "tell me more" follow-up.

Pacing math: conversational speaking pace runs about 130 to 150 words per minute. A 60 second pitch is therefore roughly 130 to 150 words, and a 90 second pitch (1.5 minutes × 130 to 150 wpm) tops out near 195 to 225 words. Write it out, read it aloud with a timer once, and cut whichever beat is running longest, almost always beat 3.

Worked example (skeleton, adapt the specifics to your own domain)

"Our signup flow was losing about 4 in 10 people before they finished creating an account. I owned redesigning that flow end to end. The one decision that mattered: I cut the form from 7 fields to 3 up front and pushed the rest to after first use, instead of redesigning the whole flow at once. Signup completion went from roughly 60% to 78% over a month of testing. The detail that proves I did the work: the biggest single gain came from moving email verification to a background step instead of a blocking one, a trade-off you only find by watching real session recordings."

The shape holds outside product work too. A security engineer's hook might be an incident count, a data engineer's might be a pipeline failure rate, a QA engineer's might be an escaped-defect count. The hook changes; the five beats do not.

Trade-offs and pitfalls

• Lead with the problem, not the tech stack; interviewers forget stacks, they remember problems.
• Don't try to cover multiple projects in one pitch, that is what follow-ups are for.
• A memorized script falls apart the first time someone interrupts with a question; know the story well enough to survive being cut off mid-sentence.
• An over-precise number you can't defend under a follow-up reads worse than a rounded number you can defend.

Common causes of unstable training

• Exploding/vanishing gradients (deep nets, poor nonlinearity choice)
• Poor weight initialization (symmetry, scale mismatch)
• Too large learning rate or abrupt changes
• Batch-norm issues (small batch sizes, train/eval mismatch)
• Class imbalance causing skewed gradients
• Numerical precision limits (FP16 underflow/overflow)

Practical remedies (research + production)

• Gradient clipping (norm or value) to control explosions
• Learning-rate schedules: cosine, step decay, decay on plateau
• Warmup (linear or cosine) to avoid early instability
• Optimizer choice: Adam/AdamW for adaptive stability; SGD+momentum for generalization
• Mixed precision + dynamic loss scaling to avoid FP16 underflow/overflow
• Careful initialization (Xavier/He/Kaiming) and normalization
• Class-rebalancing: loss weighting, focal loss, oversampling
• Batch-norm alternatives: LayerNorm/GroupNorm when batches small

Concrete examples: small models vs large transformers

• Small CNN/RNN: use SGD with momentum, modest LR, standard Xavier init, clip gradients rarely; FP32 usually fine.
• Large-scale transformers (billions of params): use AdamW with weight decay, long linear warmup (thousands of steps), gradient clipping by global norm, mixed precision with dynamic loss scaling, careful initialization (scaled std), and gradient accumulation to emulate large batch sizes.

These remedies are used together—choice and hyperparameters depend on model scale, dataset, and compute constraints.

Feature leakage: when a feature includes information that wouldn’t be available at prediction time or directly encodes the target.
Three examples:

• Data collection: timestamps include future labels — e.g., including 'cancellation_time' when predicting churn at signup.
• Feature engineering: aggregations computed using the full history including the target window — e.g., mean spend computed including post-label period.
• Labeling: label derived from features used as inputs — e.g., using a heuristic that uses a form field that’s also an input.
  Testing strategy to detect/prevent leaks:

1. Code review checklist: require reviewers to verify temporal validity and availability of each feature at scoring time.
2. Offline tests: simulate production scoring pipeline and assert all features are computable using only allowed data; run feature-timestamp validations.
3. Holdout experiments: train model with and without suspect features; if performance drops dramatically when removing them, investigate for leakage.
4. Cross-validation with time-based folds and forward-chaining CV for temporal data.
5. Automated unit tests in CI that enforce feature provenance metadata (source, last-updated time, allowed lag) and block deployment if provenance missing.