Full-Stack Developer (Entry Level) Interview Preparation Guide for Lyft

Direct answer

Sort the three-valued array in one pass with three pointers, low, mid, high, that carve it into a growing "already-placed-0s" region, a "confirmed-1s" region, and a "not-yet-placed-2s" region, swapping at most once per position and using no extra storage (the Dutch National Flag algorithm). The same low/high swap idea generalizes directly to a two-way in-place partition by any predicate, but that direct generalization is not stable: swapping elements out of place can scramble the relative order of items that land in the same output region, so keeping order stable needs an extra step beyond just relabeling the predicate.

Structured elaboration

The three-way invariant

At every point during the scan: everything before low is 0, everything in [low, mid) is 1, everything after high is 2, and mid is the next unclassified element. When nums[mid] == 0, swapping it to low and advancing both pointers is safe because the element that lands at mid from the swap was already known to be 1 (it came from inside [low, mid)). When nums[mid] == 2, swapping it to high and only decrementing high (not advancing mid) is required because the element swapped in from the unexplored tail is unclassified and must still be examined.

Generalizing to an arbitrary predicate, and where stability breaks

Collapsing the three categories to two, "satisfies the predicate" versus "does not", turns this into the standard in-place two-way partition: scan with a single pointer, swap anything satisfying the predicate to the front. This preserves the $O(n)$ time, $O(1)$ space profile, but it is not stable: a swap moves an element across positions that may already hold other same-category elements, and nothing about the swap preserves their relative order. The demonstration below shows two items in the same category (both satisfying the predicate) ending up reordered relative to each other purely because of how the swaps landed, even though the partition itself (which items are in which category) is correct.

To keep relative order stable while partitioning in place, the pointer-swap approach is not enough on its own. Two honest options:

• Trade space for stability (simple): scan once, appending predicate-true and predicate-false items to two separate output lists in encounter order, then concatenate. This is $O(n)$ time and stable by construction, at the cost of $O(n)$ auxiliary space, no longer in-place.
• Keep $O(1)$ space, pay in time (advanced): a genuinely in-place and stable partition is possible using a recursive divide-and-rotate scheme, partition each half of the array independently, then merge the two halves' boundary regions by rotating the "false" suffix of the left half past the "true" prefix of the right half. This is the same technique behind library-grade in-place stable partitions (for example, C++'s std::stable_partition is specified to do at most $O(n \log n)$ swaps in the general case, or a single linear pass if it is allowed to allocate a temporary buffer). It is a materially different algorithm from the plain DNF swap, not just the same three-pointer idea relabeled.

Worked example

Approach

First, the DNF sort itself:

def dutch_national_flag(nums):
    low, mid, high = 0, 0, len(nums) - 1
    while mid <= high:
        if nums[mid] == 0:
            nums[low], nums[mid] = nums[mid], nums[low]
            low += 1
            mid += 1
        elif nums[mid] == 1:
            mid += 1
        else:  # nums[mid] == 2
            nums[mid], nums[high] = nums[high], nums[mid]
            high -= 1
    return nums

print(dutch_national_flag([2, 0, 2, 1, 1, 0]))

This prints [0, 0, 1, 1, 2, 2].

Second, the two-way generalization by predicate, showing the instability directly on tagged items so reordering is visible:

def unstable_partition(items, pred):
    lo = 0
    for i in range(len(items)):
        if pred(items[i]):
            items[lo], items[i] = items[i], items[lo]
            lo += 1
    return items

labeled = [('a', 1), ('b', 0), ('c', 1), ('d', 0), ('e', 1)]
print(unstable_partition(labeled[:], lambda t: t[1] == 1))

def stable_partition(items, pred):
    true_bucket = [x for x in items if pred(x)]
    false_bucket = [x for x in items if not pred(x)]
    return true_bucket + false_bucket

print(stable_partition(labeled[:], lambda t: t[1] == 1))

This prints:

[('a', 1), ('c', 1), ('e', 1), ('d', 0), ('b', 0)]
[('a', 1), ('c', 1), ('e', 1), ('b', 0), ('d', 0)]

The swap-based version reorders 'b' and 'd' relative to each other (both are category-0, and 'd' ends up before 'b', the reverse of their original order), while the extra-buffer version preserves 'b' before 'd' exactly as encountered.

Key points

• The DNF three-pointer scan and the two-way predicate partition are the same swap mechanism; only the number of categories changes.
• Correctness of which bucket each item lands in is unaffected by the instability; only the order within a bucket is at risk.
• Stability and true in-place ($O(1)$ space) are in tension for this problem: you can have both only by accepting $O(n \log n)$ time via the rotation-based approach, or you can have $O(n)$ time by giving up in-place-ness.

Complexity

DNF: time $O(n)$ (single pass, mid never revisits a position), space $O(1)$.
Unstable two-way partition: time $O(n)$, space $O(1)$.
Stable partition via extra buffer: time $O(n)$, space $O(n)$.

Edge cases

• Empty array, single element, or an already-sorted array: the DNF loop terminates immediately or after trivial no-op passes.
• All elements identical (all 1s, for instance): low never advances, mid sweeps straight to high with no swaps.
• A predicate that is trivially true or false for every element: the two-way partition degenerates to a no-op copy.

Trade-offs & pitfalls

