Frontend Developer Interview Preparation Guide - Mid Level at Spotify

Brief explanation
Route-based code-splitting defers loading route component code until needed, reducing initial bundle size and improving time-to-interactive. In React you use dynamic import + React.lazy for component splitting and Suspense to show a fallback while the chunk loads.

Example

// lazy route component
const Users = React.lazy(() => import('./Users'));

// usage in router
<Suspense fallback={<Spinner />}>
  <Route path="/users" element={<Users />} />
</Suspense>

Error boundaries
React.lazy throws when loading fails — wrap lazy components in an error boundary to catch and render a recovery UI.

class ErrorBoundary extends React.Component {
  state = { err: null };
  static getDerivedStateFromError(err) { return { err }; }
  render() {
    if (this.state.err) return <RetryUI onRetry={() => this.setState({err:null})} />;
    return this.props.children;
  }
}

Use: <ErrorBoundary><Suspense>…</Suspense></ErrorBoundary>

Preload / prefetch strategies

• import(/* webpackPrefetch: true */ './BigComp') hints browser to fetch during idle time (low priority).
• import(/* webpackPreload: true */ './MainComp') loads with high priority.
• Use <link rel="prefetch"> or rel="preload" for critical chunks or likely next-route assets.
• Programmatic preloading on hover/focus: onMouseEnter={() => import('./Settings')} to improve perceived speed.

SSR pitfalls

• React.lazy + Suspense for code-splitting isn’t SSR-friendly — Suspense for data/hydration differs; can cause mismatches.
• Use SSR-aware libraries (e.g., @loadable/component or react-loadable) which provide server-side chunk extraction and preload support.
• Ensure critical chunks are inlined or preloaded to avoid flash-of-loading and poor SEO.
• Beware chunking too granularly (many small requests) and user bandwidth/HTTP/HTTP2 constraints.

Best practices

• Split by route and by large, rarely used UI.
• Keep chunk sizes reasonable and measure with bundle analyzer.
• Combine ErrorBoundary + Suspense + prefetch for robust UX.

Approach (brief)

Use a discriminated union where one variant requires href and optionally target, and the other requires onClick. Add common props (e.g., children, className, disabled). The union prevents passing both href and onClick.

Types

import React from "react";

type CommonProps = {
  children: React.ReactNode;
  className?: string;
  disabled?: boolean;
  // other shared props...
};

type LinkButtonProps = CommonProps & {
  href: string;            // discriminant: presence of href => link variant
  target?: "_self" | "_blank";
  onClick?: never;         // forbid onClick when href is present
};

type ActionButtonProps = CommonProps & {
  onClick: (e: React.MouseEvent<HTMLButtonElement>) => void;
  href?: never;            // forbid href when onClick is present
  type?: "button" | "submit" | "reset";
};

export type ButtonProps = LinkButtonProps | ActionButtonProps;

Component

export function Button(props: ButtonProps) {
  if ("href" in props) {
    const { href, target, children, className, disabled } = props;
    return (
      <a href={disabled ? undefined : href} target={target} className={className} aria-disabled={disabled}>
        {children}
      </a>
    );
  } else {
    const { onClick, children, className, disabled, type = "button" } = props;
    return (
      <button onClick={disabled ? undefined : onClick} className={className} disabled={disabled} type={type}>
        {children}
      </button>
    );
  }
}

Usage examples

// Link variant
<Button href="/about" target="_self" className="btn">About</Button>

// Action variant
<Button onClick={() => alert("clicked")} className="btn">Save</Button>

Why this works

• TypeScript enforces mutually exclusive props via never.
• Runtime check ("href" in props) narrows type safely.
• Pattern supports accessibility (aria-disabled) and extensibility.

Direct answer

Keep alignment across time zones with three levers: shrink what actually needs real-time overlap by defaulting to async updates on a fixed template, protect a small deliberately scheduled overlap window for anything that truly needs live discussion, and make handoffs explicit in writing so context transfers cleanly across the boundary instead of depending on someone's memory.

Framework

Reduce dependence on overlap. Default to async status updates on a fixed cadence, and use written decision docs rather than requiring a live meeting for every decision. Most updates don't need a room, only genuinely ambiguous or high-stakes calls do.

