Google Research Scientist (Staff Level) Interview Preparation Guide

Direct answer
I'll use Amazon's "Customer Obsession" as the example: in plain terms it means starting from the customer's actual experience and working backward to the decision, rather than starting from what's easiest or cheapest for the team and working forward to how it will land on the customer. In day-to-day work that shows up as a specific, repeatable habit: before finalizing a decision, explicitly write down what the customer will experience as a result, not just what the team will ship.

Structured elaboration

1. State the value in plain language first, in one or two sentences, before layering on any nuance. A stated value is only useful if you can restate it without jargon; if you can't, you probably don't understand it well enough to apply it.
2. Trace two or three concrete decisions the value would actually change, not just decisions it would be compatible with. The test is not "does this decision fit the value" (almost any reasonable decision can be described as fitting almost any value after the fact); the test is "would I have decided differently without this value in mind."
3. Be specific about the mechanism, not just the outcome. It's not enough to say "I'd focus on the customer"; describe the actual practice (writing the customer-facing consequence down explicitly, reviewing a metric that measures customer impact rather than only internal effort, asking a specific question in a design review) that operationalizes the value day to day.
4. Acknowledge the value has a cost or a trade-off, because a value with no real cost usually is not being taken seriously. A genuinely operative value changes what you'd otherwise have done, which means it sometimes means doing the harder or slower thing.
5. Connect it back to your own role specifically, since the same value plays out differently for different functions; the mechanism for a backend engineer, a designer, and an analyst are all different concrete practices in service of the same underlying value.

Worked example
Say you're building a dashboard intended to help a seller reduce order defects. A team NOT applying customer obsession as a working discipline might ship the dashboard once the underlying data pipeline is stable and the metrics are technically correct, treating "the data is right" as the finish line. Applying the value changes the finish line: before shipping, you'd sit with two or three actual sellers using an early version and ask what decision they're trying to make when they open it, which might surface that they need same-day defect data to catch a bad batch before it ships further, not a metric that's accurate but a day stale. The concrete decision that changes: you invest in a same-day data refresh even though it's more engineering effort than the weekly batch job you'd planned, because the customer's real decision-making need, not the easier technical path, is what determines what "done" means. The cost is real (more pipeline complexity, tighter SLAs to maintain) which is exactly why it's evidence the value is actually operative rather than decorative.

Trade-offs & pitfalls
The most common failure is reciting the value's definition fluently and then giving an example so generic it would apply to any company with any stated value ("I always think about the user"), which demonstrates you've read the careers page rather than that you understand the mechanism. A second pitfall is picking an example where the value cost nothing: if every example you give was also simply the obviously correct engineering or business call regardless of the stated value, you haven't actually shown the value did any independent work in your reasoning. A third is over-indexing on one company's specific phrasing so heavily that the answer would sound out of place at any other employer; the goal is to show you can genuinely reason from a stated principle to a concrete decision, a transferable skill, not that you've memorized one company's vocabulary.

Direct answer

Don't try to average everyone's position into a compromise nobody's happy with. Ground the negotiation in the shared outcome, make the trade-offs between options explicit with evidence, and force a real decision (with an owner and a documented rationale) within a fixed timeframe. A compromise sticks when people can see why it was chosen, not just that it split the difference.

Structured elaboration

1. Reframe around outcome, not position. Ask each stakeholder what success looks like for them, not what they want built. Two stakeholders who seem opposed on the "what" often agree on the "why," which is where the real compromise lives.
2. Bring evidence, not opinions. Gather whatever is available and relevant: usage data, cost/effort estimates, prior incidents, qualitative feedback. A room full of opinions negotiates forever; a room with a shared set of facts converges faster.
3. Make trade-offs visible. Lay out 2-3 real options with their costs and benefits side by side, instead of a single proposal to accept or reject. People compromise more easily when they're choosing between concrete alternatives than when they're being asked to give up a specific ask.
4. Use a structured negotiation move. Propose a balanced default option first, then invite each side to request a bounded concession from it, rather than starting from each side's maximal ask and negotiating down. Time-box the discussion so it doesn't drift into re-litigating the same points.
5. Document the decision and name an owner. Write down what was decided, why, who owns it, and when it will be revisited. If the group truly can't converge, escalate with a specific recommendation rather than an open question, so the escalation itself doesn't become another unresolved debate.
6. Build in a review point. Treat the agreement as provisional and testable, not permanent. A short follow-up (after the next milestone, or a fixed number of weeks) to check whether the compromise is actually working keeps people bought in because they know it isn't final and unappealable.

