Staff-Level Frontend Developer Interview Preparation Guide for Spotify

Comparison

Choosing between them

The deciding questions are: does the SERVER need to read this automatically, only cookies do that; does it need to survive the tab closing, localStorage and IndexedDB yes, sessionStorage no; and how much data, a few KB fits anywhere, hundreds of KB to MB pushes you toward IndexedDB. Avoid putting an auth token in localStorage/sessionStorage when possible: an HttpOnly cookie is the only one of the four immune to a JavaScript-based XSS read.

Direct answer

Semantic versioning gives a component library's version number, MAJOR.MINOR.PATCH, a contract meaning: PATCH is a backwards-compatible bug fix, MINOR is a backwards-compatible addition, and MAJOR is a change that can break a consumer. The point is that a consumer can safely auto-update on patches and minors (^1.4.2 in npm terms) without reading a changelog, and knows a major bump means "stop and read before upgrading."

Structured elaboration

What changes at each level

The test for "does this need a major bump" is not "did the code change a lot," it is "does any existing correct usage now behave differently or fail to compile/render." A large refactor that keeps the public API and visuals identical is still a patch.

Communicating each release type

• Changelog: generate it from commit messages using a convention (Conventional Commits: fix:, feat:, feat!: or BREAKING CHANGE: footer) so the bump level and the changelog entry come from the same source of truth instead of being decided twice.
• Release notes for majors: always include a migration guide with before/after code snippets, not just a prose description of what changed.
• Distribution channels: GitHub Releases or an internal package registry page for the human-readable notes, plus an in-repo CHANGELOG.md so it is visible in the diff of any PR that bumps the dependency.

Tooling

• Automated bump and changelog: semantic-release or changesets read Conventional Commits and produce the version bump, changelog, and tag automatically, removing the "did I mean minor or patch" judgment call from a human at release time.
• Breaking-change detection assist: a type-diff check (for example comparing the public .d.ts API surface between versions) catches accidental breaking changes that were not intentionally flagged with feat!:, which is a common source of "silent major" bugs.

Worked example

A library is at 1.4.2. Three independent changes land:

• (a) Patch, 1.4.2 -> 1.4.3: Button's icon-only variant is missing an aria-label, so screen readers announce nothing. The fix adds the label. The prop API, markup structure, and visual layout are unchanged for every existing usage, so this is a bug fix with zero consumer action required.
• (b) Minor, 1.4.3 -> 1.5.0: A new Badge component is added, and Button gains an optional size="xxs" prop that defaults to the previous size when omitted. Every existing usage of Button compiles and renders identically; only code that opts in to the new prop is affected. This is additive, so it is a minor bump, not a patch, because it is new surface area (even though nothing breaks).
• (c) Major, 1.5.0 -> 2.0.0: Button's variant prop is renamed to tone, and the values change from "primary" | "secondary" to "brand" | "neutral". Any component currently written as <Button variant="primary"> now either fails to compile (in TypeScript) or silently renders with no styling (in plain JS, since variant is simply ignored). That is a breaking change to every consumer using the old prop, so it is a major bump regardless of how small the code diff looks.

Trade-offs and pitfalls