Protect a deliberate overlap window. Negotiate a recurring block, even a short one, and rotate who takes the inconvenient time so the burden doesn't always fall on the same region.

Make handoffs explicit. When work crosses a time-zone boundary, produce a short written artifact rather than relying on a quick chat message. This matters most in ops-heavy, always-on contexts.

Worked example

Consider an on-call rotation providing 24/7 production coverage across three time zones (for example [Region A], [Region B], and [Region C]), where the two outer regions have little or no live overlap with each other.

• Shadow and overlap periods: the incoming region's on-call shadows the outgoing region's on-call for a short deliberate window at the shift boundary, even 15 to 30 minutes, to ask questions live before the outgoing engineer signs off.
• Written handoff template: a standard document filled at every handoff covering open incidents, any systems in a degraded state, changes deployed in the last shift, and explicit 'known risk' or 'do not touch' notes.
• Escalation expectations: a written policy defining what counts as page-worthy versus a handoff note, who the secondary on-call is in each region, and how long the incoming engineer has to acknowledge before it auto-escalates.
  Result: even with zero live overlap between two of the three regions, the written handoff plus the short shadow window from the middle region means each incoming on-call starts already briefed, instead of reconstructing state from raw logs.
  For non-ops roles the same mechanism applies with a different artifact, for example a design or product handoff might be a written decision log plus a recorded walkthrough rather than an incident handoff, but the principle (explicit written handoff over a live conversation) is the same.

Trade-offs and pitfalls

• Repeatedly scheduling occasional syncs at painful hours burns out whichever time zone draws the short straw. Rotate it deliberately.
• Async-only breaks down for genuinely ambiguous or high-stakes decisions. Some live channel for true emergencies still has to exist.
• A handoff template that's too heavy gets skipped under time pressure. Keep it short enough to fill in within a few minutes.
• Assuming a chat message counts as a handoff is the actual failure mode this whole approach is designed to prevent. The structured artifact is the point, not the tool it's written in.

Semantic elements (header, main, nav, article, section) communicate structure to browsers, assistive tech, and search engines—improving accessibility and SEO. They enable screen readers to provide landmarks and let crawlers infer content importance. Consequence 1: Using generic <div>s removes landmark semantics so keyboard/screen-reader users can’t quickly navigate regions, harming a11y. Consequence 2: Overusing divs can dilute semantic signals for search engines, reducing chance of rich snippets or correct indexing. Use semantics to improve discoverability and inclusive navigation.

Direct answer

Triage by urgency and impact first, protect your own deliverables with an explicit, communicated time-box, and convert repeat-pattern questions into reusable artifacts so future requests don't all cost you 1:1 time. Prioritization alone doesn't scale past a certain number of mentees; reusable resources are what let personalized-feeling mentoring keep up as the queue grows.

Triage and scaling approach

Triage each request on three axes. Is it blocking (them or someone downstream) versus a growth request with slack. How long would it actually take to unblock: a quick answer versus a real session. Is this a shape of question you've answered before, which is a signal to build something reusable rather than repeat yourself.

Route, don't just prioritize. Not everything needs to be you specifically. A growth-oriented question might be better answered by a peer with more direct expertise, freeing your time for things only you can unblock.

Time-box and communicate the SLA out loud. "I can give you twenty minutes now on the blocking piece; let's put the design question on tomorrow's slot" sets expectations honestly instead of leaving people guessing whether they've been deprioritized.

Build reusable async artifacts for repeat patterns. When you notice you've answered a variant of the same question more than once, that's the signal to invest in a recorded walkthrough, a short playbook, or an FAQ instead of repeating the synchronous session a third and fourth time. This is a genuinely different lever from prioritization: it lets you scale personalized-feeling help without your 1:1 time growing linearly with the number of people asking.

Maintain the artifacts deliberately. A playbook or recording that goes stale is worse than not having one, because people trust it and get misled. Whoever owns it, you or a rotating owner, needs a cadence to revisit and refresh it, not a one-time write-and-forget.

Worked example