Worked example

Three stakeholders disagree on scope for a feature: one wants the full version shipped now, one wants it deferred a quarter, one wants a stripped-down version shipped immediately. Instead of negotiating "how much scope," the facilitator asks each what outcome they're protecting: the first is protecting a customer commitment, the second is protecting engineering capacity for other work, the third is protecting the team's ability to learn before over-investing. That reframing surfaces a real option none of them had proposed: ship a narrow version that satisfies the customer commitment, explicitly scoped as a first iteration, with the deferred work logged and re-prioritized at the next planning cycle. The decision, the scope boundary, and the re-prioritization date are written down and shared with all three stakeholders.

Trade-offs & pitfalls

• Pitfall: false compromise, where everyone gets a token piece of what they asked for and the result satisfies no one's actual underlying need.
• Pitfall: skipping documentation. An undocumented "agreement" gets re-argued the moment someone's memory of it differs.
• Pitfall: treating consensus as required. Some decisions need a single accountable owner to make the call after input, not unanimous agreement, especially under a deadline.
• Senior differentiator: designing the forcing function (a default option, a timebox, a named decision owner) instead of facilitating an open-ended discussion indefinitely. That's what turns "several people who each want something different" into an actual decision.

Clarify goal & constraints
Train a 1B-parameter transformer on 64 GPUs with mixed precision, prioritize throughput and reproducible recovery; assume each GPU is 40–80GB GPU memory (A100/H100 class), intra-node NVLink and inter-node 100 Gbps RDMA.

Architecture summary

• Hybrid: data parallelism at the outer level, tensor-parallelism (TP) for weight-splits, small pipeline parallelism (PP) if model depth justifies it.
• Example partition: TP=8 (within node groups), PP=2 (split transformer stack), Data-parallel replicas = 64 / (TP * PP) = 4. This gives 4-way data parallelism.

Why this split

• TP reduces per-GPU parameter memory and FLOPs per op with minimal communication pattern (all-reduce on matmul fragments).
• Small PP reduces peak activation memory for deeper models without long pipeline bubbles.
• Data parallelism preserves simplicity for scaling and statistical independence.

Optimizer state sharding & gradient sync

• Use ZeRO Stage 2/3 (preferred: Stage 3 if memory-limited) to shard optimizer states, gradients, and optionally parameters across data-parallel ranks.
• Gradient synchronization: use ReduceScatter + AllGather pattern (NCCL/IB verbs) to overlap communication with computation; use fused AllReduce for data-parallel gradient sync when not using ZeRO stage 3.
• Combine gradient accumulation to increase effective batch size and amortize sync frequency.

Checkpointing & recovery

• Sharded checkpoints (ZeRO-compatible): each rank writes its shard to distributed storage (parallel multipart uploads to S3 or NFS with throughput guarantees).
• Periodic consistent global checkpoint: lightweight global index + versioned manifest.
• Fast recovery: on restart, read local shards in parallel; if node losses occur, re-shard from surviving shards or restore from last full checkpoint. Keep occasional full-model checkpoints to simplify catastrophic recovery.

Memory & perf optimizations

• Mixed precision (AMP/float16 or bfloat16) + loss scaling.
• Activation checkpointing (rematerialization) for deep layers.
• Fused kernels (fused Adam/optimizers), custom CUDA kernels for matmuls.
• Operator-level memory reuse and static memory planning.
• Use attention optimizations (flash attention) to reduce memory/time.

Scaling to 10B

