Entry Level Data Scientist Interview Preparation Guide - FAANG Standards

Direct answer

Make the case with concrete evidence rather than a general appeal to rigor: bring data on what share of past incidents or bad decisions were traceable to a data issue that a thorough EDA pass would likely have caught, and propose a lightweight, time-boxed process instead of framing it as an all-or-nothing choice between "skip EDA" and "take a full day."

Building the advocacy case

Quantify the cost of skipping EDA in terms the team already tracks: incidents, wasted engineering time chasing a bad number, or a shipped feature that had to be walked back because of a data problem that could have been caught earlier. Then propose something concrete and cheap enough that "compress sprints" and "keep basic EDA" aren't actually in tension: a lightweight, standardized checklist (the kind of first-pass structural checks that take an hour, not the deep case-study kind that takes days) built into the sprint cadence rather than treated as a separate, cuttable phase.

Worked example

Reviewing the last two quarters of incidents, three of eleven were traceable to a data issue (a schema change nobody caught, a duplicate-event bug, a currency-unit mix-up) that a basic first-pass EDA checklist would very likely have surfaced before shipping. Bringing that specific number ("roughly a quarter of our incidents this half were data issues a one-hour check would likely have caught") alongside a proposed lightweight checklist template that fits inside a normal sprint, rather than asking for a separate EDA phase, reframes the ask from "give me more time" to "let's not cut the one-hour version of this."

Trade-offs and pitfalls

Avoid over-claiming: not every future incident would have been caught by a basic EDA pass, and inflating the number undermines the credibility of the argument. The strongest version of this pitch pairs a specific, honest track record with a concrete, low-cost proposal, rather than a general appeal to "we should always be thorough."

Direct answer

Documentation of a dataset's known limitations for non-technical analysts should cover null semantics (what a missing value actually means for this dataset), expected lag or freshness, known gaps or sample-size caveats, an explicit confidence level, and recommended versus unsupported use cases, formatted so a new analyst finds it before building on the dataset, not after making a mistake.

Structured elaboration

• Null semantics: does a NULL in this dataset mean "genuinely unknown," "not applicable," or "not yet arrived"? These have very different implications for how an analyst should treat them, and the distinction is rarely obvious from the data alone.
• Freshness/lag: how current is the data, and does that vary by field (some columns updated hourly, others only nightly)?
• Known gaps and sample-size caveats: any known missing time periods, undersampled segments, or known-unreliable subsets, stated explicitly rather than left for an analyst to discover the hard way.
• Confidence level and recommended use: what this dataset is well-suited for versus explicitly NOT suited for (a dataset good for directional trend analysis but not precise point-in-time reporting, for example), stated as clearly as the dataset's actual strengths.
• Discoverability: attach this documentation directly to the dataset in the data catalog or as metadata visible at the point an analyst would query it, rather than in a separate document they have to know to go looking for.

Worked example

A customer-satisfaction survey dataset's limitations doc states: "NULL in response_score means the respondent was shown the question but did not answer, not that they were never asked; response rate varies significantly by channel (68% email, 12% in-app), so channel-level comparisons of raw response counts will be misleading without normalizing by send volume; data before March 2024 uses a different 5-point scale rather than the current 10-point scale and is not directly comparable without an explicit rescaling; recommended for directional trend analysis, not appropriate as a precise measure of absolute satisfaction level for any single period." An analyst who reads this before building a quarter-over-quarter trend chart avoids a specific, predictable mistake (comparing raw scores across the 2024 scale change) that the doc calls out explicitly.

Trade-offs and pitfalls

Documentation that is accurate but buried (a wiki page nobody links to from the dataset itself) provides essentially none of its intended value, since an analyst who does not know to look for it will make exactly the mistake the documentation was written to prevent. The format matters as much as the content: attaching the caveats directly to the dataset's catalog entry, ideally surfaced in the query tool itself, is what actually changes analyst behavior, versus a separate document that exists but is never consulted.

Direct answer: Separate the decision from the sunk cost explicitly, using the data as the anchor: state clearly that the campaign investment already spent is gone either way and cannot be recovered by continuing to run a feature that is now shown to be harmful, then focus the conversation on the go-forward cost of keeping versus rolling back.

Structured elaboration