You're juggling your own deliverable alongside three mentees asking for time at once: one is genuinely blocked, one has a growth-oriented design question with no real time pressure, and one is asking a version of a question you've now answered several times before. You give the blocked person a focused twenty minutes to unblock them. You schedule the design question for a defined slot the next day rather than squeezing it in now. And instead of walking the third person through it live again, you point them to an existing recorded walkthrough, or if one doesn't exist yet, you record a short one this time specifically because you can already tell it'll come up again.

Trade-offs and pitfalls

Treating every request as equally urgent burns you out and, worse, under-serves the person with the actually urgent need, because everyone gets a diluted amount of attention instead of the right amount going to the right place.

Over-investing in artifacts nobody maintains creates a different failure: a stale playbook actively misleads people and erodes trust faster than simply not having documentation and telling people to ask.

Prioritizing strictly by who's loudest or most urgent can systematically starve quieter mentees who don't escalate assertively. It's worth periodically checking who you haven't heard from, not just responding to who's asking.

If you find yourself using "I'll make you a doc" as a polite way to avoid ever giving someone real synchronous time, that's usually a sign the mentee queue has outgrown what one person can reasonably carry, and it's a resourcing conversation to raise with your own manager, not something to keep absorbing indefinitely.

Direct answer
Write a short summary right after the meeting that states the decision made, names an owner and deadline for each follow-up, and flags anything still unresolved, so nobody has to reconstruct what happened from memory a week later.

Structured elaboration

1. State the decision first, in one sentence, even if it feels obvious right after the meeting; it stops being obvious within a day or two, especially for people who weren't in the room.
2. List action items with an owner and a deadline each, not a bare to-do list; "someone should look into X" is not actionable, "Priya will check the vendor SLA by Thursday" is.
3. Name what's still open, explicitly, rather than letting it quietly drop; a one-line "not yet decided: whether we notify customers proactively" prevents someone assuming it was implicitly settled.
4. Send it promptly, ideally within the hour, while the details are fresh and before people have moved on to something else and stopped tracking it mentally.
5. Keep it short. Three to six sentences is usually enough; a summary that's as long as a transcript won't get read.

Worked example
"Decision: we're moving the schema migration to next Tuesday's low-traffic window instead of doing it live this week. Action items: Priya to update the migration runbook by Monday EOD; Sam to notify the on-call rotation of the new window by Friday. Open question: whether we need a customer-facing heads-up, still deciding, will confirm by Wednesday."

Three sentences, one decision, two owned action items with deadlines, and one explicitly flagged open item.

Trade-offs and pitfalls

• The most common failure is writing a summary that lists what was discussed instead of what was decided; a meeting can generate a page of discussion and one real decision, and the summary should reflect that ratio.
• An action item without a named owner tends to silently not get done; if you can't name an owner in the summary, that's a sign the meeting didn't actually resolve who's responsible.
• Sending it too late (days later) defeats the purpose; by then people have already formed their own, sometimes conflicting, memory of what was agreed.

Why this can leak

• The arrow callback closes over el, keeping a JS reference to the DOM node.
• If that handler remains registered (or other JS roots reference el), the removed element becomes a “detached DOM tree” still reachable from JS and not GC'd.
• Some engines/browsers historically had additional roots (timers, DOM->JS cycles) which make this more likely.

How to detect in DevTools

• Open Chrome DevTools → Memory.
• Take a Heap snapshot before creating widget, then after creating & removing it.
• Compare snapshots: search for “Detached DOM tree” or instances of HTMLDivElement still retained.
• Use “Allocation instrumentation on timeline” while creating/removing to see retained objects.
• In Elements panel, right-click node → “Break on” to inspect removals; in Event Listeners pane inspect attached listeners.

Fixes (practical, role-appropriate)

1. Remove listener before removing element:

function createWidget(container) {
  const el = document.createElement('div');
  el.className = 'widget';
  const handler = () => console.log(el.textContent);
  el.addEventListener('click', handler);
  container.appendChild(el);
  // later:
  // el.removeEventListener('click', handler);
  // el.remove();
}

2. Avoid closing over el — use event.currentTarget (no external reference retained):

el.addEventListener('click', function (e) {
  console.log(e.currentTarget.textContent);
});

3. Use event delegation (no per-element listeners):

container.addEventListener('click', (e) => {
  const w = e.target.closest('.widget');
  if (w) console.log(w.textContent);
});