• Increase TP and PP: e.g., TP=16–32, PP=4–8, and data-parallel replicas as allowed by 64 GPUs (likely need more GPUs — 64 may be tight; target cluster of ~256 GPUs).
• Rely on ZeRO-3 to shard full optimizer+params across all GPUs.
• Expect increased communication overhead — require higher network bandwidth and lower latency (200 Gbps+ desirable) and fast NVMe-backed checkpointing.

Expected bottlenecks & network assumptions

• Bottlenecks: inter-node AllReduce/AllGather latency and bandwidth (dominant for TP and ZeRO shuffles), checkpoint I/O throughput, and host-GPU PCIe limits.
• With 100 Gbps RDMA and good topology/NCCL, TP communication and ZeRO shuffles are manageable; with lower bandwidth, TP and ZeRO will dominate runtime.
• Mitigations: overlap comm/comp, topology-aware placement, compression (FP16 or 8-bit comm), and gradient accumulation.

This design balances memory, compute, and network trade-offs, and is compatible with research iterations (fast restart, reproducible checkpoints) while being practical to scale toward 10B with more GPUs and higher network capacity.

Quick answer

For a continuous outcome, Cohen's d standardizes the difference between two group means by the pooled standard deviation, so effects become comparable across metrics measured in different units. For a binary outcome, the risk ratio (RR) and odds ratio (OR) compare event rates between groups multiplicatively rather than as a raw percentage-point difference. All three feed directly into sample-size and power calculations: the effect size you're willing to assume determines how many observations you need to reliably detect it.

Framework

Continuous outcomes: Cohen's d

