Applied Scientist, Junior Level - Lyft Interview Preparation Guide

Direct answer

At every midpoint, exactly one of the two halves relative to mid is guaranteed to be a normally-ordered, unbroken sorted run, because a rotation introduces at most one discontinuity and mid splits the array so that discontinuity can only fall on one side. Check which half is sorted by comparing the value at the low end to the value at mid; then decide whether the target lies within that sorted half's own range, and search there, or search the other half. This preserves $O(\log n)$ time.

Structured elaboration

Decision rule. If nums[lo] <= nums[mid], the left half [lo, mid] is a normal ascending run. Otherwise, the right half [mid, hi] is the one that must be a normal ascending run instead.

Why exactly one side is always sorted. The array is a rotation of a sorted array, so it consists of two ascending runs joined at one rotation point (or one run, if there was no rotation). Splitting the array at mid means that single rotation point can only fall strictly inside the left half or strictly inside the right half (or at neither, if the whole array happens to still be sorted), never inside both.

Using the sorted half. Once you know a half is a genuine ascending run, checking whether the target falls within its own low/high bounds is an ordinary, $O(1)$ sorted-range check, which tells you definitively whether to descend into that half or discard it and search the other one.

Worked example

def search_rotated(nums: list[int], target: int) -> int:
    lo, hi = 0, len(nums) - 1
    while lo <= hi:
        mid = (lo + hi) // 2
        if nums[mid] == target:
            return mid
        if nums[lo] <= nums[mid]:
            if nums[lo] <= target < nums[mid]:
                hi = mid - 1
            else:
                lo = mid + 1
        else:
            if nums[mid] < target <= nums[hi]:
                lo = mid + 1
            else:
                hi = mid - 1
    return -1


if __name__ == "__main__":
    nums = [4, 5, 6, 7, 0, 1, 2]
    print(search_rotated(nums, 0), search_rotated(nums, 3))

Running this prints 4 -1. Tracing target 0: lo=0, hi=6, mid=3 (value 7); nums[0]=4 <= nums[3]=7, so the left half is sorted, but 0 is not in [4, 7), so search moves right, lo=4; mid=5 (value 1); nums[4]=0 <= nums[5]=1, left half (now [4,6]) is sorted, and 0 is in [0, 1), so hi becomes 4; lo=4, hi=4, mid=4, nums[4]=0 matches, return 4.

Complexity

Time: $O(\log n)$, since each step still discards at least one half of the remaining range, exactly as in ordinary binary search.
Space: $O(1)$, since the iterative version only tracks a fixed number of index variables (lo, hi, mid) regardless of the array's size.

Edge cases

• No rotation at all: the whole array is one ascending run, so nums[lo] <= nums[mid] is always true and the algorithm degenerates to ordinary binary search.
• Single-element array: lo == hi == mid on the first iteration, so the loop either matches immediately or returns the sentinel.
• Duplicates with nums[lo] == nums[mid] == nums[hi]: the algorithm cannot tell which side is genuinely rotated, and the worst case degrades to $O(n)$, as discussed below.

Trade-offs & pitfalls