4. Explicitly null references if stored globally:

• someRefToEl = null.

5. For complex caches, consider WeakMap/WeakRef to avoid strong roots.

Choose the simplest: prefer event.currentTarget or delegation in UI code, and always remove listeners if you create named handlers you later discard. Detect with heap snapshots and validate fixes by verifying the node no longer appears as retained.

Direct answer

I'd structure the three months as a small number of month-scale milestones, each with concrete evidence I'm actually on track, and I'd bias the early weeks toward habits, how I verify information, who actually knows what, how work really gets reviewed, over a rigid task list, since those habits compound and a task list rarely survives contact with how things actually work.

Structured elaboration

• Month one is about orientation habits, not output. I focus on the meta-skills that determine how fast the whole ramp goes: how to verify what I'm told here, who actually has the answers versus who's just available, and how work really gets reviewed and shipped. I also pick one small but real piece of work, not a throwaway exercise, small enough to be safe but real enough to teach me the actual constraints, and finish it.
• Month two expands scope with less hand-holding, and I deliberately pick a task that stretches a specific gap month one exposed, rather than repeating something month one already proved I could do.
• Month three takes something closer to end-to-end with minimal supervision, and functions as the real check on whether the earlier ramp actually took, not just whether I felt more comfortable.
• Track progress against visible evidence each month, not a feeling. A shipped piece of real work, a question I can now answer without help, a review I no longer need: these are checkable in a way "I feel more settled" isn't.
• Keep running notes on what I'm learning as I go, mainly for myself: writing it down forces me to notice what I actually understand versus what I only think I understand, and it happens to save me from re-deriving the same answer a second time later.
• Hold the longer arc in view. The point of a genuinely good first-ninety-days plan isn't just fitting into the new team, it's building toward what I'll be trusted with next, so I pick milestones that show growth, not just that I've reached the floor of the new role.

Worked example

Moving from a general security role into an application-security specialty I hadn't worked in directly before, I spent the first two weeks less on formal training material and more on habits: sitting in on a few real code reviews to see how security issues actually got raised and resolved here, and figuring out which two colleagues actually knew the history behind our trickiest existing systems. My first real piece of work was reviewing one moderate-risk change end to end, small enough that a mistake was recoverable, but real enough to teach me the team's actual review norms rather than the documented ones. By month two, I took on a task that specifically stretched a gap month one had exposed: I hadn't yet had to reason about a vulnerability class that came up more often here than in my old role, so I deliberately picked a task involving that. By month three, I led a review independently that would have needed a second pair of eyes back in month one, and used that as the actual evidence the ramp had worked, not just a feeling of familiarity. I kept a short running document of what I was learning throughout, which turned out useful a few months later when a similar issue came up and I could look back at my own notes instead of re-figuring it out from scratch.

Trade-offs and pitfalls

A plan that's all reading and passive orientation with no real work in the loop tends to feel productive without actually testing anything. The opposite mistake, front-loading too much scope before the meta-skills like who to ask and how review works are in place, tends to produce avoidable mistakes early that damage trust. And judging yourself only by how comfortable you feel, rather than by concrete evidence like a piece of finished work or a question you can now answer alone, is an easy way to think you're on track when you're not.

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

First precompute, for every substring s[i..j], whether it is a palindrome, by dynamic programming over increasing substring length (a substring is a palindrome if its two endpoints match and the substring strictly inside it is also a palindrome). Then run a second dynamic-programming pass where cut[i] is the minimum number of cuts needed to partition the prefix s[0..i] into palindromic pieces, trying every valid palindrome ending exactly at i as the final piece.

Structured elaboration

Step 1: the palindrome table

def build_palindrome_table(s):
    n = len(s)
    is_pal = [[False] * n for _ in range(n)]
    for i in range(n):
        is_pal[i][i] = True
    for length in range(2, n + 1):
        for i in range(0, n - length + 1):
            j = i + length - 1
            if s[i] == s[j]:
                is_pal[i][j] = (length == 2) or is_pal[i + 1][j - 1]
    return is_pal

Filling by increasing length guarantees that whenever is_pal[i + 1][j - 1] is read, it was already computed on an earlier iteration (a shorter substring), which is exactly why this fill order is required rather than incidental.