• Shipping a behavior change "as a patch" because it feels small is the most common semver violation; if any correctly-written existing usage now behaves differently, it is not a patch, no matter how minor it looks to the author.
• Renaming or removing a prop without a deprecation window forces every consumer to upgrade and migrate simultaneously; a senior answer proposes keeping the old prop working (with a console deprecation warning) for at least one major cycle, or shipping a codemod (an automated script that mechanically rewrites consumer code from the old API shape to the new one, so teams don't hand-edit every call site), rather than a hard cutover.
• Auto-generated changelogs from commit messages are only trustworthy if the team actually follows the commit convention; a mislabeled fix: on a change that is actually breaking produces a version that lies about its own risk, which is worse than a hand-written changelog because consumers trust the automation.
• Treating "internal refactor with no API change" as needing any bump at all is unnecessary churn; reserve version bumps for changes visible to a consumer.

Approach

Trace what actually blocks the page from being usable before picking a side, since page load time is a chain, and lazy-loading (deferring resources until needed) and code-splitting (breaking a large JavaScript bundle into smaller pieces loaded on demand) fix a different part of that chain than API aggregation (combining multiple backend calls into fewer round trips).

Worked estimate (illustrative numbers)

Say a trace shows the page currently loads in 4.5 seconds: about 1.5 seconds comes from a chain of 8 sequential API calls at roughly 180 milliseconds round trip each, about 2 seconds from downloading, parsing, and running a large, unsplit JavaScript bundle, and the remaining second from rendering and images.

Aggregating those 8 calls into 2 combined calls could plausibly cut that 1.5 seconds down to 400 to 500 milliseconds, roughly a 1 second win. Code-splitting the bundle so only what is needed for first paint loads up front could plausibly cut the 2 second JavaScript cost by half or more, roughly another 1 to 1.2 second win. In this profile the two options are close in raw impact, so the tie-breaker becomes speed and risk to build in four weeks. API aggregation usually touches fewer moving parts and can ship incrementally, one endpoint at a time, with fast, measurable wins, while a full code-splitting pass across a codebase, deciding what is route-critical versus deferred, tends to take longer to get right.

What would change the answer

If the trace showed one side clearly dominating, say 3 of the 4.5 seconds coming from the sequential API calls, I would start there since it has the higher ceiling. If most users are on a fast connection but a smaller, high-value segment is on mobile or slow networks where the JavaScript payload dominates their experience, that shifts the priority depending on who "fastest possible" is really meant to serve. And if the backend calls are shared with other teams' services, aggregating them carries wider blast radius and may take longer to get sign-off on than a frontend-only change, which pushes the four-week bet toward frontend first.

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.

Direct answer

Get both teams in the same room with concrete evidence of the overlap, not each team's assumption about who owns what, agree on a single ownership model for the disputed piece, write it down somewhere both teams will actually find later, and set a lightweight recurring check so the boundary does not quietly drift back into ambiguity.

Structured elaboration

Start with evidence, not opinion

Map the actual overlap: which capability, which parts of the system, which decisions each team has been making independently. A short, concrete inventory, such as "both teams modified this component in the last quarter, for these reasons," turns a "whose job is this" argument into a shared problem to solve.

Choose an ownership model, do not just split the difference

Common options: one team owns it fully and the other is a client of it, ownership is split along a clear seam such as by data domain or by interface, or the piece gets consolidated into a single shared service with one clear owner. Whichever you pick, the test is whether a new engineer joining either team could read the agreement and know who to ask.

Write it down where it will be found

A decision made in a meeting and never documented decays within a sprint. Put the ownership boundary in the same place engineers already look, such as a README, a service catalog, or an API contract doc, not a one-off meeting note.

Set a recurring, lightweight check

A short standing sync between the two teams for boundary-crossing changes, or a simple rule that any change to the shared piece pings both teams, is enough to catch drift early without adding heavy process.

Worked example

Two teams both maintain code that retries failed requests to a downstream service, each having added its own retry and backoff logic independently over time. The overlap surfaces when a production incident review shows both teams' logic firing on the same failure and compounding retry pressure on the downstream service.

The teams map the overlap and find one team's logic lives in a shared client library, while the other's is inline in their own service and duplicates the same behavior. They agree the shared library should be the single source of retry logic, with the other team's inline logic removed and replaced by a call to the library. They write this into the library's README as "owned by Team A, changes to retry behavior require a ping in the shared channel," and add a short section to each team's onboarding doc pointing new engineers at the library first. They also add a lightweight rule: any pull request touching retry or backoff logic in either codebase gets a reviewer from the other team tagged automatically.

Trade-offs and pitfalls

Consolidating too aggressively can overstep a team's actual mandate and create a bottleneck if the new sole owner becomes a blocker for changes the other team needs quickly. Splitting too finely, dividing by an overly granular seam, creates new edge cases at the new boundary instead of removing them.

The common failure mode is not picking the wrong model, it is skipping the documentation and recurring-check steps because the meeting felt like it resolved things. Verbal agreements between the two people in the room do not survive a reorg or a new hire; only a written, discoverable agreement does.

Direct answer

I anchor the estimate on a concrete definition of "productive," specific tasks I could hand off unsupervised, not a vague feeling, then adjust it based on how far this technology is from something I already know, how good the documentation and community support are, and whether someone experienced is reachable to unblock me quickly. I give a range with the assumptions stated, not a single number, and if I miss it I raise that as early as possible rather than at the deadline, since recovery options shrink fast the closer the deadline gets.

Structured elaboration

Building the estimate

• Anchor on what "productive" means as an observable task: can I ship a specific, bounded piece of real work without hand-holding.
• Separate "can do the basics" from "can be trusted unsupervised"; conflating those two milestones is the most common way an estimate turns out too optimistic.
• Factors that move the number: distance from something already known well, quality and completeness of documentation, whether an experienced person is reachable, and how forgiving the task is of a slower, careful pace early on.
• Compress the number deliberately rather than padding it: deliberate practice on the riskiest part first, a short conversation with someone experienced up front, or small scoped exercises before the real task.
• Give a range with the driving assumption named, "two to three weeks, assuming thirty minutes from someone experienced in week one," rather than a false-precision point estimate.

Handling a miss

• Raise it as soon as it is visible, not at the deadline; the moment the estimate looks wrong is the moment there is still time to change plan, get help, or reset expectations.
• Recovery usually means one of: getting more experienced help, narrowing scope to what is actually achievable, or being explicit that the deadline needs to move, decided deliberately rather than by default.
• The lasting change after a miss is usually in the estimating process itself, being honest about a specific factor that was underweighted, not just resolving to try harder.
• If a formal certification path would take longer than the project allows, competence needs to be evidenced some other way, a demonstrated deliverable, a review from someone qualified, rather than treating the certificate as the only proof.

Worked example

A project lead asked how long it would take to get productive in a new automated-testing framework for an upcoming release. I anchored the estimate on a specific task, writing and maintaining a real test suite for one service, unsupervised. Because it was reasonably close to a framework I already knew well, and documentation was strong, I gave a range of one to two weeks, naming the assumption that a colleague already using it could answer occasional questions. Partway through week one, I realized the framework's approach to test fixtures worked differently than expected, in a way that would take longer to work around than planned, and instead of waiting to see if it resolved itself, I flagged it immediately with a revised estimate and two options: extend the timeline by a few days, or narrow the first release's coverage to the highest-risk paths and expand later. The lead chose the narrower scope. Afterward, the concrete change to how I estimate was adding an explicit check in week one for exactly this kind of surprise, a close analog behaving differently than expected, instead of assuming a close analog transfers cleanly.

Trade-offs and pitfalls

• Giving a single confident number instead of a range with stated assumptions makes the estimate look more certain than it is and removes the natural chance to say what would move it.
• Waiting until the deadline to admit a miss removes almost every good recovery option; raising it early keeps scope, help, and timeline all still on the table.
• Padding an estimate broadly, instead of naming the specific factors driving uncertainty, produces a number that is hard to defend or recalibrate later.

Direct answer

Triage fast to find the smallest change that removes the actual user-facing harm, use the shrinking window as a reason to scope down rather than attempt a full root-cause rebuild days before release, and tell stakeholders the real state and the fallback option early rather than quietly hoping the fix lands cleanly.

Structured elaboration

Diagnose fast and scoped: for a performance regression, use a profiler (an in-engine frame-time profiler for a game, or browser devtools for a web frontend) to find the specific function or asset actually causing the slowdown rather than guessing. For a UI deviating from the approved design, do a direct side-by-side comparison against the design file to produce a specific list of deviations rather than a vague sense that "it looks off."

Quick mitigations: for a performance issue, a targeted fix (reducing a specific effect's cost, lazy-loading an asset, capping a repeated computation) beats a broad refactor under this kind of time pressure. For a design deviation, fix whatever is visually significant or brand-critical first, and explicitly defer pixel-level polish that does not affect usability to a fast-follow.

Tools: a profiler to find the real hotspot, a visual diff or side-by-side screenshot comparison against the design spec, and a feature flag or config toggle that can instantly revert the change if the fix itself turns out risky right before release.

Communicate with stakeholders: give them the specific finding, not just "there's an issue," the fix plan, and a fallback (ship with the change flagged off, or revert to the last known-good build) if the fix is not verified in time, so the release date does not depend entirely on one fix landing perfectly.

Worked example

Four days from a mobile game's release, frame-rate profiling shows a specific particle effect added the previous sprint is causing a drop from 60 to 40 frames per second in one busy scene. Day one: profile and confirm it is that one effect, not a broader issue. Day two: reduce the effect's particle count and cap it behind a quality setting rather than removing it entirely, and verify frame rate recovers to around 58 to 60 in the same scene. Day three: regression-test the fix across the other scenes using the same effect. Day four, release day: ship with the capped effect, communicated to the team as a deliberate scope trim rather than a mystery late fix.

Trade-offs and pitfalls

The clearest pitfall is attempting a deep architectural fix for either kind of problem this close to release instead of the smallest safe change available. A second is not telling stakeholders until the last possible moment, which removes their ability to choose a fallback if the fix risks slipping. The same discipline applies to the design-deviation version of this problem: fix what actually matters to users and the brand, and explicitly log, rather than silently drop, the cosmetic deviations for a fast-follow patch instead of trying to close every gap before the date.

Grooming, spike triggers, and spike deliverables are three separate decisions, and treating a spike as a substitute for a clarifying question that already has a known answer is the single most common mistake here.

Questions to ask in grooming. "What's the acceptance criteria, how will we know this is actually done?" surfaces a missing definition of done. "Is there a design or mock, or an existing pattern in the codebase we're extending?" surfaces a missing design. "Does this touch a system we don't fully understand yet, a third-party API, a legacy module, an unfamiliar data model?" surfaces a real technical unknown. "What's explicitly out of scope?" prevents scope from silently creeping in mid-build. "Does this depend on another team or story that isn't finished yet?" surfaces a sequencing risk before it becomes a blocked sprint.

When to recommend a spike, not just more grooming. A spike is warranted when the story can't be estimated within a reasonable confidence band because of a genuine unknown, specifically: the team's estimates disagree by an order of magnitude, for example someone says 2 days and someone says 3 weeks, or the story depends on an external system whose real behavior the team hasn't verified firsthand, or it requires touching unfamiliar legacy code with no test coverage. If none of those apply and the team simply hasn't discussed it yet, that's a grooming gap you close with a clarifying question to the PM or stakeholder who already knows the answer, not a spike; reaching for a spike here just delays getting an answer that was already available.

What a spike needs to produce for the story to become estimable and schedulable. A written answer to the specific unknown that triggered the spike, not a general write-up of everything explored. A rough order-of-magnitude estimate for the real story, with a stated confidence level. A list of any new sub-tasks or dependencies the spike uncovered. An explicit note that any code produced is throwaway, not production-ready, flagged as such so nobody accidentally ships it hardened but unreviewed. And if the spike itself runs out of its timebox without an answer, a predefined response: either re-timebox once with a narrower, more specific question, or escalate to the PM that the story likely needs to be broken down further rather than estimated as one unit.

Worked example. A story reads "add support for syncing calendar events from a partner's calendar API." Grooming questions surface that nobody on the team has used this particular partner API before, and its rate-limit and webhook behavior under a bulk sync is undocumented, a genuine unknown, with the team's estimate spread running from 3 days to 3 weeks. That spread is the trigger to recommend a 2-day spike. The spike's deliverable: confirmation that the API supports webhooks rather than requiring polling, a documented rate limit of 500 requests per hour, a revised estimate of 5 to 7 days at medium confidence, and a newly surfaced dependency, a webhook receiver endpoint the story hadn't originally scoped.

Direct answer

The move is to separate diagnosis from reaction: before assuming the gap is unfair (inconsistent criteria, an indifferent manager) or purely a personal failing, do an honest, evidence-based audit of your own case first, then act on what you actually find rather than on the story you started with. That self-diagnosis is what keeps the response grounded instead of either resigned or entitled.

Structured elaboration

1. Name the trigger honestly, whatever it actually is: no advancement across two review cycles, criteria that seem to shift depending on who's managing you, or just a general sense of plateauing. Treat it as a starting observation, not a verdict.
2. Diagnose before reacting. Audit your own evidence (scope actually carried, outcomes attributable to you, feedback received) against whatever the organization's stated or informal bar is. Separately, note if the bar itself looks inconsistent or unclear across managers, that's useful information, not an excuse to skip the audit.
3. Have the direct conversation. Bring your honest self-assessment to your manager and ask explicitly what's missing, rather than silently accumulating resentment or silently giving up on the goal.
4. Decide on a bounded response. Set a real timeframe to see change, and know your own answer for what you'd do if nothing changes, without turning that into an ultimatum in the room.

Worked example

"At one point I'd gone through two review cycles without the scope change I was expecting, and it would have been easy to decide either that the process was broken or that I just wasn't good enough. Instead I sat down and mapped what I could actually point to: had I taken on next-level work, could I show outcomes that were mine, had anyone besides me confirmed it. Some of it held up, some didn't, there was a specific kind of cross-team decision I'd been avoiding making solo. I brought that honest picture to my manager instead of a complaint, asked directly what was missing from their side, and used what came back to set a concrete plan with a real check-in date rather than just waiting quietly for the next cycle."

Trade-offs & pitfalls

• Skipping the self-diagnosis and going straight to a conversation framed as a grievance is the entitled failure mode interviewers are listening for.
• Quietly disengaging or lowering your own ambition instead of raising the issue is the opposite failure mode, and just as costly.
• Blaming inconsistent criteria across managers without also checking your own evidence dodges the harder, more useful half of the question.
• Setting no real timeframe for reassessment lets "wait and see" drift indefinitely. A grounded answer names when you'd revisit the decision.

Approach (brief)
Create a generic hook useForm<T> that stores values, touched, errors, and provides handlers. Support synchronous and asynchronous validators, multi-field rules, debounced validation, and TypeScript generics for type-safety.

API

• values: T
• errors: Partial<Record<keyof T, string>>
• touched: Partial<Record<keyof T, boolean>>
• handleChange(name: keyof T): (e) => void
• handleBlur(name: keyof T): () => void
• handleSubmit(onValid: (values: T) => Promise<void> | void): (e) => void
• setField / reset

Example implementation (core parts)

import { useState, useRef, useCallback } from "react";

type Validator<T> = (values: T) => string | null | Promise<string | null>;
type Validators<T> = Partial<Record<keyof T, Validator<T> | Validator<T>[]>>;

function useForm<T extends Record<string, any>>(initial: T, validators?: Validators<T>) {
  const [values, setValues] = useState<T>(initial);
  const [errors, setErrors] = useState<Partial<Record<keyof T, string>>>({});
  const [touched, setTouched] = useState<Partial<Record<keyof T, boolean>>>({});
  const validatingRef = useRef<Record<string, number>>({});

  const runValidators = useCallback(async (field?: keyof T) => {
    const runForKey = async (k: keyof T) => {
      const vs = validators?.[k];
      if (!vs) return null;
      const list = Array.isArray(vs) ? vs : [vs];
      for (const v of list) {
        const res = v(values);
        const message = res instanceof Promise ? await res : res;
        if (message) return message;
      }
      return null;
    };

    if (field) {
      const msg = await runForKey(field);
      setErrors(prev => ({ ...prev, [field]: msg || undefined }));
    } else {
      const all: Partial<Record<keyof T, string>> = {};
      for (const k of Object.keys(values) as (keyof T)[]) {
        all[k] = (await runForKey(k)) || undefined;
      }
      setErrors(all);
    }
  }, [values, validators]);

  const handleChange = useCallback((name: keyof T) => (e: any) => {
    const value = e?.target ? (e.target.type === "checkbox" ? e.target.checked : e.target.value) : e;
    setValues(v => ({ ...v, [name]: value }));
  }, []);

  const handleBlur = useCallback((name: keyof T) => async () => {
    setTouched(t => ({ ...t, [name]: true }));
    await runValidators(name);
  }, [runValidators]);

  const handleSubmit = useCallback((onValid: (values: T) => any) => async (e?: any) => {
    e?.preventDefault();
    await runValidators();
    if (Object.values(errors).every(v => !v)) {
      await onValid(values);
    }
  }, [errors, runValidators, values]);

  return { values, errors, touched, handleChange, handleBlur, handleSubmit, setValues };
}

Synchronous vs Asynchronous validators

• Accept validator returning string|null or Promise<string|null>. runValidators awaits each and short-circuits on first error.
• Use per-field counters in validatingRef to ignore stale async responses (increment token when start validate; only apply result if token matches).

Multi-field validation

• Provide validators that inspect whole values (Validator<T> receives all values). For example confirmPassword validator reads password and confirmPassword.

Performance & Type-safety

• Use generics T so keys are typed. Memoize handlers with useCallback. Avoid rerenders by batching state updates and storing ephemeral tokens in useRef. Debounce expensive async validations (e.g., onChange) via setTimeout or external debounce hook.

Edge cases

• Stale async results, large forms (virtualize), partial validation modes (onBlur/onSubmit/onChange).