The comparison nums[lo] <= nums[mid] must use <=, not <: a range that has collapsed to a single element or two equal adjacent elements should still count as sorted, and using strict < there can misclassify that case. If duplicates are allowed and nums[lo] == nums[mid] == nums[hi], the algorithm cannot tell which side is genuinely rotated, and the worst case degrades to $O(n)$ because you may have to shrink the range one element at a time to break the tie. Finding the pivot (the array's minimum) explicitly is a related but distinct $O(\log n)$ problem: it compares nums[mid] against nums[hi] rather than comparing the target against a sorted half's bounds.

Direct answer: Detecting and reproducing a training-serving inconsistency starts by comparing the exact feature values the model saw at training time against what the online path currently returns for the same entities, narrowing down whether the divergence is a stale cache, a missing key, or a serialization mismatch, and closing the loop with instrumentation that would catch this class of bug automatically going forward.

Structured elaboration:

1. Detect. Set up a systematic comparison: for a sample of entities, pull their feature values from the offline (training-time) computation and from the online serving path for the same point in time, and diff them; a consistently non-zero diff rate (not just occasional noise) confirms a real inconsistency rather than expected minor timing differences.
2. Reproduce. Narrow to specific entities showing the largest divergence and trace each one's value through the pipeline: what did the offline computation produce, what does the online store currently hold, and when was the online value last updated, which starts distinguishing the candidate causes.
3. Stale cache. If the online value's last-updated timestamp is old relative to when it should have refreshed, the online materialization pipeline itself may be lagging or failing silently for a subset of entities (worth checking if it correlates with a specific partition or shard); the fix here is addressing the materialization lag/failure, not the feature logic itself.
4. Missing keys. If some entities have no online value at all (falling back to a default or null that the offline path would not have produced), trace whether those entities are newly created (a cold-start gap between when an entity is created and when it first gets materialized online) or whether a upstream join or filter is silently excluding them from the online materialization pipeline that the offline pipeline does not exclude them from.
5. Serialization differences. If values exist on both sides but differ, check whether the offline and online computation paths are using genuinely the same transformation logic (a common root cause is the two paths having independently-implemented, subtly different logic, e.g. different rounding, different null-handling, or a unit mismatch) versus a serialization/deserialization bug (a type coercion, an encoding mismatch) that corrupts an otherwise-correct value on the way to or from the online store.
6. Instrumentation and tests to prevent recurrence. Add an automated, continuously-running online/offline consistency check (not just a one-time investigation) that samples entities and alerts if the divergence rate exceeds a threshold; add a unit or integration test asserting the offline and online computation paths, when fed the same input, produce identical output, so a future code change that lets the two paths drift apart is caught in CI rather than in production months later.

Worked example: The investigation finds that entities with a specific upstream data source (say, a newer mobile client version) show the highest divergence; tracing one such entity reveals the online path's transformation logic was updated recently to handle a new field from that client version, but the corresponding offline (batch) transformation logic was never updated to match, meaning the two paths have silently diverged for exactly the population using the new client, which explains both the false-positive symptom (features computed differently for a subset of the population) and why it was not caught immediately (it only affected a growing but still partial slice of traffic).

Trade-offs & pitfalls: A common trap is fixing the specific instance of divergence found (patching the online or offline logic to match) without addressing why the two paths were able to drift apart in the first place; the durable fix is usually architectural, such as sharing the actual transformation code between the offline and online paths (a single source of truth for the logic, executed in both a batch and a streaming/serving context) rather than maintaining two independently-written implementations that have to be manually kept in sync, which is the root cause this class of bug keeps recurring from in practice.

Direct answer

Rather than just resampling existing data, change what data you COLLECT in the first place: add targeted labeling triggers that specifically capture more positive examples as they occur, instrument the product to surface precursor signals of churn earlier, and be careful the new collection process doesn't itself introduce a fresh sample-selection bias.

Structured elaboration

Targeted labeling triggers: rather than passively waiting for churn events to accumulate at their natural (low) rate, actively flag and prioritize labeling for customers showing early churn-precursor signals (a support ticket, a usage drop, a failed payment), which both surfaces more genuine positive examples faster and, if done thoughtfully, captures the EARLY signal that's most useful for prediction rather than only the eventual outcome.

Instrumentation changes: add logging or tracking for behaviors hypothesized to precede churn (declining login frequency, a specific feature going unused) that may not currently be captured at all, since you can't use a signal you never recorded, no matter how sophisticated your later modeling is.

Avoiding new sample-selection bias: be deliberate that the NEW collection process doesn't systematically over-represent one kind of churn (only customers who file a support ticket before churning, missing the larger population who churn silently) or one customer segment (only actively-monitored high-value accounts), since a biased collection process produces a model that's excellent at predicting the KIND of churn it was trained to see and blind to other kinds.

Worked example

For a subscription product with a genuine 2% monthly churn rate, instead of only labeling churn after it's already happened, the team might add tracking for "days since last login" and trigger a lightweight manual review whenever an account crosses a threshold (say, 14 days inactive), producing both more labeled examples faster AND examples that capture the PRECURSOR state, not just the final churn event, which is often more useful signal than the churn event itself.

Trade-offs and pitfalls

The judgment call at the center of this whole strategy is distinguishing "legitimately capturing more real signal" from "changing the population you're studying in a way that biases your data": a well-designed instrumentation change surfaces MORE of the true churn population earlier; a poorly-designed one (triggering extra scrutiny only on customers already flagged by an existing, imperfect heuristic) can inadvertently narrow your definition of "churn" to whatever that heuristic already catches, making the resulting model better at confirming the existing heuristic than at genuinely improving on it.

Risk summary: repeatedly "peeking" at A/B test results without a stopping rule inflates the Type I error: each look multiplies the chance of a false positive, so a nominal 5% alpha can become much larger. Optional stopping without adjustment undermines p-values and confidence intervals, leading to wrong product decisions, wasted rollout effort, and biased effect estimates.

Concretely, how much peeking actually costs you: with the classical result on repeated significance testing (Armitage, McPherson and Rowe, 1969), if you peek at an A/B test 5 times and stop as soon as p < 0.05 at any look with no correction, the actual probability of a false positive over the whole experiment is roughly 14%, not 5%. Peek 10 times and it climbs to roughly 19 to 20%. That is the concrete size of the problem the methods below are built to fix: they re-allocate the same 0.05 total alpha budget across the planned looks so the cumulative false-positive rate, however many times you check, comes back down to 5%.

Statistical techniques to control Type I error under optional stopping:

• Alpha-spending functions (group-sequential framework)

  • Idea: pre-allocate the overall alpha across planned looks using a spending function that maps information fraction (the fraction of the planned total sample size you have collected so far, e.g. 0.5 once you are halfway through the planned sample) to cumulative alpha spent.
  • Benefit: flexible schedule (deterministic or information-driven) that maintains the overall Type I error.
  • Practical note: requires pre-specifying a maximum number of looks or maximum information; works well when you can estimate information accrual.

• Pocock boundaries

  • Equal critical values at each interim look (more liberal early, moderately conservative overall).
  • Good when you expect several interim looks and want simple, constant thresholds.
  • Trade-off: more alpha spent early means less power at the final sample size than a more conservative design.

• O'Brien-Fleming boundaries

  • Very conservative early thresholds, close to nominal at the final look.
  • Good when you want strong protection against false positives early while allowing decisive evidence later.
  • Trade-off: hard to stop early because early thresholds are very strict.

Worked comparison (3 planned looks, total two-sided alpha = 0.05):

Under O'Brien-Fleming you would need an almost-impossible p < 0.0005 to stop at the first look, and only need an ordinary-looking p < 0.045 by the third; under Pocock the bar is roughly the same p < 0.022 at every look, including the last one, which is stricter than the 0.05 you would use in a single unplanned test. Both designs spend the same total 0.05 alpha across the 3 looks, they just spend it on different schedules: O'Brien-Fleming makes stopping early nearly impossible so it preserves power for a decisive final look, Pocock makes stopping equally easy at any look but pays for that with a stricter bar even at the final look.

• Bayesian sequential testing
  • Uses posterior probabilities or Bayes factors (a Bayes factor is the ratio of how much more likely the observed data is under "there is an effect" versus "there is no effect": a Bayes factor of 10 means the data is 10 times more consistent with there being an effect); allows continuous monitoring without inflating Type I error in the Bayesian sense, since optional stopping is coherent once priors and decision rules are specified up front. Concretely, coherent looks like this: you pre-register a 50/50 prior on "variant B is better" and a stopping rule of "stop and ship once the posterior probability that B is better exceeds 95%". If that posterior crosses 95% at look 2 out of a planned 5, you stop and ship, because the rule and the prior were both fixed before any data was seen: nothing about seeing the data changes the coherence of a decision made against a pre-specified rule, unlike a frequentist p-value threshold checked ad hoc after every new data point comes in.
  • Practical caveats: decisions depend on the chosen prior and loss function; regulators or businesses often still expect frequentist-style error guarantees, so calibration via simulation is recommended.
  • Advantages: intuitive decision metrics (e.g. P(effect > 0) > threshold), easier to communicate to product teams.

Practical recommendations for product teams

• Pre-specify a stopping plan. Never peek ad hoc.
• If you need frequent monitoring but want familiar frequentist guarantees: use alpha-spending with either Pocock (simple constant threshold) or O'Brien-Fleming (strict early control). Implement using an existing group-sequential design package, such as R's gsDesign, which directly supports alpha-spending functions and both the Pocock and O'Brien-Fleming boundary shapes, rather than hand-deriving them; validate the resulting stopping rule against your actual metric's variance via simulation before trusting it on real traffic.
• If you prefer flexible, decision-focused rules and can simulate and calibrate: use a Bayesian stopping rule with transparent priors and thresholds, and run simulations to map the Bayesian thresholds to the frequentist error rates stakeholders will ask about.
• For most product teams: an alpha-spending group-sequential design with a few planned looks, or a well-calibrated Bayesian approach, are the practical options: both are implementable, explainable, and prevent false positives while enabling early stopping when the evidence is strong.

Requirements

• Watch a shared folder, validate each report, aggregate metrics, and write one daily summary.
• Keep running if one file is bad.

Design
I would prefer a scheduled scanner over a pure file watcher, because shared folders can miss events. The CLI would:

1. list files in incoming/
2. move each file atomically to processing/
3. validate and parse it
4. write metrics to a temp summary file
5. rename the temp file to the final output when complete

Idempotent design
Idempotent means running it twice produces the same result, with no duplicate output. I would track a checksum or a (date, filename) key in a small state file or SQLite table. If the same file appears twice, skip it. If the run dies midway, rerun only unprocessed files.

Debuggability

• structured logs with filename, checksum, line number, and error
• quarantine bad files in failed/ with a reason file
• counters for processed, skipped, and failed
• a --file replay mode for one broken input

Worked example: if ops_2025-07-03.csv has a bad line 18, the run should still finish the other files, mark that one as failed, and include the failure in the final summary. That makes the job observable instead of mysterious.

Direct answer

lst[start:stop:step] returns a NEW list built by copying references at indices start, start+step, start+2*step, ... up to but not including stop. Negative indices count from the end (-1 is the last element), and a negative step walks backward. Unlike numpy, Python list slicing always copies, it never returns a view, so a slice of length k from a list of length n costs O(k) time and O(k) extra memory, not O(n).

Structured elaboration

Syntax mechanics. start defaults to 0 (or len(lst) for a negative step), stop defaults to len(lst) (or "through the beginning" for a negative step), step defaults to 1. Negative indices are resolved to positive ones first (-1 -> len(lst) - 1), then the normal start/stop/step machinery applies.

Negative step behavior. A negative step reverses the walk direction. lst[::-1] is the idiomatic full-list reverse; lst[5:1:-2] starts at index 5 and walks backward by 2 until it would reach or pass index 1.

View vs copy. List slicing is always a full copy, a genuinely new list object with its own storage, which is why mutating the slice's result never affects the original list (demonstrated below). This differs from numpy, where basic slicing (not fancy or boolean indexing) returns a VIEW sharing the same underlying buffer, and mutating the view does mutate the source, which is a separate consideration when choosing between the two.

Time and memory complexity. Creating lst[a:b] where b - a = k does exactly k reference copies: O(k) time and O(k) new memory, regardless of how large the source list n is. A common misconception is that slicing costs O(n) because "it touches the whole list": it does not, it only touches the k elements it copies.

Site Reliability Engineering (SRE)-specific danger and alternatives. Repeatedly slicing a large in-memory structure (for example, paginating through a multi-gigabyte log buffer with buf[i:i+chunk] in a loop) duplicates data on every slice, which can double memory pressure or trigger avoidable garbage-collection churn under load, exactly when an SRE (the on-call engineer responsible for a system's reliability) least wants unpredictable memory behavior during an incident. Alternatives that avoid the copy: itertools.islice for a lazy, non-copying iterator over a sequence; a plain generator or yield-based chunker; memoryview for byte-like buffers (bytes, bytearray, array.array), which does support zero-copy sliced views; or, for genuinely huge data, memory-mapping the source (mmap) instead of holding it as a Python list at all.

Worked example

data = [10, 20, 30, 40, 50, 60, 70]  # length n = 7, pinned

print("first three     data[:3]      =", data[:3])
print("last two        data[-2:]     =", data[-2:])
print("every other     data[::2]     =", data[::2])
print("reversed        data[::-1]    =", data[::-1])
print("middle (drop ends) data[1:-1] =", data[1:-1])
print("negative step   data[5:1:-2]  =", data[5:1:-2])

sub = data[1:4]
sub[0] = 999
print("after mutating sub, data      =", data, " (unchanged: slicing copied)")

import sys
n = 100_000
big = list(range(n))
small_slice = big[:10]
print("sys.getsizeof(big)        =", sys.getsizeof(big), "bytes")
print("sys.getsizeof(small_slice)=", sys.getsizeof(small_slice), "bytes")

Output:

first three     data[:3]      = [10, 20, 30]
last two        data[-2:]     = [60, 70]
every other     data[::2]     = [10, 30, 50, 70]
reversed        data[::-1]    = [70, 60, 50, 40, 30, 20, 10]
middle (drop ends) data[1:-1] = [20, 30, 40, 50, 60]
negative step   data[5:1:-2]  = [60, 40]
after mutating sub, data      = [10, 20, 30, 40, 50, 60, 70]  (unchanged: slicing copied)
sys.getsizeof(big)        = 800056 bytes
sys.getsizeof(small_slice)= 136 bytes

The size comparison makes the O(k) claim concrete: a slice of 10 elements from a 100,000-element list costs 136 bytes, not anywhere near the 800,056-byte cost of the full list, confirming the slice's footprint scales with k, not n.

Trade-offs and pitfalls

• Assuming slicing is "free" or O(1): it is O(k), which is cheap for small k but adds up when repeated over large chunks in a hot loop.
• Assuming list slicing returns a view like numpy does: it never does. If zero-copy behavior on a byte buffer is needed, reach for memoryview, not a list.
• Off-by-one errors with a negative step (lst[stop:start:-1]-style mistakes) are the single most common source of "why is my reversed slice missing an element."
• Rebuilding a large structure via repeated slicing inside an incident-response script is exactly the kind of thing that can turn a memory-pressure incident into a self-inflicted one.

Direct answer

When a stakeholder acts on a misread model output, I treat it as three separate problems: what actually happened this time, why the interface or documentation allowed that misreading, and what changes so the same mistake cannot repeat quietly. I fix the immediate decision first, then the underlying cause, in that order, because correcting the person without fixing the surface just moves the same failure to the next person who reads the same number.

Structured elaboration

Diagnosing where the misunderstanding came from:

• I reconstruct exactly what they saw: the specific report, dashboard view, or export, including any rounding or formatting, not a description of it from memory.
• I check what the number actually represents (a probability, a percentile, a relative rank) against what was documented at the point where they saw it, since a mismatch there is often the whole story.
• I ask the stakeholder directly what they believed the number meant before I correct them, because their mental model tells me exactly which assumption to fix, rather than guessing.

Correcting the stakeholder without damaging trust:

• I explain using their own example rather than a generic one: the exact score they acted on, what it actually represents, and what a decision consistent with that meaning would have looked like.
• I use one visual, for instance grouping scores into a few plain risk bands with what each band typically means, rather than a wall of statistics.
• I propose a concrete way to recover from the specific bad decision (for example, a follow-up outreach to the group that was incorrectly deprioritized) so the correction comes with a fix, not just a lesson.

Changing the documentation and interface so it does not recur:

1. Add a short, plain-language description directly attached to every exported report: what the number is (a probability, not a guarantee), the range it falls in, and the last time the model was retrained.
2. Change the interface itself, not just the documentation: label the number in plain terms next to the raw value ("estimated risk, not a guarantee"), group scores into named bands instead of showing a bare decimal, and add a short explanation of the main factors behind an individual score, so the person does not have to go find documentation to interpret what they are looking at.

Worked example

A product manager used a churn-risk model's output to stop marketing spend on customers scored as "low risk," treating the score as a firm "do nothing" signal. Churn in that segment rose shortly after. Reconstructing what they saw showed the export displayed a bare decimal like 0.12 with no label, and the model card describing it as a calibrated probability, not a threshold-based flag, lived in a separate document nobody had opened in months.

I walked the PM through their own export: "a score of 0.12 here means our model estimates roughly a 1 in 8 chance this customer churns, not that they are safe. Some of the customers you deprioritized were sitting right at that level." We agreed on an immediate fix, a short reactivation outreach to the deprioritized group, and I changed the export itself to show a labeled risk band ("Low: roughly 1 in 10 to 1 in 20") next to the raw score, plus a one-line note on the model's current calibration date, so the next person reading that same export sees the meaning without needing a separate document.

Trade-offs and pitfalls

• Fixing only the interface without also correcting the specific stakeholder in front of you leaves the earlier bad decision unaddressed; both steps are needed, not one instead of the other.
• Adding too much explanatory text directly into the interface (a full methodology paragraph on every screen) recreates the original jargon problem in a new location; the interface fix should be one short plain-language label, with deeper detail one click away for anyone who wants it.
• Renaming or re-bucketing scores changes how people act on them going forward, so it needs a short heads-up to the whole team that uses the export, not just the person who misread it, or you risk a second, different misunderstanding.
• Blaming the interface entirely can let a real communication gap go unaddressed if the stakeholder also skipped documentation that was genuinely available; the goal is to make the correct reading the path of least resistance, not to absolve every prior explanation of responsibility.

Direct answer

Constructive skepticism means treating a colleague's analysis as something to verify before it reaches people who will make a decision on it, not something to trust blindly or attack. What keeps it collaborative rather than adversarial is that the questions are aimed at the work, in service of the same goal the analyst has (a correct, defensible result), not aimed at their competence.

Structured elaboration

What to actually check

• Data provenance and cleaning: were there filters, joins, or exclusions applied that could bias the result?
• Assumptions and their sensitivity: does the conclusion hold under a slightly different time window, cohort definition, or parameter choice?
• Confounders and alternative explanations: could something else, like seasonality or a cohort mix shift, explain the pattern as well as the stated cause?
• Reproducibility: can someone else rerun the analysis and get the same numbers, and are the metric definitions written down anywhere?

How to raise it without it turning into a credibility fight

The framing matters more than the content. Raise it privately and early, before it's in front of stakeholders, not during the stakeholder meeting itself. Ask it as a question about the data or method ('what date range did you use for this cohort?'), not as a verdict about the person or their competence. Where possible, offer to help verify rather than only pointing out a gap; that keeps the interaction collaborative instead of adversarial. The deeper mechanics of de-escalating a tense disagreement are their own skill; the key move here is simply getting the framing and the timing right before it escalates into one.

Worked example

A colleague's dashboard shows a conversion metric trending in a direction that conflicts with what other data would suggest. Before it goes in front of stakeholders, a private message asks what date range and cohort definition were used, and whether a known seasonal effect was accounted for. It turns out the shift came from a change in how the cohort was defined that week, not a real change in behavior. The colleague fixes the definition before the meeting, and the stakeholder presentation goes out correct, with no public correction needed.

Trade-offs and pitfalls

• Raising a concern only after it's already in front of stakeholders turns a technical question into a public correction, which is exactly where it tends to become a credibility fight.
• Flagging every minor doubt in a public forum regardless of the stakes wears down trust and slows the team; reserve escalation for cases where a private check didn't resolve it and the decision at stake actually matters.
• Being right about a caught issue is not the same as handling it well; how the concern was raised often matters more to the relationship than the fact that it was correct.

Direct answer

When logistic regression training is oscillating or diverging, work through it as a checklist in this order: data and label correctness first, then feature scaling (the single most common cause), then numerical conditioning of the features, then optimizer hyperparameters (learning rate, batch size), then regularization as a stabilizer, then the numerical stability of the loss computation itself. Each step is cheap to check and rules out a large class of causes before you start tuning blindly.

Structured elaboration

1. Data and labels: confirm labels are correctly encoded (0/1, not NaN, not a stray value, not an inverted sign), check for duplicate or contradictory rows (identical features, different label), and confirm the train/validation split and any shuffling are correct. A bug here can look exactly like an optimization problem.
2. Feature scaling: logistic regression fit by gradient descent is very sensitive to feature scale. A feature ranging in the thousands next to one ranging in [0,1] makes the loss surface extremely elongated in one direction, so gradient descent overshoots along the large-scale direction and the loss oscillates or diverges. Standardizing (z-score) or min-max scaling every continuous feature resolves a large fraction of real-world divergence cases on its own.
3. Multicollinearity and numerical conditioning: check the correlation matrix and/or the condition number of the design matrix; near-duplicate or perfectly collinear columns, including the dummy-variable trap, make the loss surface nearly flat along some direction, which both slows convergence and makes it numerically unstable. Drop redundant columns or add regularization.
4. Optimizer hyperparameters: if scaling doesn't fix it, reduce the learning rate (try dropping it by 10x), and monitor the gradient norm and the loss per step; if the gradient norm is exploding, apply gradient clipping. Beyond plain gradient descent (which takes the same-size step in every direction), two categories of alternative are worth trying: Adam adjusts the step size separately for each parameter based on that parameter's recent gradient history, which is often more forgiving of imperfect feature scaling than plain SGD; LBFGS is a batch solver that uses curvature information (an approximation of second derivatives) to take smarter steps instead of a fixed learning rate. Since logistic regression's loss is convex, a well-implemented batch solver like LBFGS should converge reliably as a sanity baseline.
5. Regularization: add a small L2 penalty. This both stabilizes the optimization, since the loss becomes strictly convex with a unique, well-conditioned minimum, and is the correct fix if the divergence stems from near-separable data (see point 7).
6. Numerical stability of the loss computation itself: naive implementations of the sigmoid and log-loss overflow for large-magnitude inputs. Computing $\sigma(x)=1/(1+e^{-x})$ directly overflows $e^{-x}$ for very negative x, and computing $\log \sigma(x)$ directly underflows to $\log(0) = -\infty$ once $\sigma(x)$ rounds to exactly 0. The standard fix uses the numerically stable log-sum-exp form,

$\log \sigma(x) = -\log(1+e^{-x}) = x - \log(1+e^{x})$

choosing whichever side avoids computing exp of a large positive number. This numerically stable form is already implemented internally by production-grade solvers (liblinear, a solver specialized for linear classifiers; lbfgs, the same curvature-aware method mentioned above; and sag, a stochastic variant that averages gradients over past steps to converge faster on large datasets, all available in scikit-learn), so seeing raw overflow usually means a custom, from-scratch gradient-descent loop rather than a mature library solver.
7. Near-perfect separation: if the classes are, or nearly are, perfectly linearly separable, the unregularized maximum-likelihood estimate doesn't exist, the optimizer keeps pushing coefficients toward infinity to make predicted probabilities approach exactly 0 or 1, which looks exactly like non-convergence. Regularization (point 5) is the standard fix, it caps how far the coefficients can grow.

Worked example

Why naive sigmoid computation overflows, concretely: computing $e^x$ directly in float64 overflows once x exceeds roughly 709.78, since float64's max representable value is about $1.8\times10^{308}$ and $e^{710}$ already exceeds it. A raw logit around -1000 for one example, entirely possible mid-training if the learning rate is too high and coefficients are blowing up, makes $e^{-x}=e^{1000}$ overflow to infinity, and $1/(1+\infty)$ correctly evaluates to 0 numerically. But the log-loss for a true label of 1 on that example then computes $\log(0)$, which is $-\infty$, and a single $-\infty$ loss value poisons the batch-averaged loss and every downstream gradient. This is a self-reinforcing spiral: unstable coefficients produce extreme logits, extreme logits break the naive loss computation, and the broken (infinite or NaN) loss produces a broken gradient that further destabilizes the coefficients, which is why divergence often looks sudden even though the scaling or learning-rate root cause was present from the first few steps.

Trade-offs & pitfalls

Don't jump straight to trying a different optimizer as step one, that treats a data or scaling bug as an optimization problem and can waste significant tuning time; the checklist order above (data, scaling, conditioning, optimizer, regularization, numerical form) is deliberately cheapest-and-most-likely-first. Gradient clipping treats the symptom, exploding gradient magnitude, without fixing the cause, usually scaling or an unstable loss implementation, it's fine as a safety net, not a substitute for the earlier checks. Switching to a mature library solver (liblinear, lbfgs, sag) as a sanity baseline is a legitimate diagnostic step, if it converges cleanly and a custom implementation doesn't, the bug is almost certainly in the implementation, not in the data or the fundamental problem difficulty.

Ways to split the work

• Data parallelism. Each GPU holds a full copy of the model and processes different batches. It is simplest, but the model must fit on one GPU.
• Tensor parallelism. Each layer is split across GPUs. This helps when the layers themselves are too large, but it adds communication every layer.
• Pipeline parallelism. Different layers live on different GPUs. This reduces memory pressure, but can leave devices idle if the pipeline is not balanced.
• Sharded optimizers or fully sharded data parallelism. These split parameters, gradients, and optimizer state to reduce memory use while keeping the training code closer to data parallelism.

How I would choose
If the model is only slightly too big for one GPU, I would prefer sharded data parallelism because it is usually the easiest path. If individual matrix multiplies are the memory or compute problem, tensor parallelism may fit better. If the model is very deep and activations dominate, pipeline or hybrid parallelism can help.

Worked example
For an 8 GPU cluster and a model that almost fits on one device, I would first try sharding plus data parallelism before moving to a more complex hybrid design.

The tradeoff is always simplicity versus communication cost versus memory savings.