Step 2: minimum cuts

def min_cut(s):
    n = len(s)
    if n <= 1:
        return 0
    is_pal = build_palindrome_table(s)
    cut = [0] * n
    for i in range(n):
        if is_pal[0][i]:
            cut[i] = 0
            continue
        best = i
        for j in range(1, i + 1):
            if is_pal[j][i]:
                best = min(best, cut[j - 1] + 1)
        cut[i] = best
    return cut[n - 1]

Total cost: O(n^2) time (the palindrome table fill and the cut computation are each bounded by the number of (i, j) pairs), O(n^2) space for the table plus O(n) for the cut array, matching what the question asks for.

Optimizations to reduce constant factors AND memory footprint (both parts of the question's explicit ask)

• Constant factor: pack each row of the boolean palindrome table into a single machine integer used as a bitset, one bit per column, instead of a Python list of booleans. Membership becomes a bit shift and mask instead of a list index and a full Python object lookup, and the table's memory footprint drops substantially since a machine integer packs many booleans per word, with identical asymptotic behavior:

def min_cut_bitset(s):
    """Same DP as min_cut, but each row of the palindrome table is packed
    into a single Python int bitset (bit j of rows[i] set iff s[i..j] is a
    palindrome) instead of a list of booleans."""
    n = len(s)
    if n <= 1:
        return 0
    rows = [1 << i for i in range(n)]
    for length in range(2, n + 1):
        for i in range(0, n - length + 1):
            j = i + length - 1
            if s[i] == s[j] and (length == 2 or (rows[i + 1] >> (j - 1)) & 1):
                rows[i] |= (1 << j)
    cut = [0] * n
    for i in range(n):
        if (rows[0] >> i) & 1:
            cut[i] = 0
            continue
        best = i
        for j in range(1, i + 1):
            if (rows[j] >> i) & 1:
                best = min(best, cut[j - 1] + 1)
        cut[i] = best
    return cut[n - 1]

I cross-checked this bitset-packed version against the plain version above; both are exercised together in the worked example below.

• Memory footprint: the cut array itself already only needs O(n) space, one integer per prefix length; the O(n^2) memory lives entirely in the palindrome table. If memory, not time, is the binding constraint, one option is to recompute "is s[j..i] a palindrome" on demand via a direct two-pointer character comparison instead of storing the full table, trading a higher constant-factor time cost (each on-demand check costs up to O(n) rather than O(1) table lookup) for O(1) extra space beyond the output. This is a genuine time-for-space trade, not a free win, and is only worthwhile once the O(n^2) table itself is the actual bottleneck resource for the input sizes involved.

Worked example

Executed with python3 s79.py (defining both min_cut and min_cut_bitset above), the plain and bitset-packed versions run on five pinned strings and cross-checked:

min_cut('aab'                 ) = 1   bitset_packed=1   agree=True
min_cut('a'                   ) = 0   bitset_packed=0   agree=True
min_cut('ab'                  ) = 1   bitset_packed=1   agree=True
min_cut('racecarxyzracecar'   ) = 4   bitset_packed=4   agree=True
min_cut('aabbc'               ) = 2   bitset_packed=2   agree=True

'aab' needs exactly 1 cut: split into 'aa' and 'b', both palindromes, using the minimum possible number of cuts (0 cuts would require the whole string to already be a palindrome, which 'aab' is not).

Trade-offs and pitfalls

• The O(n^2) palindrome table is unavoidable in this straightforward DP formulation; genuinely reducing the worst-case time below O(n^2) requires fundamentally different machinery for palindrome detection that belongs to a different topic's territory, not a small tweak to this approach.
• A common bug: filling is_pal[i][j] using is_pal[i + 1][j - 1] before that entry has actually been computed. The length-ordered fill above exists specifically to prevent this; iterating by row or column index instead of substring length silently reads stale (default False) values and produces wrong results for longer palindromes.
• Off-by-one in the cut recurrence: forgetting the base case where s[0..i] is itself a palindrome (0 cuts needed) is an easy miss, distinct from the general "minimize over every valid split point j" loop, and produces an answer that is too high by exactly one in cases where the whole prefix needs no cut at all.