• Name the sunk-cost reasoning directly and respectfully, since stakeholders pushing back are often doing so in good faith, not irrationally; acknowledge the investment was real and the intention behind it was reasonable, while being clear that the investment's size has no bearing on what happens going forward.
• Reframe the decision around the go-forward numbers only: what does keeping the feature cost from today onward (continued harm shown in the data), versus what does rolling back cost from today onward (any remaining campaign value that would be lost, any embarrassment or process cost of reversing course); compare those two forward-looking costs, not the money already spent.
• Bring the data itself into the room as the anchor for the conversation, rather than relying on personal authority to win the argument; if possible, quantify the ongoing cost of keeping the feature live in the same terms stakeholders already care about (the campaign's ROI, updated to reflect the newly-discovered harm) so the conversation happens on shared ground.
• If stakeholders still resist, propose a middle path that respects both the data and the organizational reality: a partial rollback, a time-boxed fix-and-recheck window, or a scoped rollback to the specific segment where the harm concentrates, rather than an all-or-nothing framing that invites maximal resistance.

Worked example: A promotional feature tied to a $2M marketing campaign shows clear experiment data that it reduces long-term customer value for a meaningful segment of exposed users. Engineering and marketing resist a full rollback, citing the campaign investment. The response separates the two questions explicitly: "the $2M is spent regardless of what we do today; the question in front of us is whether continuing to run this feature costs us more in ongoing customer value than the marginal campaign benefit we would lose by stopping now." Presenting the ongoing cost in the same dollar terms as the original campaign's expected ROI reframes the conversation productively, and the team agrees to a scoped rollback limited to the segment where the harm is concentrated, preserving the campaign's benefit for the segment where no harm was detected.

Trade-offs and pitfalls: The most common mistake is treating this purely as a persuasion problem (finding the right words to win the argument) rather than a framing problem (getting everyone to evaluate the same, correctly-scoped forward-looking comparison); once the framing is right, the argument often resolves itself. The other pitfall is proposing an all-or-nothing rollback when a scoped, partial option would address the actual harm while preserving legitimate value elsewhere, which needlessly maximizes organizational resistance to a decision that did not need to be all-or-nothing.

Direct answer

I build depth in the same order I'd want to trust anyone else's expertise: reproduce something already known to be correct before attempting anything novel, set explicit checkpoints where I decide to continue, change approach, or escalate, and treat "genuinely ready" as a specific test, a real piece of my own work standing up to a domain expert's scrutiny, rather than the fluent feeling of finally being able to use the right vocabulary in a meeting.

How I would build the depth

Secure access first. Whatever gates the work, a dataset, a piece of hardware, compute, or access to the right people, I identify and secure it in week one rather than discovering three weeks in that I've been blocked the whole time. This is the dependency most likely to quietly eat a three-month timeline.

Sequence theory before building, but interleave rather than front-load. I learn just enough of the underlying fundamentals to understand why the standard approaches work, then move into hands-on work quickly and let each build cycle pull in more theory as it becomes necessary, rather than spending the first month purely reading before touching anything real.

Reproduce a known result before attempting anything new. Before I trust my own judgment here, I reproduce an existing, already-validated result: someone else's published finding, a vendor's documented benchmark, or a piece of work a teammate already completed correctly. If I can't reproduce something known to be right, I'm not ready to originate something new, no matter how fluent I've become in the terminology.

Set checkpoints with real decision criteria, not just calendar dates. At each checkpoint I ask explicitly: am I on track to continue as planned, do I need to pivot the approach, or is this blocked in a way that needs escalating now rather than being discovered in month three. I also decide my evaluation metrics before I start, not after, so I'm not tempted to redefine success once I see how the work is going.

Test readiness against an expert, not against my own confidence. The real test of "genuinely ready" is producing a piece of work with real stakes and having someone who already has depth in the area review it and try to break it. Passing that is different from holding a fluent conversation about the topic; vocabulary fluency is necessary but not sufficient, and it's the trap that makes people feel ready before they are.

Worked example

Given three months to become the team's authority on a caching and consistency mechanism the team was about to depend on for a major project, I first confirmed access to a realistic test environment, since the production-like setup was gated behind another team and would have cost two weeks if I'd waited to ask. I spent the first two weeks on the underlying theory just deeply enough to understand the trade-offs, then spent the rest of month one reproducing a known, previously documented failure mode from the vendor's own case studies in our environment, to prove I understood the mechanism rather than just its description. At a one-month checkpoint I judged myself on track and continued; at a two-month checkpoint, a contingency I had planned for, a related dependency becoming unavailable, actually happened, and having already thought through the fallback meant it cost days, not weeks. The real readiness test came in month three: I proposed a design that depended on this mechanism and had the engineer who had run it in production for years review it specifically to find where it would break under real load, not lab conditions. She found one case, a rare failure mode during a specific kind of failover, that I would not have caught, and that correction, not my ability to explain the mechanism fluently, is what told me I still had a gap to close.

Trade-offs and pitfalls

The trade-off is time spent proving readiness against time spent doing new work; skipping the reproduction and expert-review steps to move faster is exactly how vocabulary fluency gets mistaken for real depth. The most common pitfall is testing understanding only in lab or theoretical conditions and never against real, messier ones, which is precisely where the gap between fluent and ready tends to hide.

Direct answer

Separate two different problems that this situation creates: what work gets cut or deferred, and who now has the authority to make the calls the departed person used to make alone. The second one is the part most answers miss, and it matters most for whichever category of decision carries the highest risk if it goes unreviewed.

Decision framework

1. Triage by impact and reversibility. Classify remaining roadmap items into must-ship (a real customer or compliance commitment), valuable-but-deferrable, and nice-to-have. Cut the nice-to-have items immediately, and for the must-ship items, identify specifically which ones depended on the departed person's unique, undocumented knowledge.

2. Put a temporary safeguard on the highest-risk decisions specifically. Assign a temporary decision-owner, often the next most senior person or the manager, but require a mandatory second review for exactly the category of decision the departed person used to make solo, such as architecture or technical design calls, rather than letting one new person inherit unilateral authority by default.

3. Communicate the revised plan and the new decision process together. Stakeholders need both: what's cut or delayed, and who to go to for what while the arrangement is temporary.

4. Document to reduce single-person dependency going forward. Capture the departed person's undocumented reasoning, not just their outputs, and change the standing process so future high-risk work always has a documented secondary owner, not only as an emergency response this one time.

Worked example: the lead building a fraud-detection scoring pipeline, one of five people on the team, resigns with two weeks notice, and their replacement won't start for eight weeks. The quarter's roadmap has six remaining items. Triage: two items are customer-committed with a regulator-driven deadline (must-ship), three are deferrable roadmap improvements, and one is a nice-to-have refactor, which I cut for the quarter. Of the two must-ship items, one depends on undocumented model-threshold tuning logic that only the departed lead understood. Safeguard: I assigned a senior remaining engineer as temporary technical decision-owner for the pipeline, but required any threshold or architecture change to get a second review from a named machine learning engineer on an adjacent team, with a 24-hour service level agreement (SLA, a committed turnaround time) for that review, specifically because threshold changes carry real financial and compliance risk, and no single person on the reduced team had full context to safely decide alone. Communicate: I presented the revised roadmap (two must-ship items kept, three deferred, one cut) and the new temporary review process to department stakeholders and the departing lead's manager within the first week, explicit that this was an eight-week interim arrangement, not a permanent capacity cut. Document: I spent six hours of the departing lead's remaining two weeks in structured knowledge transfer specifically on the threshold-tuning logic, recorded as a written runbook plus a 40-minute screen-recorded walkthrough, and instituted a standing rule that any pipeline with real financial or compliance impact must have two people who can explain its core logic, verified at each quarterly review.

Second example (different discipline): a content team's sole search-engine-optimization (SEO) strategist leaves mid-quarter. The editorial lead cuts two experimental content formats, keeps the core publishing cadence, puts a temporary two-person review on any page-structure or metadata change since that was the departed strategist's unilateral domain, tells stakeholders to expect a lighter cadence for six weeks, and documents the strategist's undocumented keyword-research process into a shared playbook so the next hire isn't starting from zero.

Trap to avoid

The mediocre answer treats this purely as a staffing or backfill problem, "we'd hire quickly" or "redistribute the work," without addressing the governance gap: who now has the authority the departed person had, and what specifically stops a wrong high-stakes call from going unreviewed simply because there's no one left who would have caught it.

Direct answer

CUPED (Controlled-experiment Using Pre-Experiment Data) is a variance-reduction technique, published by Microsoft researchers (Deng, Xu, Kohavi and Walker, 2013), that uses a metric measured before the experiment started to strip out some of the between-user noise in the outcome metric, without touching the unbiasedness of the treatment-effect estimate. It requires one thing: a pre-experiment value of a covariate, ideally the same metric you are about to test, measured for the same units, from a period before assignment happened (so it cannot itself have been affected by treatment). The payoff is a tighter estimate of the same treatment effect from the same traffic, which functionally means you can detect the same effect size with less traffic or in less time.

Structured elaboration

What it requires and assumes

• A pre-experiment covariate $X$ for every unit, measured strictly before random assignment (so treatment cannot have influenced it) and ideally correlated with the outcome $Y$ you're testing.
• The scaling coefficient must be estimated without using the treatment label, typically pooled across both arms or from control alone. This is what keeps the adjustment from injecting bias: you are not letting "knowledge of which arm someone is in" leak into how you weight their pre-period value.

How the adjustment is computed, in plain terms

For each unit, adjust its outcome by subtracting a scaled version of how far its pre-experiment covariate was from the population average:

$Y_i^{\text{CUPED}} = Y_i - \theta \left(X_i - \bar{X}\right)$

where the scaling coefficient is the population covariance of $X$ and $Y$ divided by the variance of $X$:

$\theta = \frac{\operatorname{Cov}(X, Y)}{\operatorname{Var}(X)}$

Intuitively: if a user's pre-period activity was above average, some of their post-period activity being above average too is "expected" and not informative about treatment, so it gets subtracted out. The treatment effect is then estimated as the difference in adjusted outcome means between arms, $\bar{Y}^{\text{CUPED}}_{\text{treat}} - \bar{Y}^{\text{CUPED}}_{\text{control}}$, which is algebraically the same as the raw mean difference minus $\theta$ times the pre-period mean difference between arms; since randomization makes that pre-period difference expected to be zero, the adjustment does not shift the expected value of the estimate, it only removes the part of each unit's variance that $X$ already explained.

The resulting variance reduction has a clean form: if $\rho$ is the correlation between the pre-experiment covariate and the outcome, the adjusted estimator's variance is $(1-\rho^2)$ times the unadjusted variance. A stronger pre-period predictor buys a bigger reduction; a weak one buys almost nothing.

What makes a covariate good or poor

What goes wrong with a poor choice

• Using a post-treatment or treatment-adjacent value as $X$ breaks the "cannot be affected by treatment" requirement and reintroduces bias: you would be conditioning on something treatment itself moved, which is a different and more serious problem than losing precision.
• Using a weakly correlated covariate costs almost nothing in bias but also buys almost nothing in variance reduction; the $(1-\rho^2)$ factor is close to 1.
• Using a covariate that is missing for a large share of units (commonly new users with no pre-period history) forces a choice: drop those units (losing sample and possibly biasing toward existing users) or impute a value (introducing a modeling assumption you did not need before).

Worked example

Suppose, for illustration, we assume a pre-experiment 7-day conversion rate correlates with the in-experiment conversion rate at $\rho = 0.6$ for a given product (a hypothetical, stated input, not an empirical claim about any real product). The variance reduction from CUPED is then derived directly:

$\frac{\operatorname{Var}(Y^{\text{CUPED}})}{\operatorname{Var}(Y)} = 1 - \rho^2 = 1 - 0.6^2 = 1 - 0.36 = 0.64$

So the adjusted estimator's variance is 64% of the unadjusted one, a 36% reduction, given only the stated assumption $\rho = 0.6$. If $\rho$ had instead been a weak 0.2, the reduction would be $1 - 0.04 = 0.96$, i.e., only a 4% cut, illustrating why the strength of the pre-period correlation, not just its existence, determines whether CUPED is worth implementing for a given metric.

Trade-offs and pitfalls

• CUPED does not help metrics with no meaningful pre-experiment history, most obviously new-user-only experiments; for those, look at stratification or other covariate-adjustment techniques instead.
• Estimating $\theta$ using data that has already been split by arm (rather than pooled or control-only) risks contaminating the coefficient with treatment information; keep the estimation step blind to arm assignment.
• CUPED reduces variance, it does not change what the true effect is; do not present the tighter confidence interval as evidence the effect itself grew, only that you can now see it more precisely.
• CUPED composes with stratified randomization (apply the adjustment within strata), which is a reason to know both rather than treat them as competing choices.

Direct answer: NumPy vectorized aggregation (integer-encode the category labels, then np.bincount) can meaningfully outperform pandas.groupby for simple numeric reductions like sum, count, or mean on a single column, because it skips the general-purpose machinery groupby carries for mixed dtypes, missing values, and multi-column, multi-aggregation pipelines. Once your aggregation needs any of that generality, pandas.groupby becomes the better choice again, both for correctness and for how much code you'd otherwise have to hand-write and maintain.

Structured elaboration, worked end to end (verified, pandas 3.0.3, numpy 2.5.1, seed 0, 20 rows, 4 groups, fully reproducible):

When NumPy wins: you have one (or a few) numeric column(s), a single simple reduction (sum, count, mean), category labels that can be mapped to small contiguous integers, and no missing values to reason about. np.bincount computes a per-group sum or count in one pass with none of groupby's dtype dispatch, index bookkeeping, or Python-level overhead per group.

import numpy as np
import pandas as pd

rng = np.random.RandomState(0)
N, G = 20, 4
groups = rng.randint(0, G, size=N).astype(np.int32)
values = rng.randn(N)

sums = np.bincount(groups, weights=values)   # per-group sum, one pass
counts = np.bincount(groups)                 # per-group count
means = sums / counts                        # handle any zero-count group separately
print('sums =', sums)
print('counts =', counts)
print('means =', means)

Verified output: sums = [-0.4656, -0.0095, 4.4562, 1.9245], counts = [6, 4, 3, 7], means = [-0.0776, -0.0024, 1.4854, 0.2749] for groups 0-3.

If you need to accumulate in place or handle repeated indices explicitly rather than via weights=, np.add.at is the safe alternative:

acc = np.zeros(G, dtype=np.float64)
np.add.at(acc, groups, values)
print('np.allclose(acc, sums) =', np.allclose(acc, sums))

Verified: acc equals sums above exactly (np.allclose(acc, sums) is True).

Correctness check against pandas.groupby, same data:

df = pd.DataFrame({'cat': groups, 'val': values})
means_pd = df.groupby('cat')['val'].mean()
print('means_pd (sorted by group) =', means_pd.sort_index().to_numpy())
print('max abs difference =', np.max(np.abs(means_pd.sort_index().to_numpy() - means)))

Verified output: means_pd (sorted by group) is [-0.077606, -0.002381, 1.485384, 0.274924], identical to means above to 15 decimal places, max absolute difference 5.6e-17 (floating-point rounding noise, not a real difference). This confirms both approaches compute the identical aggregation on real data, so the choice between them is purely about performance and generality, not correctness. (Wall-clock timing numbers are intentionally omitted here since they are hardware- and environment-dependent and this small fixture is too small to be a fair benchmark anyway; the mechanism below is what actually explains the gap at scale.)

Why NumPy is faster for this narrow case: np.bincount is a single specialized C loop over a pre-encoded integer array with no per-row dtype checks, no handling of missing group labels, and no construction of an intermediate grouped-object representation. pandas.groupby builds a grouping object, handles arbitrary key types (strings, categoricals, tuples of columns), preserves index alignment, and supports dozens of aggregation functions and multi-column .agg() dictionaries, all of which cost something even when your specific case doesn't need it.

When pandas.groupby is preferable despite the difference

• Mixed dtypes or non-numeric group keys, groupby handles string, categorical, and datetime keys directly; you would have to build your own integer encoding by hand for NumPy.
• Missing values that need to be preserved or explicitly excluded, groupby has consistent, well-tested NaN (not-a-number, pandas' missing-value marker) handling; a hand-rolled bincount pipeline requires you to reimplement that correctly.
• Multiple different aggregations per column or across columns in one pass, e.g. df.groupby('cat').agg({'sales': 'sum', 'user': 'nunique'}), this is one readable call in pandas versus several hand-written NumPy passes.
• Time-aware or hierarchical grouping (resampling, groupby(level=...) on a MultiIndex).
• Code clarity and fewer manual edge-case bugs: division-by-zero on empty groups, sort/stability guarantees, and correct alignment back to the original frame are all handled for you.

Complexity: both approaches are O(n) in the number of rows for a single-pass reduction like sum or count; the difference is in the constant factor, not the asymptotic order, bincount has a smaller constant because it avoids groupby's per-row dispatch and object overhead. Memory is O(G) for both, where G is the number of distinct groups (the accumulator array in one case, the grouped result index in the other), so this trade-off is about per-row overhead and generality, not about complexity class.

Trade-offs and pitfalls

• Reach for the NumPy path only when you can cleanly map categories to small contiguous integers up front (pd.factorize does this for you and returns exactly what bincount needs) and your aggregation genuinely is that simple. Building and maintaining that encoding for a case that doesn't actually need the speed is wasted complexity.
• Benchmark on your real data and hardware before committing to the NumPy path in a production pipeline, the size of the gap depends heavily on group count, row count, and dtype, and groupby's internal implementation improves across pandas releases.
• A common middle ground: use pandas.groupby for exploratory work and multi-aggregation reporting, and drop to a NumPy pre-aggregation pass only in a narrow, profiled hot path where it has been measured to matter.

Direct answer

Conversion rate is conversions divided by a chosen denominator, and the denominator choice is the single biggest source of misinterpretation: sessions, unique users, and qualified users answer different questions and can move in opposite directions from the same underlying data. Deduplication rules, bot filtering, and the attribution window compound that risk.

Structured elaboration

Other pitfalls compound the denominator choice: deduplicate repeat conversions according to an explicit business rule (funnel-step conversion is usually deduped per user, while lifetime-value counting may allow repeats); resolve identity across devices (an authenticated user_id, or a deterministic cross-device link) before trusting a "unique users" denominator at all, since the same person on a phone and a laptop is otherwise silently counted as two separate users, understating the true per-person rate; filter known bots and test traffic before computing the rate rather than adjusting after the fact; and choose an attribution window (same-day, 7-day, 30-day) and touch model (last-touch versus multi-touch) that matches how long the product's typical purchase decision actually takes.

The same reasoning is not specific to "conversion rate": any X-per-Y ratio metric built the same way, for example an engagement rate defined as engaged users divided by some population, faces the identical three-way sessions/users/qualified-users choice, the identical deduplication and cross-device question, and the identical bot-filtering discipline. Getting the denominator right is a general metric-definition skill, not a conversion-specific one.

Worked example

Consider a checkout redesign tested against the same 15,000 unique users in both control and treatment, where the redesign happens to make people browse more before converting.

Reported on sessions, the redesign looks like a 16% regression. Reported on unique users, the same underlying data shows a genuine 5% improvement: the same population converted more often, they just also returned to the site more often per person, which inflates the session count without representing a real drop in intent-to-convert. Switching only the denominator flips the conclusion from "kill this feature" to "ship it."

Trade-offs & pitfalls

• Reporting only one denominator without stating it invites stakeholders to compare periods where the true unit changed (a redesign that structurally alters sessions-per-user, for example); always publish the denominator definition next to the rate.
• Bot and test traffic dilutes whichever denominator is chosen; filter it upstream rather than adjusting the formula after the fact.
• Attribution-window choice trades undercounting slow conversions (window too short) against overcounting exposures unrelated to the observed session (window too long); pick a window matched to the typical purchase-consideration cycle and state it.
• Always report the raw counts, numerator and denominator, next to the percentage, so a reader can sanity-check both the direction of the change and the sample size behind it.

Direct answer. Write out each source's SELECT explicitly, renaming columns to a common set of names and adding any column that's missing on one side as an explicit NULL (or a sensible default) cast to the right type, so every branch of the UNION ALL produces an identically-shaped row.

Structured elaboration. UNION ALL requires the same number of columns, in the same order, with compatible types, across every branch, it does NOT reconcile mismatched column names or missing columns for you. The fix is mechanical: pick one canonical column list, and for each source, alias its columns to match, and explicitly supply a typed NULL for any column that source doesn't have at all.

Worked example. logs_v1(event_time, event_type): ('2025-01-01 10:00:00', 'view'). logs_v2(ts, type, user_id): ('2025-01-01 11:00:00', 'click', 5) (logs_v2 has an extra user_id column that logs_v1 lacks entirely).

SELECT event_time, event_type, CAST(NULL AS INTEGER) AS user_id FROM logs_v1
UNION ALL
SELECT ts AS event_time, type AS event_type, user_id FROM logs_v2
ORDER BY event_time;

Result: ('2025-01-01 10:00:00', 'view', NULL), ('2025-01-01 11:00:00', 'click', 5). logs_v1's rows correctly show a NULL user_id (since that source never captured it), and both sources' columns are now under one consistent set of names.

Trade-offs and pitfalls. The choices you make for a column that only exists on one side matter: a bare NULL correctly communicates "this source never captured this," and is usually the honest choice; a manufactured default (0, or an empty string) can look like real data to anyone querying the combined view later and should only be used if it's genuinely meaningful, not just to avoid a NULL. It's also worth explicitly casting the NULL to the target type (as shown above), since some engines will otherwise infer a type for an untyped NULL that doesn't match the corresponding column in the other branch, causing a type-mismatch error or an unwanted implicit cast across the whole UNION.

Direct answer

Walk the list once, and at each node redirect its next reference back to the previous node before advancing, using three tracking references: previous, current, and a temporary save of current's original next. This is $O(n)$ time and $O(1)$ space. A recursive version expresses the identical rewiring, handling everything after the current node first and then flipping the one link back, but it pays for that with $O(n)$ call-stack space that the iterative version does not need.

Structured elaboration

The iterative three-pointer dance. Before overwriting curr.next, save it in a temporary variable, or the rest of the list is lost permanently. Then point curr.next back at prev, advance prev to curr, and advance curr to the saved temporary. Repeat until curr is empty.

The recursive version. The base case is an empty list or a single remaining node, which is already "reversed" as-is. Otherwise, recursively reverse everything after the head first; that recursive call returns the new head of the whole reversed list. Then head.next.next = head flips the one link connecting the old head back into the newly-reversed remainder, and head.next = None prevents the old head from accidentally pointing at itself in a two-node cycle.

What language a solution is written in does not change any of this. The reskin into Python, JavaScript, Swift, or Kotlin, or building the linked-list node class from scratch first, is the same pointer-rewiring skill underneath; only the syntax for holding and dereferencing a reference changes, not the three-step relinking logic itself.

Worked example

class Node:
    def __init__(self, val, next=None):
        self.val = val
        self.next = next


def reverse_iterative(head):
    prev = None
    curr = head
    while curr:
        next_tmp = curr.next  # save before overwriting
        curr.next = prev
        prev = curr
        curr = next_tmp
    return prev


def reverse_recursive(head):
    if head is None or head.next is None:
        return head
    new_head = reverse_recursive(head.next)
    head.next.next = head
    head.next = None
    return new_head


def to_list(head):
    out = []
    while head:
        out.append(head.val)
        head = head.next
    return out


def build_list(vals):
    dummy = Node(0)
    tail = dummy
    for v in vals:
        tail.next = Node(v)
        tail = tail.next
    return dummy.next


if __name__ == "__main__":
    print(to_list(reverse_iterative(build_list([1, 2, 3, 4]))))
    print(to_list(reverse_recursive(build_list([1, 2, 3, 4]))))

Running this prints [4, 3, 2, 1] twice, once from each implementation.

Complexity

Time: $O(n)$ for both the iterative and recursive versions, since each one visits every node exactly once.
Space: $O(1)$ extra for the iterative version (three pointer variables regardless of list length); $O(n)$ for the recursive version, from the call stack, since the recursion descends one frame per node before any relinking happens.

Edge cases

• Empty list (head is None): both versions return None immediately without any relinking.
• Single-node list: both versions return that same node unchanged as the new head, since there is nothing to reverse.
• Very long list: the recursive version risks an actual stack overflow, since typical call-stack depth limits are far smaller than what a linked list can otherwise hold in memory.

Trade-offs & pitfalls

The recursive version risks an actual stack overflow on a very long list in production, not just an academic concern, since typical call-stack depth limits are far smaller than what a linked list or array can otherwise hold in memory. The single most common bug in the iterative version is forgetting to save curr.next before overwriting it, which permanently disconnects the rest of the list from anything still reachable.