The most common mistake when moving from three-way DNF to a two-way predicate partition is assuming the result is automatically stable "because it's the same kind of algorithm." It is not, and that distinction matters directly whenever a partition needs to preserve, for example, insertion order or timestamp order within each output group (a very common real requirement, such as partitioning a task queue into "ready" versus "blocked" while keeping each group's original ordering). Reaching for the swap-based version there without checking the stability requirement is a silent correctness bug, not just a style choice. When stability genuinely is not required, the swap-based version remains the better default: no allocation, single pass, and it generalizes cleanly to $k$-way partitioning by widening from two pointers to $k-1$ boundary pointers.

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

Structured elaboration
Proposed criteria, with the reasoning for each:

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

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

Trade-offs and pitfalls

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

Brief answer / recommendation
For a 6‑engineer team building a form‑heavy SPA I recommend using a small external state library (Zustand) for global UI state and per‑form local state (React state or form libs like React Hook Form) for form fields. This balances ergonomics, performance, bundle size, and maintainability.

Developer ergonomics

• React Context: simple API, no extra dependency; OK for small, infrequent global values.
• Redux: explicit patterns, great devtools, more boilerplate and cognitive load.
• Zustand: minimal API, predictable selectors, easy async support — low friction for a small team.

Performance (re-renders)

• Context: updates re-render all consuming descendants unless you split contexts or memoize heavily — can be costly in form-heavy UIs.
• Redux/Zustand: selector-based subscriptions avoid broad re-renders; Zustand excels with granular subscriptions and tiny overhead.

Bundle size

• Context: zero extra bytes.
• Redux + toolkit + middleware/devtools: noticeably larger.
• Zustand: very small footprint, good middle ground.

Long-term maintainability

• Context scales poorly if used as ad‑hoc global store; code becomes entangled.
• Redux offers structure and predictability for very large apps, but adds ceremony.
• Zustand gives low boilerplate and clear boundaries; pairs well with component-local form state and form libraries.

Concrete pattern for team

• Use React Hook Form for per‑form inputs (local, performant).
• Use Zustand for app/global UI state (modals, toasts, auth).
• Reserve Context for theme/locale or narrow concerns.

This approach minimizes re-renders, keeps bundle size small, and gives the team an easy‑to‑learn, maintainable pattern.

Direct answer

OAuth 2.0 is an authorization framework: it lets a user grant a third-party application scoped access to an API or resource without handing over a password. On its own it has no standard concept of "who logged in," only "what access was granted." OpenID Connect (OIDC) is a thin identity layer built on top of OAuth 2.0 that adds a standardized token proving who authenticated, not just what the app can now touch. SAML (Security Assertion Markup Language) is an older, XML-based protocol built specifically for browser-based single sign-on (SSO), most often used to federate identity into enterprise web applications. All three answer "who is this, and can we trust that claim across a network boundary," but they target different client types and eras of the web.

Structured elaboration

Criteria for choosing between them:

• Building a login experience for a modern web or mobile app that also needs to call an API on the user's behalf: use OIDC. It sits on top of OAuth 2.0, so you get delegated authorization and a verified identity from the same flow.
• Only need delegated API access, with no identity concept for the calling app itself (a backend job reading a user's calendar): plain OAuth 2.0 is sufficient and simpler.
• Integrating with an enterprise's existing identity provider, and that provider or the target application only speaks SAML: you use SAML even though it is heavier to implement than a JWT-based approach, because the counterpart has no OIDC endpoint to talk to.
• Mobile deployment pushes the decision toward OIDC: SAML's browser-redirect-and-XML-post pattern is awkward inside a native app, while OIDC's authorization code flow was purpose-built for exactly that client type.
• Enterprise SSO deployment sometimes forces SAML regardless of preference: large enterprise buyers frequently standardize on a SAML identity provider for audit and compliance reasons, and the vendor's application may expose only a SAML integration point.

Worked example

Trace "Log in with Google," which demonstrates both the OAuth delegation layer and the OIDC identity layer built on top of it:

1. The user clicks "Log in with Google"; the app redirects to Google's authorization endpoint requesting scope=openid email profile.
2. Google authenticates the user through its own login screen and the user consents to the requested scopes.
3. Google redirects back to the app with a short-lived authorization code.
4. The app exchanges that code at Google's token endpoint for an ID token (the OIDC-specific artifact, a JWT) and an access token (the underlying OAuth artifact).
5. The app validates the ID token's signature and claims (iss equals Google's issuer, aud equals the app's own client id, exp has not passed) to learn who logged in, from the sub and email claims.
6. If the app also wants to read the user's Google Calendar, it uses the separate access token for that call. That is the original OAuth layer doing its job, distinct from step 5.

This split is exactly why using bare OAuth to implement login was a historical mistake, before OIDC existed: an access token alone does not certify identity (it authorizes calls to a specific API, and it isn't required to be a verifiable, self-contained token at all), so an app inspecting only an access token to decide "who is logged in" could be fooled by a token that was legitimately issued, just for a different purpose or audience. OIDC's ID token exists specifically to close that gap.

Trade-offs and pitfalls

• SAML assertions are XML-based and require careful canonicalization and signature validation. Implementing that by hand is a well-known source of signature-wrapping vulnerabilities; always use a maintained library rather than parsing and verifying the XML yourself.
• Treating an OAuth access token as proof of identity, instead of using OIDC's ID token, is the single most common protocol-selection mistake in this space; it works in testing and fails once a token issued for a different audience gets presented to the wrong service.
• Bridging protocols (a SAML-only enterprise identity provider fronting an OIDC-only application, or the reverse) is a common real integration need, but it adds an extra hop and an extra trust boundary; treat that bridge as its own design problem rather than assuming one protocol trivially substitutes for the other.

Situation & goal
We repeatedly see production bugs from incorrect async patterns (missing awaits, unhandled promise rejections, race conditions). My goal: a learning-centered program to eliminate recurrence within three sprints while upskilling the team.

Training topics (1 sprint kickoff + ongoing)

• JS/TS async fundamentals: Promises, async/await, error propagation
• Concurrency patterns: debouncing, throttling, cancellation (AbortController), locking for shared resources
• Backend async: connection pooling, transaction ordering, idempotency
• Testing async code: unit mocks, integration, end-to-end async flows

Pairing rotations

• Two-week rotation: pair a senior + mid/junior on async-heavy modules each sprint
• Weekly “async clinic” 1-hour session where pairs bring a problematic PR or production issue and walk through fixes

Coding standards & lint rules

• ESLint rules: no-floating-promises, promise/always-return, consistent-async (or TypeScript’s strictNullChecks + noImplicitAny)
• Add code-review checklist entries: confirm awaited calls, error handling, cancellation where needed

Automated checks & tests

• CI lint step enforcing rules
• Unit tests for async flows (Jest with fake timers/promises)
• Integration tests simulating concurrent requests (supertest / Playwright)
• Contract tests for API ordering/idempotency
• Add CI job to run concurrency stress tests on critical endpoints nightly

Measurement over next 3 sprints
Baseline: count async-related production incidents in last 3 sprints (e.g., 5). Track weekly:

• Number of async-related production bugs (target: reduce by 60–80% by sprint 3)
• Mean time to detect & fix async bugs (target: 50% faster)
• % PRs failing async lint rules pre-merge (target: 0%)
• Coverage of async-critical paths by automated tests (target: +30%)
  Review metrics at sprint demos and adjust training/pairing if goals aren’t met.

This combines hands-on learning, enforced standards, and measurable automated safety nets to reduce recurrence while building team capability.

Direct answer. The body below follows RFC 7807's shape (type/title/status/detail/instance) and adds two fields the standard leaves out but any real API needs: a stable machine-readable code and a correlation id.

{
  "type": "https://api.example.com/errors/validation-failed",
  "title": "Request validation failed",
  "status": 400,
  "detail": "The 'quantity' field must be greater than 0, and 'email' is not a valid email address.",
  "instance": "/orders",
  "error_code": "ORDER_VALIDATION_FAILED",
  "correlation_id": "req_8f2a1c9d",
  "remediation": "Fix the fields listed in 'detail' and resubmit the request."
}

What each field is for.

• type: a stable URI identifying this PROBLEM TYPE (not this occurrence); resolving it (or just reading it, most implementations do not require it to be a live, dereferenceable page) tells a developer or a client library "this is the kind of error where request validation failed," reusable across every endpoint that can fail this way.
• title: a short, generic summary of that problem type, identical every time this specific type occurs; changes to wording here are a documentation update, not a per-request detail.
• status: 400, repeated in the body because some client code and logging pipelines only see the JSON body, not the HTTP status line, especially once a response has passed through a proxy that logs bodies but not headers.
• detail: THIS occurrence's specifics, which fields failed and why; this is what actually varies request to request, unlike title.
• instance: the specific resource path this occurrence happened against, useful when the same problem type can occur on multiple endpoints and you want to know exactly which call triggered it.
• error_code: the machine-readable string a client's error-handling code should actually branch on (if error_code == "ORDER_VALIDATION_FAILED"), since type/title are meant to be more human-facing and are not guaranteed to be a tight enum a client can safely switch over.
• correlation_id: lets support or the client hand this exact value back to you, and you look up the full server-side log entry for the request instantly, instead of searching by approximate timestamp.

Trade-offs and pitfalls. Putting per-request specifics (like the exact invalid value a user typed) into title instead of detail breaks the standard's own intended use of title as a stable, cacheable label for the error TYPE, and makes it useless for grouping or aggregating errors by type later.

Trade-offs:

• Performance: webfonts add bytes and can cause FOIT/ FOUT; slow networks amplify delay.
• UX: invisible or sudden font swaps harm readability and layout.
• Licensing: fonts may have restrictive EULAs, require proper hosting or subsetting.
  Mitigations:
• Subset fonts to needed glyphs and weights; deliver WOFF2 and use variable fonts where appropriate.
• Loading strategy: preload critical fonts, use font-display: swap or optional depending on importance; consider FOIT for hero text only.
• Metric matching: choose system fallback with similar metrics and use CSS adjustments (font-size-adjust, letter-spacing) to reduce layout shift.
• Caching & CDN: host fonts on CDN with long TTL and proper CORS headers.
• Accessibility: test reading flow; support prefers-reduced-motion and system fonts when necessary.
  Trade-off rationale: balance brand fidelity with performance by prioritizing only critical brand glyphs/weights and graceful fallbacks.

Quick answer

Frame a lateral move as a deliberate capability-gap fill: name the specific gap your prior role couldn't close, what you actually did in the new function, and what you gained that you couldn't have gotten by staying put, then connect it forward to the role you're interviewing for now.

How to build it

The gap-fill frame

A lateral move reads as strategic, not restless, when you can name the specific thing you couldn't learn where you were. "I wanted to broaden my experience" alone is weak; "I could plan well but had never owned the operational side that plans depend on" is a real gap.

What to cover in the action beat

Treat the lateral role like any other STAR story (Situation, Task, Action, Result): name concrete responsibilities that were genuinely new to you, not just a change of title. If the day-to-day work barely changed, the lateral move doesn't prove much; the interesting material is the part that was unfamiliar.

Connecting it forward

End by tying the gained capability to the role in front of you. The lateral move should read as the reason you're now more ready for this role, not as a detour you're explaining away.

Worked example

Skeleton: "I was in [prior function] and moved laterally into [adjacent function] for [a period] because I could [do task A] but had never had to [do task B], and I wanted to own both ends of the problem. In the new role I was responsible for [one or two concrete new responsibilities], which meant learning [a specific skill or process] from the ground up, including a stretch where I had to [a concrete example, e.g. fix a recurring handoff error between two teams by rebuilding the process both sides used]. What I gained was [a specific capability] I couldn't have picked up by staying in my original function, and it's a big part of why I can now [connect to the target role]."

Filled illustration: "I was in a planning-focused role and moved laterally into an operations role for about a year, because I could design a plan but had never had to run one day to day, and I wanted to own both ends of the problem. In the new role I was responsible for coordinating the daily handoffs between two teams, which meant learning the operational scheduling process from the ground up, including a stretch where I had to fix a recurring handoff error between the two teams by rebuilding the process both sides used. What I gained was a real feel for where a plan actually breaks down in practice, not just on paper, and it's a big part of why I can now spot operational risk earlier when I'm the one doing the planning."

Trade-offs and pitfalls

The most common weakness is describing the lateral move as a title change with no real new responsibility, which makes it sound like a resume line rather than a growth story. A second is failing to name the gap that motivated the move in the first place, leaving the interviewer to wonder whether it was really a choice or just what was available. Skipping the forward connection turns a genuinely interesting story into a closed loop that doesn't help the interviewer see why it matters for this role.

A TIMESTAMP column includes a time-of-day component, so a date-only BETWEEN upper bound like '2024-03-31' is treated as midnight at the start of that day, silently excluding every row later that same day; a half-open range using the next day's start avoids the gap.

Structured elaboration

-- Misses late-March-31 rows
SELECT order_id FROM orders WHERE created_at BETWEEN '2024-03-01' AND '2024-03-31';
-- Correct half-open range
SELECT order_id FROM orders WHERE created_at >= '2024-03-01' AND created_at < '2024-04-01';

BETWEEN '2024-03-01' AND '2024-03-31' is shorthand for >= '2024-03-01' AND <= '2024-03-31', and that upper bound, when compared against a TIMESTAMP, is interpreted as 2024-03-31 00:00:00. Any row timestamped later that same day (say, 2024-03-31 23:00:00) is strictly greater than midnight and gets excluded, even though it clearly belongs in "March 2024" by any reasonable interpretation.

Worked example

Given orders at 2024-03-31 23:00:00 and 2024-03-15 10:00:00: the BETWEEN version returns only the March 15 order, silently dropping the March 31 order entirely. The half-open version (< '2024-04-01') correctly returns both orders.

Trade-offs and pitfalls

The half-open-range fix generalizes to any period boundary (a single day, a month, a quarter, a year): always express the upper bound as "the start of the next period, exclusive" rather than "the last moment of this period, inclusive", since the latter requires knowing the column's precision exactly (is it seconds? milliseconds? does '2024-03-31 23:59:59' actually cover a row at '2024-03-31 23:59:59.500'?) while the former never does. This same half-open form is also what makes the query index-friendly, which the question asks for by name: created_at >= '2024-03-01' AND created_at < '2024-04-01' compares the raw created_at column directly against two literal bounds, exactly the shape a B-tree index (the default index structure in most relational engines, storing column values in sorted order) on created_at can use for a plain range scan. A common alternative fix, wrapping the column instead of the bound, e.g. WHERE DATE(created_at) BETWEEN '2024-03-01' AND '2024-03-31' or CAST(created_at AS DATE) = ..., looks similarly correct but applies a function to every row's created_at value before comparing it, which prevents a plain index on created_at from being used at all, since the engine can no longer look up sorted values directly and instead has to compute the expression for every row. Keeping the column bare on one side of a plain comparison is what index-friendly means in practice.

Direct answer

A React error boundary catches rendering errors thrown by any component in its subtree during render, in lifecycle methods, and in constructors, logs the error with enough context to diagnose it, and shows a fallback UI instead of leaving the user with a blank screen or React's own default error overlay; it does not catch errors in event handlers, asynchronous code, or errors thrown in the boundary component itself.

Structured elaboration

What it catches. Errors thrown during the render phase of any component below the boundary in the tree, including errors in lifecycle methods (componentDidMount, etc.) and in constructors. This is React's mechanism for preventing one broken component from crashing the entire application.

What it does NOT catch, and why that matters. Event handlers (a click handler that throws is a normal JavaScript exception, not a React rendering error, and needs its own try/catch); asynchronous code (a .then() callback or an async function's rejection happens outside React's render cycle entirely); server-side rendering errors; and errors thrown by the error boundary component itself (a boundary cannot catch its own failures, which is why the boundary component should be kept as simple as possible, with minimal logic that could itself throw).

Logging to an error-tracking service. componentDidCatch(error, info) receives both the error object and a componentStack describing which component tree led to the failure; sending both to a service like Sentry, tagged with any available user or session context, turns "a customer reported a blank page" into "we can see exactly which component threw, with what stack, for which user" without waiting for the customer to describe what they were doing.

Retry UI versus surfacing the raw error. A "try again" button that resets the boundary's state and re-attempts rendering the subtree is appropriate when the failure might be transient (a component that failed because of a momentary bad prop from a slow API response); it is misleading for a deterministic bug that will fail identically on every retry, where a generic "something went wrong, we've been notified" message (with no false promise that retrying will help) is more honest to the user, even though it is less satisfying than a button that appears to offer control.

Worked example

class ErrorBoundary extends React.Component {
  constructor(props) { super(props); this.state = { hasError: false }; }
  static getDerivedStateFromError(error) { return { hasError: true }; }
  componentDidCatch(error, info) {
    if (this.props.logger) this.props.logger.logError(error, info.componentStack);
  }
  render() {
    if (this.state.hasError) {
      return <div role="alert">{this.props.fallbackText || 'Something went wrong.'}</div>;
    }
    return this.props.children;
  }
}

Executed (React Testing Library, verified): rendering <ErrorBoundary logger={logger} fallbackText="We hit a snag. Please retry."><Boom /></ErrorBoundary>, where Boom throws during render, confirms screen.getByRole('alert') shows the fallback text and logger.logError was called exactly once with the thrown Error object. A second test confirms that when no child throws, the boundary renders its children normally and logger.logError is never called, so the boundary is confirmed to be transparent in the non-error case, not just functional in the error case.

Trade-offs and pitfalls

A single application-wide error boundary at the root catches everything but takes down the ENTIRE page for a failure in one small, non-critical widget; placing boundaries around individual independent sections (a sidebar widget, a comments section) means one broken component degrades gracefully to just that section showing a fallback, while the rest of the page keeps working, which is almost always the better default for anything with multiple independent sections. The most common mistake is assuming an error boundary catches an async data-fetching failure inside a useEffect: it does not, since that error occurs outside the render phase entirely, and needs its own explicit error state managed by the component, separate from the boundary mechanism.