Interpretation benchmarks (Cohen's conventions, treat as rough guides, not hard cutoffs): small $\approx 0.2$, medium $\approx 0.5$, large $\approx 0.8$. In a business setting, $d = 0.5$ means the two group means differ by half a pooled standard deviation; multiplying $d$ back by $s_{pooled}$ converts it into a dollar (or whatever unit) difference stakeholders can act on.

Binary outcomes: risk ratio and odds ratio

where $p_1$ is the event rate in the treatment group and $p_0$ in the control. $RR = 1$ means no effect. OR always exaggerates RR in the same direction, and the gap grows as baseline rate $p_0$ moves away from 0; OR only approximates RR well when events are rare (roughly under 10%).

Linking effect size to sample size and power

For a two-sided two-sample t-test with significance $\alpha$ and power $1-\beta$, the standard normal approximation for the required sample size per group is:

A larger assumed $d$ shrinks the required $n$; a smaller, more realistic effect size grows it fast because $n$ scales with $1/d^2$. For binary outcomes the same logic applies through the variance of a proportion, $p(1-p)$, and the required $n$ additionally depends on the baseline rate $p_0$, not just the OR or RR.

Worked example

Continuous outcome (order value, dollars), $n_1 = n_2 = 40$, $\bar{x}_1 = 128.50$, $\bar{x}_2 = 121.30$, $s_1 = 22.0$, $s_2 = 24.5$:

import numpy as np
from scipy import stats

n1, n2 = 40, 40
m1, m2 = 128.50, 121.30
s1, s2 = 22.0, 24.5
s_pooled = np.sqrt(((n1 - 1) * s1**2 + (n2 - 1) * s2**2) / (n1 + n2 - 2))
d = (m1 - m2) / s_pooled
print(f"s_pooled={s_pooled:.4f}, d={d:.4f}")
# s_pooled=23.2836, d=0.3092

$d \approx 0.31$: a small-to-medium effect, an $7.20 mean difference against a pooled spread of about $23.

Binary outcome (checkout conversion), $p_1 = 0.18$, $p_0 = 0.12$:

p1, p0 = 0.18, 0.12
RR = p1 / p0
OR = (p1 / (1 - p1)) / (p0 / (1 - p0))
ARD = p1 - p0
print(f"RR={RR:.4f}, OR={OR:.4f}, ARD={ARD:.4f}")
# RR=1.5000, OR=1.6098, ARD=0.0600

RR $= 1.5$: conversion is 50% higher in treatment. OR $= 1.61$ overstates that because $p_0 = 0.12$ isn't rare. ARD $= 0.06$, a 6-percentage-point lift, is the number to lead with in a business readout.

Sample-size planning for a future test, assuming a smaller, more conservative $d = 0.4$, $\alpha = 0.05$, power $= 0.80$:

from scipy import stats

alpha, power = 0.05, 0.80
z_a = stats.norm.ppf(1 - alpha / 2)
z_b = stats.norm.ppf(power)
d_target = 0.4
n = 2 * (z_a + z_b) ** 2 / d_target ** 2
print(f"z_a={z_a:.4f}, z_b={z_b:.4f}, n_per_group={n:.2f}")
# z_a=1.9600, z_b=0.8416, n_per_group=98.11

Round up: 99 per group, 198 total, to reliably detect a $d = 0.4$ effect.

Trade-offs and pitfalls

• Standardized effects hide the raw units. Always convert $d$ back to dollars, and RR/OR back to an absolute risk difference, before presenting to a non-technical audience; "$d=0.5$" means nothing to a stakeholder on its own.
• OR vs. RR confusion is a classic interview trap. If baseline conversion is anywhere near 10-20% or higher, quoting an OR as if it were a RR materially overstates the effect.
• Cohen's d assumes equal (or pooled) variance. If group variances differ substantially, use Welch's approach and consider Hedges' g, a small-sample-corrected version of d, instead.
• The sample-size formula needs an assumed effect size before you have data. Power calculations are only as good as that assumption; a common senior move is to run the calculation across a small range of plausible effect sizes rather than a single point estimate.

Direct answer

CUPED (Controlled-experiment Using Pre-Experiment Data, the variance-reduction method published by Deng, Xu, Kohavi, and Walker at Microsoft, WSDM 2013) adjusts the experiment outcome $Y$ by subtracting a scaled, pre-experiment covariate $X$ that is correlated with $Y$ but unaffected by treatment. The optimal scaling coefficient is $\theta^* = \mathrm{Cov}(X,Y)/\mathrm{Var}(X)$, and the payoff is that the adjusted outcome's variance shrinks by a factor of $(1-\rho^2)$, where $\rho$ is the correlation between $X$ and $Y$, which under a fixed minimum detectable effect and fixed power translates directly into a required sample size that shrinks by the same factor. The method breaks down if $X$ is itself affected by treatment, because then part of the true treatment effect gets subtracted out along with the noise.

Structured elaboration

Deriving the optimal coefficient

Define the adjusted outcome as $Y' = Y - \theta (X - E[X])$. Subtracting a constant, $\theta E[X]$, does not change variance, so $Y'$ has the same variance as $Y - \theta X$:
$\mathrm{Var}(Y') = \mathrm{Var}(Y) - 2\theta\,\mathrm{Cov}(X,Y) + \theta^2 \mathrm{Var}(X)$
This is a quadratic in $\theta$, minimized where its derivative with respect to $\theta$ is zero:
$\frac{d}{d\theta}\mathrm{Var}(Y') = -2\,\mathrm{Cov}(X,Y) + 2\theta\,\mathrm{Var}(X) = 0 \quad \Rightarrow \quad \theta^* = \frac{\mathrm{Cov}(X,Y)}{\mathrm{Var}(X)}$
Subtracting $\theta(X - E[X])$ does not shift the mean of $Y'$, since $E[X - E[X]] = 0$, so this adjustment is unbiased for the mean of $Y$, and therefore unbiased for the treatment effect, as long as $X$ is unaffected by treatment (more below).

Variance reduction in terms of rho

Substituting $\theta^*$ back into the variance expression, writing $\sigma_X^2 = \mathrm{Var}(X)$ and $\sigma_Y^2 = \mathrm{Var}(Y)$:
$\mathrm{Var}(Y') = \sigma_Y^2 - 2\theta^*\,\mathrm{Cov}(X,Y) + (\theta^*)^2\sigma_X^2 = \sigma_Y^2 - \frac{\mathrm{Cov}(X,Y)^2}{\sigma_X^2}$
Using $\rho = \mathrm{Cov}(X,Y)/(\sigma_X \sigma_Y)$, so $\mathrm{Cov}(X,Y)^2 = \rho^2 \sigma_X^2 \sigma_Y^2$:
$\mathrm{Var}(Y') = \sigma_Y^2 - \frac{\rho^2 \sigma_X^2 \sigma_Y^2}{\sigma_X^2} = \sigma_Y^2(1 - \rho^2)$
CUPED reduces the variance of the outcome used in the treatment-effect estimate by exactly a factor of $(1-\rho^2)$: a covariate correlated at $\rho = 0.5$ removes $\rho^2 = 25\%$ of the outcome variance; at $\rho = 0.7$ it removes $\rho^2 \approx 49\%$. The relationship is quadratic in $\rho$, so weakly correlated covariates, $\rho$ below roughly 0.3, remove under 9% of variance and buy very little.

How required sample size scales with rho

The standard two-sample sample-size formula for a fixed minimum detectable effect (MDE), significance level, and power is proportional to the outcome variance: $n \propto \sigma^2 / \text{MDE}^2$, holding alpha and power fixed; that base relationship itself belongs to standard power-analysis mechanics, not to CUPED. Since CUPED only changes the variance term, from $\sigma_Y^2$ to $\sigma_Y^2(1-\rho^2)$, and leaves the MDE and the estimator's unbiasedness unchanged, the required sample size scales the same way:
$\frac{n_{\text{CUPED}}}{n_{\text{raw}}} = 1 - \rho^2$
A pre-experiment covariate correlated at $\rho = 0.7$ with the outcome would let you reach the same statistical power with about $1 - 0.49 = 0.51$, roughly half the sample, or equivalently run the same sample for about half the calendar duration.

What breaks if X is affected by treatment

The derivation above relies on $\theta$ being estimated from data where $X$ has no relationship to treatment assignment. If $X$ is measured after treatment starts, or is otherwise influenced by it, then $X$ itself carries part of the treatment signal, and subtracting $\theta(X - E[X])$ subtracts part of that signal out of $Y'$ along with the noise, biasing the estimated treatment effect toward zero. This is the same failure mode as conditioning on a variable that sits on the causal path between treatment and outcome: the fix is procedural, not statistical, use only strictly pre-experiment values of $X$, measured before randomization occurs, computed identically for both arms.

Worked example

Suppose a pre-experiment covariate is a user's prior 28-day spend, and analysis of historical (pre-experiment) data gives stated, illustrative moments $\sigma_X^2 = 400$, $\sigma_Y^2 = 100$, and $\mathrm{Cov}(X,Y) = 120$. Then:
$\theta^* = \frac{\mathrm{Cov}(X,Y)}{\mathrm{Var}(X)} = \frac{120}{400} = 0.3$
$\rho = \frac{\mathrm{Cov}(X,Y)}{\sigma_X \sigma_Y} = \frac{120}{\sqrt{400}\sqrt{100}} = \frac{120}{20 \times 10} = 0.6$
$\mathrm{Var}(Y') = \sigma_Y^2(1-\rho^2) = 100 \times (1 - 0.36) = 64$
The adjusted outcome variance drops from 100 to 64, a 36% reduction, and the required sample size for the same MDE and power drops to $1 - 0.36 = 0.64$, 64% of the original sample.

Trade-offs and pitfalls

• $\theta$ itself must be estimated, from pooled or historical data, which adds a small amount of estimation noise not captured in the idealized derivation above; in practice this is usually negligible if $\theta$ is estimated on a large enough historical sample, but it is not literally zero cost.
• CUPED buys nothing for users with no pre-experiment history, since $X$ is undefined or has to be imputed for them; teams typically report CUPED-adjusted results for existing users and a separate, unadjusted analysis for new users rather than silently imputing.
• The variance reduction is entirely a function of $\rho$; picking a covariate that is easy to compute but weakly correlated with the actual outcome metric wastes engineering effort for little statistical payoff, so the covariate should be chosen and validated on historical data before committing to it, not assumed.
• The most common real-world mistake is using a covariate window that overlaps with treatment start, even by a day, because of a timezone or pipeline lag; this silently reintroduces the treatment-affected-X bias described above while looking, superficially, like a valid pre-experiment covariate.

Direct answer. Metamorphic testing checks a RELATIONSHIP between an input transformation and the expected change (or non-change) in output, rather than checking output against a fixed expected value, which makes it useful exactly where you don't have ground-truth labels for every possible input but do know how the model SHOULD behave under certain transformations.

Three metamorphic relations for an image classifier's preprocessing and inference pipeline.

1. Invariance to small brightness changes. For a class that isn't defined by brightness (most object classes), a small, uniform brightness adjustment to an input image should not change the predicted class. The automated test applies a small brightness perturbation to a batch of inputs and asserts the predicted class is unchanged (allowing prediction CONFIDENCE to shift somewhat, but not the class itself).
2. Rotation symmetry for certain classes. For a class that's genuinely rotation-invariant in the real world (a satellite image of a lake, versus a class like "6" versus "9" where rotation changes the true label), a small rotation of the input should not change the predicted class. The test applies a small rotation and asserts class stability, explicitly scoped to classes where this genuinely holds, since applying it universally would produce false failures on the (correctly) rotation-sensitive classes.
3. Monotonicity under image degradation. As you progressively add noise or blur to an input, model confidence in the originally-predicted class should trend downward (or stay flat), not increase. The test applies increasing levels of a degradation and asserts the confidence trend is non-increasing, catching a model whose confidence score doesn't actually track how corrupted or ambiguous an input has become.

What a failure indicates for each. A brightness-invariance failure that flips the predicted class points at the preprocessing pipeline being sensitive to something it shouldn't be (perhaps a normalization step that doesn't correctly account for brightness variation), rather than a genuine limitation of the model's learned features. A rotation-symmetry failure on a class the test correctly scoped as rotation-invariant suggests the model has learned an orientation-dependent shortcut rather than the actual class concept. A monotonicity-under-degradation failure (confidence going UP as an image gets noisier) is a strong, specific signal that the model's confidence score is not trustworthy as a measure of uncertainty, valuable to know before using that confidence score to gate any downstream decision (like whether to route a low-confidence prediction to human review).

Situation / Task
I work on exploratory ML research where months can pass with weak experimental signals. I maintain momentum by building a routine that focuses on curiosity, measurable progress, and community feedback.

Daily practices

• 60–90 minutes of deep work: experiments or proof steps with clear mini-goal.
• 30 minutes reading new papers / blog posts; capture 2–3 ideas in a notes repo.
• Quick end-of-day log: what I tried, why, next hypothesis.

Weekly practices

• 1-hour sync with peers to share failures and get critique.
• 1 “clean-slate” hour to pursue an odd idea or follow-up from literature.
• Weekly dashboard update tracking experiment runs, validation metrics, and hypotheses tested.

What I track to stay motivated

• Number of hypotheses tested per week (velocity).
• Best validation metric and its trend.
• Novel insights captured (notes count) and paper drafts progress.
  Seeing velocity, even if metrics plateau, preserves a sense of forward motion.

Example (Action / Result)
On a noisy RL project with repeated negative results, the routine revealed we had conflated two hypotheses. Weekly notes plus a peer sync led me to reframe the reward shaping assumption; a focused 48-hour experiment confirmed the change and unlocked consistent improvements. Result: paper-quality results in 3 months instead of stagnating for 6.

Learning
Small, tracked wins, scheduled curiosity time, and peer feedback convert long dry spells into iterative progress.

Direct answer

Sort meetings by start time, and track the end times of currently occupied rooms in a min-heap (a binary heap ordered so the smallest element is always at the root, giving $O(\log n)$ push and pop). For each meeting, if the room that frees earliest already ended at or before this meeting's start, reuse it; otherwise open a new room. The peak number of rooms in use at any moment is the answer, which is a fundamentally different question from merge-overlapping-intervals: that problem asks for the union of overlapping ranges, while this one asks for the maximum number of ranges alive at the same instant, which can be larger than the number of merged groups whenever more than two meetings overlap at once.

Structured elaboration

Why this differs from merging overlapping intervals

Merging intervals collapses any chain of pairwise-overlapping intervals into one output range: three meetings that overlap in a chain (A overlaps B, B overlaps C, but A and C do not) merge into a single interval. Room counting instead asks how many of them are simultaneously alive, which is a different quantity: those same three meetings only ever need 2 rooms if A and C never overlap directly, even though they all merge into one interval. Room counting is a peak concurrency question, not a union of ranges question.

Why sorting starts and ends (or a heap of active ends) gets you there

Model each meeting as a $+1$ event at its start and a $-1$ event at its end. Sorting starts and ends and sweeping through events in time order lets you track the running concurrent count directly: the answer is the maximum value that running count ever reaches. A min-heap of active end times is an equivalent formulation of the same sweep: instead of a raw counter, the heap always tells you the earliest time a room becomes free, so you know immediately whether the next meeting can reuse an existing room or needs a new one.

Algorithm (steps)

1. Sort meetings by start time.
2. Maintain a min-heap of the end times of meetings currently occupying a room.
3. For each meeting in start order: if the heap is non-empty and its minimum end time is $\le$ this meeting's start, pop that end time (that room frees up) and push this meeting's end time in its place; otherwise push this meeting's end time as a new room.
4. The final heap size is the minimum number of rooms needed.

Worked example

import heapq


def min_meeting_rooms(intervals: list[list[int]]) -> int:
    """
    Minimum concurrent rooms needed. O(n log n) time, O(n) space (heap of end times).
    """
    if not intervals:
        return 0
    ordered = sorted(intervals, key=lambda pair: pair[0])
    heap: list[int] = []  # end times of meetings currently occupying a room
    for start, end in ordered:
        if heap and heap[0] <= start:
            heapq.heapreplace(heap, end)  # reuse the room that frees earliest
        else:
            heapq.heappush(heap, end)     # need a new room
    return len(heap)


if __name__ == "__main__":
    sample = [[0, 30], [5, 10], [15, 20]]
    print(min_meeting_rooms(sample))
    no_overlap = [[7, 10], [2, 4]]
    print(min_meeting_rooms(no_overlap))

Running this prints:

2
1

For [[0,30],[5,10],[15,20]]: room 1 opens for [0,30]; at start=5, the heap's minimum end is 30 which is not $\le$ 5, so a new room opens for [5,10]; at start=15, the minimum end is now 10 (from the just-finished [5,10]), which is $\le$ 15, so that room is reused for [15,20]; final heap size 2. For [[7,10],[2,4]] (sorted to [[2,4],[7,10]]): room 1 opens for [2,4]; at start=7, the minimum end 4 is $\le$ 7, so the same room is reused; final heap size 1.

Complexity

Time: $O(n \log n)$, dominated by the initial sort (heap operations are $O(\log n)$ each, over $n$ meetings). Space: $O(n)$ for the heap in the worst case, when every meeting overlaps every other.

Edge cases

• Empty input needs 0 rooms.
• A meeting that starts exactly when another ends is treated as not overlapping here (the room is reused): whether a meeting ending at t and one starting at t count as conflicting is a modeling choice to state up front.
• All meetings mutually overlapping (for example, everyone scheduled from 9am to 5pm) requires n rooms, the maximum possible.
• Duplicate identical meetings still each require their own room if they are genuinely simultaneous distinct bookings.

Trade-offs & pitfalls

The most common wrong turn is applying the merge-overlapping-intervals algorithm here and reporting the number of merged groups: that undercounts whenever three or more meetings overlap in a chain without all pairwise overlapping, since merging only tracks the union shape, not simultaneous occupancy. A second common gap is not being explicit about the boundary rule (does a meeting ending at t conflict with one starting at t), since interviewers frequently vary this to see if the candidate notices the assumption. For the streaming follow-up (meetings arriving one at a time rather than as a batch), the min-heap of active end times generalizes directly: insert the new end time, and if a room is reused, decrement the heap; there is no need to re-sort, since the heap already maintains order incrementally.

Approach summary
Start by assuming tiny true effects and high overfitting risk. Prioritize strong, reproducible evidence: conservative baselines, rigorous validation splits, and targeted ablations that isolate mechanisms.

Strategy

• Strong baselines first
  • Reproduce simple but competitive baselines (e.g., tuned logistic/regressor, random features, data augmentation only). A new method must beat these reliably.
• Validation design
  • Use nested cross-validation or repeated random splits to estimate variance. Hold out a final locked test set for the claim.
• Ablation plan
  • Pre-register a small set (~3–6) of hypothesis-driven ablations: remove key components individually, replace with controlled alternatives, and run pairwise comparisons.
• Statistical testing
  • Apply paired tests (e.g., Wilcoxon signed-rank or paired t if normality holds) across folds; adjust for multiple comparisons (Benjamini–Hochberg) when testing multiple ablations.
• Power and sample-effort trade-off
  • Run a pilot to estimate effect size and variance; compute required runs for desired power (e.g., 80%). If required runs are prohibitive, favor stronger baselines and tighter claims.

Trade-offs

• More tests → higher chance of false positives and greater computational cost; need corrections and pre-registration.
• Stronger baselines → higher bar but reduces risk of publishing artifacts.
• More runs/permutations → better confidence but linear increase in cost; use stratified sampling and variance-reduction (control seeds, common random numbers).

Template for robust claims

• Claim statement (precise metric, dataset, and seed regime)
• Experimental protocol (data splits, hyperparameter tuning budget, number of repeats)
• Baselines (list + how tuned)
• Ablations (pre-registered list and rationale)
• Statistical results (mean ± SE, p-values, effect size, correction method)
• Power analysis and limitations
• Reproducibility artifacts (code, seeds, config)

This balances scientific rigor with computational practicality and is appropriate for research-grade claims.

Clarify scope & goals
Design a tiered, scalable internal research governance and ethical-review process for ML/AI research that balances safety, scholarly freedom, and speed-to-insight.

Submission requirements

• Short-form intake (automated form, <10 fields): project title, PI, team, abstract (150 words), datasets (sources, sensitivity), compute needs, human-subjects or PII? yes/no, potential harms, mitigation plan, intended outputs (code/paper/product), risk self-assessment.
• Long-form for medium/high risk: methods, training data schema, model cards, evaluation plan, reuse/transfer risks, IRB/partner approvals.

Risk categorization

• Low: public data, no PII, no deployment, purely theoretical/simulations.
• Medium: uses internal or sensitive datasets, potential for bias, models with dual-use concerns.
• High: human-subjects experiments, deployment to users, high-impact models (biological, safety-critical), national-security dual-use.

Review-board composition & cadence

• Standing Research Ethics Board (REBoard): PI-level researcher, ML safety expert, data steward, privacy/officer, legal liaison, representative from affected domain.
• Ad-hoc SMEs added per domain (health, finance).
• Cadence: weekly for triage (low/medium), biweekly deep reviews, immediate ad-hoc for high-risk.

Timelines

• Auto-approve low-risk within 3 business days via checklist and delegated reviewer.
• Medium: decision in 7–10 business days (one full review cycle).
• High: initial decision within 3 business days for hold/fast-track; full review 14 business days; may require iterative mitigation.

Appeal & escalation

• Applicant may request re-review within 5 days with new evidence.
• Escalation to Research Governance Council (senior directors + external advisor) for contested high-risk decisions; final decision within 7 days of escalation.

Avoid blocking low-risk work

• Fast-path automation: checklist, delegated approval to senior researcher pool, template mitigations.
• Pre-approved data/model sandboxes for exploratory work.
• Clear acceptance criteria for low-risk automation; audits post-hoc rather than pre-approval for benign experiments.
• Rolling training: quarterly “office hours” and tooling (automated data-sensitivity scanners, ML-card generators) to reduce friction.

Metrics & continuous improvement

• Track throughput, time-to-decision, appeals, harm incidents, and researcher satisfaction; review quarterly and iterate.