Senior Frontend Developer Interview Preparation Guide - Spotify

Approach summary
Describe features-first for modern browsers (progressive enhancement) and provide simple, robust fallbacks for IE11 (graceful degradation). Use feature-detection (@supports / JS) + build-time transpilation (PostCSS/Babel) + polyfills and test across real/virtual legacy browsers.

Feature detection & CSS examples

• Use @supports to gate modern code (Grid, container queries):

/* use Grid when available */
@supports (display: grid) {
  .layout { display: grid; grid-template-columns: 1fr 3fr; gap: 16px; }
}
/* fallback to flex for browsers without grid */
.layout { display: flex; flex-direction: row; }

• CSS variables fallback pattern:

:root { --brand: #0070f3; }
.button { background: var(--brand, #0070f3); } /* second arg is fallback */

Build & transpilation pipeline

• Use Browserslist to target evergreen + IE 11.
• PostCSS with postcss-preset-env (autoprefixer included) to polyfill newer CSS and add vendor prefixes.
• Example PostCSS config snippet:

module.exports = { plugins: [ require('postcss-preset-env')({ stage: 3, browsers: 'defaults, IE 11' }) ] }

• JavaScript: Babel with @babel/preset-env and core-js for polyfills; configure useBuiltIns: 'entry' or 'usage' per project.

Polyfills & JS feature detection

• Provide polyfills only where needed: core-js (Promise, Symbol), fetch polyfill, URLSearchParams if used.
• Use feature detection in JS (or Modernizr) to conditionally load polyfills:

if (!window.Promise) { import('core-js/features/promise'); }

Fallback layouts & UX

• Prefer mobile-first CSS; ensure layout degrades to a single-column for IE11 if Grid features fail.
• Avoid relying on complex interactions that break; provide non-JS accessible alternatives for critical features.
• For CSS gap in flex (unsupported in some legacy), use margin-based fallbacks.

Testing strategy

• Automated: set Browserslist targets in CI and run cross-browser test suites with BrowserStack / Sauce Labs for IE11 and latest Chrome/Firefox/Safari.
• Visual regression (Percy/Chromatic) to catch layout regressions in legacy viewports.
• Manual: smoke-test on a real Windows 7/10 VM or BrowserStack for keyboard navigation, forms, focus styles.
• Performance & audit: run Lighthouse for evergreen; ensure polyfills are conditionally loaded to avoid perf regressions for modern users.

Trade-offs & notes

• Shipping fewer polyfills => better modern perf; rely on feature-detection and targeted polyfills.
• Where parity is impossible or expensive (CSS Grid advanced alignment), accept visual degradation but keep functionality intact.
• Document browser support and known limitations in README so designers and PMs set expectations.

Direct answer

Decouple "shipped" from "fully rolled out": you can move fast on ambiguous requirements as long as
you control the blast radius of being wrong, using guardrails you build in before you ship, not
after an incident. The guardrails to know here are feature flags, canary releases, service level
agreements (SLAs), and error budgets, and together they turn "quality versus speed" from a values
argument into a number everyone already agreed to ahead of time.

Structured elaboration

Principles:

1. Shipping code to production and exposing it to all your users are two separate decisions with
   two separate risk levels; you can do the first quickly while staying deliberate about the
   second.
2. Invest in the guardrails before you ship something ambiguous, not after it breaks. A guardrail
   retrofitted post-incident is a lesson learned the expensive way.
3. Define, in numbers, what "good enough to learn from" means for this specific feature, since
   ambiguous requirements otherwise leave "quality bar" floating and arguable after the fact.
4. Not all risk is equal: a bug in an internal dashboard shipped fast to learn is a different risk
   class than a bug in a payment flow, and the guardrails you use should scale with which one
   you're touching.

Decision criteria: think in two dimensions, reversibility and blast radius. Low blast radius
and easily reversible: ship fast behind a flag and learn from real usage. High blast radius or hard
to reverse (a schema migration, a pricing change, anything touching money, safety, or compliance):
slow down and add more upfront validation, regardless of deadline pressure, because ambiguous
requirements are not a good enough reason to accept irreversible risk.

Guardrails, and what each one actually is:

• Feature flag: a runtime on/off switch for a piece of code, letting you turn a feature off
  instantly without a new deployment, and expose it to a specific subset of users first instead of
  everyone at once.
• Canary release: rolling a change out to a small slice of traffic or users first (commonly 1
  to 5%) and watching key metrics before expanding further, so a bad change only affects a small
  group before you find out.
• SLA (service level agreement): a stated commitment about how reliable or fast a service will
  be, for example 99.9% uptime or sub-300-millisecond response time, often with a real consequence
  attached if missed, that sets an outer bound you don't cross even while moving fast.
• Error budget: the amount of unreliability you're explicitly allowed, on purpose, within a
  given period, derived from your SLA. A 99.9% uptime SLA implies roughly 43 minutes of allowed
  downtime per 30-day month (the math: 1 minus 0.999, times 30 days, times 24 hours, times 60
  minutes, is about 43.2 minutes). While you're within that budget, you ship and experiment freely;
  once it's burned, feature work pauses and the team fixes reliability first. This turns "should we
  slow down" into a number both sides already agreed to, instead of a fresh argument every time.

Worked example: a notifications feature adjacent to payments, with ambiguous requirements on
exact trigger conditions. Ship it behind a flag to a 2% canary for one week, tracking opt-out rate
and error rate against the existing SLA and error budget. If this feature's error-budget
consumption stays under, say, 10% of the monthly budget, and opt-out rate stays under 5%, expand to
25%, then to everyone, over the next two weeks. If error-budget consumption spikes instead, the
flag kills the feature instantly with no redeploy needed, and the damage stays isolated to the 2%
cohort (basis: cohort-level error rate, not the whole user base).

Second, shorter example (different discipline): a marketing team piloting a new lifecycle
email sequence to 5% of the list before a full send is running the identical canary logic without
any code involved: bounded exposure, a pre-set metric (unsubscribe rate) to watch, and a defined
threshold before expanding to the full list.

Trade-offs and pitfalls

"Move fast and fix it later" with no guardrail works right up until "later" is a public incident.
The opposite mistake, blocking everything on a fully specified plan before shipping anything, just
recreates the slow, spec-first failure mode the question's premise (ambiguous requirements) is
explicitly asking you to work around, not wait out.

Input vs Change

• input: Fires synchronously whenever the value of a form control changes (each keystroke, paste, drag). Use for live validation, search-as-you-type, or updating UI in real time.
  • Example: updating a filtered list as user types.
• change: Fires when the control loses focus and the value has changed (or on commit for selects). Use for final/committed value processing (e.g., submit-ready validation, analytics).
  • Example: updating model only on blur to avoid frequent re-renders.

keydown vs keypress vs keyup

• keydown: Fires when a key is pressed down. Useful for detecting special keys (Esc, Arrow keys), preventing default behavior, or implementing keyboard shortcuts. Fires before character is produced.
• keypress: Legacy, deprecated for many uses; fired for printable characters in older browsers. Avoid it — use keydown/keyup and inspect event.key.
• keyup: Fires when the key is released. Good for actions that should occur after the full key press (e.g., measuring final key state).

Performance considerations

• input and keydown can be high-frequency. Debounce or throttle handlers for expensive work (network calls, heavy DOM updates). Prefer passive listeners where appropriate and avoid layout thrashing (batch DOM reads/writes). In frameworks, minimize state updates per event (e.g., setState batching, requestAnimationFrame for visual updates).

Direct answer

Set a line breakpoint where the argument is used, then right-click it and add a condition. DevTools then only pauses on the call you actually care about, instead of resuming through every call by hand, and unlike a console.log you don't have to edit the source, redeploy, or remember to strip it back out afterward.

Structured elaboration

• Locate the function (Cmd/Ctrl+P to jump to file, or jump from the triggering element/request).
• Set a plain breakpoint, then right-click its gutter marker and add a condition like arg === undefined.
• Use the Scope and Call Stack panels at the pause to see the value and who called it, which gives you every in-scope variable and the full caller chain for free, versus a console.log that only shows whatever single expression you remembered to print.
• If pausing would break timing-sensitive code, use a logpoint instead (same menu), which prints without stopping and without touching the source file at all.

Worked example

Say the function runs 500 times per page load and only 2 calls are malformed:

$\frac{500}{2} = 250$

A plain breakpoint costs about 250 resumes per bad call found; a conditional one costs one setup and zero resumes. A console.log approach would need a code edit, a reload, and manually scanning 500 printed lines for the 2 that matter.

Trade-offs and pitfalls

An expensive condition re-evaluates on every hit and can slow a hot loop, so keep conditions cheap and side-effect free. Never ship a leftover debugger; statement, the same discipline problem console.log has, just caught by the debugger itself instead of a stray log line reaching production.

What the interviewer probes next

Whether you know logpoints exist, and how you'd do this against a minified production bundle.

I would treat this as a change-management problem, not just a rollout problem.

First, I would diagnose where adoption is breaking down. I would review usage data, interview a few people from each function, and compare the new process to the old one. I want to know whether people are resisting because the process is too slow, unclear, misaligned with incentives, or simply not useful in their day-to-day work.

Then I would test the rollout design. I would ask: did we train people, give them a reason to care, and remove the old path? For example, if support keeps using the old escalation template, maybe the new process adds friction and does not solve their problem fast enough.

If the issue is execution, I would tighten enablement, add team champions, and publish a clear operating cadence. If the issue is the process itself, I would change it based on the feedback rather than forcing adoption of a bad design.

I would judge success by outcomes, not attendance at meetings. If adoption improves, cycle time drops, and fewer teams revert to the old habit, the rollout is working. If not, I would change the process before asking for more compliance.

For example, when a company rolled out a new cross-functional incident-escalation process across product, engineering, and support, usage data after three weeks showed only 40% of support tickets were being routed through the new template, the rest were still going through the old one. Interviews with five support agents revealed the real problem: the new template required them to fill in a business-impact field that only engineering had the context to answer, so agents defaulted back to the old, faster template rather than get stuck. That pointed to a process-design gap, not a training gap. The fix was to move the business-impact classification to a follow-up step engineering completed after triage, instead of asking support to guess it up front. Within two weeks of that change, template usage rose to 92%, and average escalation cycle time (the time from a ticket being flagged to a fix being assigned) dropped from about 3.5 days to just under 2 days.

Approach overview
Compare patterns by showing compact TypeScript examples for a counter widget, then discuss testability, mutability, composition, and maintainability.

Functional (immutable, pure)

// functional.ts
type State = { count: number };
type View = (s: State) => string;

const init = (): State => ({ count: 0 });
const update = (s: State, delta: number): State => ({ ...s, count: s.count + delta });
const render: View = s => `<div><span>${s.count}</span></div>`;

// usage: state = update(state, 1); container.innerHTML = render(state);

Object-Oriented (encapsulated, methods)

// oop.ts
class CounterWidget {
  private count = 0;
  constructor(private container: HTMLElement) {}
  incr() { this.count++; this.render(); }
  decr() { this.count--; this.render(); }
  private render() { this.container.innerHTML = `<div><span>${this.count}</span></div>`; }
}

Trade-offs

• Testability: Functional code is easier to unit-test (pure functions, no DOM side effects). OOP needs mocking or exposing internal state or injecting renderer.
• Mutability: FP favors immutable state (safer concurrency, predictable). OOP often mutates internal members (convenient, can cause hidden state bugs).
• Composition: FP composes via function pipelines and reducers; it's flexible for state machines and time-travel debugging. OOP composes via inheritance or composition of objects—clear encapsulation but can lead to rigid hierarchies.
• Maintainability: FP can be more verbose for side effects (need effect management) but scales well for complex state logic. OOP groups behavior with state making small widgets straightforward; larger systems risk tight coupling.

Choose based on team familiarity, framework (React favors FP-style state), and complexity of side effects.

Direct answer
"Unclear requirements" is a real cause sometimes and a convenient explanation other times, so the first job is figuring out which, using evidence rather than taking the explanation at face value. Look at the pattern across several instances, not just the latest miss, separate estimation problems from execution problems from actual requirement gaps, then fix the specific mechanism, not the person's attitude.

Diagnose using the pattern, not the excuse

• Pull several recent examples, not just the most recent miss. Was the requirement genuinely ambiguous every time, or does "unclear requirements" get invoked even when the ticket had clear acceptance criteria? The former is a process problem; the latter is a signal something else is going on (confidence, avoidance, poor estimation).
• Look for where in the workflow it breaks down: did they ask clarifying questions before starting and get bad answers, or did they not ask and guess? Did the requirement change mid-task without being re-scoped? Did they commit to something they didn't actually understand, to avoid looking behind?

Separate the possible root causes

• Genuine ambiguity: the requirement really was underspecified and nobody caught it before work started.
• Estimation or planning gap: the requirement was clear but the person didn't break it down enough to notice the ambiguous parts until they hit them.
• Avoidance: asking clarifying questions feels risky (looks like not knowing), so they guess and then have a ready explanation when it goes wrong.
• Skill gap under a different name: they may not yet have the judgment to know what "clear enough to start" looks like.

Fix the mechanism that matches the cause

• Genuine ambiguity: introduce a lightweight definition-of-ready check before work starts, owned jointly, not something you police alone.
• Estimation or planning: practice breaking a ticket into sub-tasks together and flag the ambiguous piece explicitly before committing to a date.
• Avoidance: make asking clarifying questions cheap and normal, model it yourself, and separate "I don't know yet" from an evaluation of competence.
• Skill gap: pair on a couple of tickets so they see what "clear enough" actually looks like in practice, rather than being told about it abstractly.

Worked example
A mentee on a team I supported kept missing sprint commitments, and the stated reason was always some version of unclear requirements. Looking at the last four tickets together, not just the most recent one, a pattern showed up: on three of the four, the acceptance criteria were actually written clearly, but the mentee hadn't asked any clarifying questions before starting, then hit an edge case mid-task and treated the whole ticket as ambiguous from the start. On the fourth, the ticket genuinely was underspecified.

The fix wasn't "communicate more clearly" in the abstract. It was two things: a short pre-work check where we'd both look at a ticket before it was picked up and flag anything genuinely unclear (catching the real ambiguity case), and a habit of the mentee sending one clarifying question per ticket before starting, even a small one, to break the avoidance pattern. The signal it was working wasn't a single metric; it was that "unclear requirements" stopped being the explanation for misses, because the real ambiguity was being caught earlier and the avoidance pattern had a lower-stakes outlet.

Trade-offs and pitfalls

• Taking "unclear requirements" at face value every time lets a deeper issue (avoidance, skill gap) hide behind a plausible-sounding excuse indefinitely.
• Assuming it's never true is just as wrong; requirements genuinely are underspecified sometimes, and treating every instance as a character problem erodes trust.
• The fix has to match the actual cause. A definition-of-ready checklist won't help someone avoiding asking questions, and coaching someone to "just ask more" won't help if the requirements really were bad.

Direct answer
An edge case (or corner case, when two or more boundary conditions intersect) is an input, state, or condition at the extreme or unusual end of what a system is expected to handle, distinct from the 'happy path' of typical, well-formed usage; systematically identifying them matters because production traffic and adversarial users reliably generate exactly these unusual conditions, while happy-path testing alone only proves the system works when everything goes as expected, which is rarely where real defects live.

Structured elaboration: eight categories, spanning multiple domains

1. Empty/null: an empty list, a null field, a zero-length string. Example (general software): a search function called with an empty query string.
2. Boundary/max-min: values exactly at, or one step past, a defined limit. Example (backend): a pagination page_size parameter at exactly the server-enforced maximum.
3. Zero/negative: values a numeric field technically accepts as a type but that may be nonsensical for the domain. Example (SRE/production): a negative value in a counter that should only ever increase, signaling either overflow or a bug in the decrement logic.
4. Duplicate: repeated values where uniqueness might be silently assumed. Example (general software): two items with the same ID in a list a system expects to be de-duplicated upstream.
5. Malformed/invalid type: input that is the wrong shape or type entirely. Example (backend): a JSON field expected to be an integer arriving as a string or an array.
6. Out-of-order/concurrent: events or requests arriving in an unexpected sequence, or overlapping in time. Example (SRE/production): a delivery-confirmation event for a message arriving before the message-sent event, due to network reordering.
7. Very large/very small scale: inputs at a magnitude far outside typical testing. Example (data/ML pipeline): a categorical feature with hundreds of millions of unique values (e.g. a raw user ID) fed into a one-hot encoder, which can silently exhaust memory.
8. Environment/locale-specific: behavior that only manifests under a specific timezone, locale, or platform. Example (general software): a date-parsing function that behaves correctly in the US locale but misinterprets day/month order elsewhere.

Worked example: why happy-path testing alone misses these
A login form tested only with a valid, well-formed email and a correct password will pass every happy-path test while shipping with a null-pointer crash on an empty password field, an infinite spinner on a 10,000-character email, or a silent security bypass on a SQL-injection-shaped username, none of which a happy-path suite would ever exercise, because by construction happy-path tests only feed the system inputs the developer already expected to work.

Trade-offs & pitfalls
Treating 'edge case' as synonymous with 'rare' is a common misconception: an empty list or a zero value is often one of the MOST common real-world inputs (a brand-new user's empty cart, a freshly-created account with no activity yet), not a rare corner case, which is exactly why the empty/null category above is listed first, not last; conflating 'edge case' with 'unlikely' leads teams to systematically under-test the cases that actually occur most often in a real user base's earliest interactions with a feature.

Clarify goal
Receive third‑party webhooks, verify, dedupe, persist, then push near‑real‑time updates to connected browsers (WebSocket/SSE with polling fallback). I’ll describe a backend flow and how the frontend integrates.

Backend flow (high level)

• Public webhook HTTP endpoint behind load balancer -> API gateway -> webhook service.
• Webhook service: verify signature, parse payload, check dedupe/idempotency, persist event, enqueue dispatch job.
• Dispatcher: fan‑out to subscribers (WebSocket/SSE channels) and to retry queue for failed deliveries.

Verification (HMAC / signature)

• Third party sends header (e.g., X-Signature: sha256=hex).
• Server computes HMAC: HMAC_SHA256(shared_secret, raw_body) and compare using constant‑time compare.
• Reject if timestamp skew > threshold to avoid replay attacks.

Idempotency / deduplication

• Use provider event id (header/body) as unique key.
• Persist event with unique constraint on event_id; if insert fails, treat as duplicate.
• Optionally store a short‑lived cache (Redis SET with NX + TTL) for fast dedupe before DB write.

Persist

• Store raw payload, event type, status, consumer metadata, timestamp in events DB/table for auditing and replay.

Retry / backoff for failed deliveries

• When dispatcher fails to deliver to client (e.g., offline WS), mark attempt and schedule retries with exponential backoff + jitter (e.g., 1m, 2m, 5m, 15m).
• Use a durable queue (Redis streams or task queue) to survive restarts and track attempt counts; stop after max attempts and alert.

Pushing updates to browsers (frontend perspective)

• Preferred: WebSocket for bi‑directional low‑latency needs (React client opens WS, subscribe to channels).
• Simpler: Server‑Sent Events (SSE) for one‑way streams (works well for updates; auto reconnect).
• Fallback: Polling (short interval) when neither available or for legacy browsers; implement conditional GET / ETag to reduce payload.
• On the frontend, handle reconnect/backoff, de‑duplication (use event_id), and optimistic UI patterns. For missed events on reconnect, fetch recent events via REST /events?since=last_event_id.

Why this fits a frontend role

• As a frontend dev, implement robust client that: maintains connection, verifies sequence via event_id, retries subscribing, and gracefully degrades to polling. Ensure UX shows delivery state and allows manual refresh when necessary.

Situation & goal
Two senior frontend engineers disagree on component composition (e.g., container-presentational vs. hooks-driven composition) and how juniors should be mentored. As technical lead I need to resolve conflict, create consistent guidance for juniors, and capture best of both views into a teachable standard and onboarding materials.

Action plan

1. Facilitate a focused, timeboxed design discussion
   • Ask each senior to present pros/cons with concrete examples (small demo repo or 10–15 minute walkthrough).
   • Capture trade-offs: reusability, testability, bundle size, mental model for juniors.
2. Align on objective criteria
   • Define measurable decision factors: bundle impact (< +2 KB), average unit test coverage (> 80%), render performance (no noticeable jank in 95th percentile), and developer onboarding time.
3. Prototype and measure
   • Implement two small sample components (one for each approach) in a feature branch with docs and tests.
   • Run simple metrics: bundle size (webpack), test coverage, and a quick dev survey (5 devs including 2 juniors) for understandability.
4. Synthesize a hybrid standard
   • Keep strengths from both approaches (e.g., use hook-based composition for shared logic + explicit presentational props for clarity).
   • Produce a concise pattern guide: when to use hooks, when to split container/presentational, naming conventions, prop vs. context rules.
5. Make it teachable and enforceable
   • Create onboarding materials: checklist, example repo, 1-hour recorded walkthrough, and a 2-week mentor pairing plan.
   • Add PR template and linter/ESLint rules to catch anti-patterns.
6. Coaching & feedback loop
   • Pair juniors with alternating mentors from both seniors for first 2 sprints.
   • Run weekly office hours and monthly retro to adjust the standard.

Concrete example

• Standard: "Use hooks for local logic and reusable behavior; split purely presentational component when markup > 50 lines or props > 6."
• Onboarding: 1-hour workshop + 3 guided PRs in first sprint.

Measurable outcomes

• Reduce onboarding time by 30% (measured by time to first approved component PR).
• Achieve 90% adherence in first 8 weeks (via automated lint + quarterly audits).
• Increase junior confidence (pre/post survey) by 40%.

Result & learning
This approach resolves the conflict through evidence, yields a practical hybrid standard, ensures juniors receive consistent, measurable guidance, and keeps both seniors engaged by adopting their best ideas.