Mid-Level Full-Stack Developer Interview Preparation Guide for Spotify

Direct answer

The partnerships that pay off under deadline pressure are almost never built in the moment you need them. They come from investing time in a working relationship with a team before there's a specific ask attached, understanding their priorities and vocabulary well enough that when you do need something urgent, they already trust your judgment and don't need to re-derive context from scratch.

Structured elaboration

1. Choose deliberately where to invest. You can't build deep relationships with every team you might someday depend on. Invest ahead of need in the teams whose dependencies are likely to become recurring or critical-path (on the chain of dependent work that directly determines a deadline), based on how your roadmap or their roadmap is shaping up.
2. Invest with no immediate ask attached. Show up to their planning or triage occasionally, offer help on something low-stakes, or spend time understanding how they prioritize their own queue. The absence of a request is what makes it relationship-building rather than a transaction.
3. Learn their vocabulary and criteria, not just their org chart. Knowing how a team actually decides what's urgent (their SLA, or service level agreement, tiers, meaning their committed response and turnaround times, and their escalation triggers) is what lets you frame a future ask in terms they'll immediately recognize as legitimate.
4. Share your own context too. A partnership that pays off later is two-directional: they should understand your team's constraints and cadence well enough that an urgent ask from you doesn't sound out of character.
5. When the moment comes, lean on the relationship, not authority. The payoff isn't that they're obligated to help, it's that they already trust your scoping and don't need to independently verify the ask is real before acting on it.

Worked example

As a backend engineer, I noticed my team periodically needed fast turnaround from the support team but had no real relationship with them beyond ticket queues. Over a few months, with no active request pending, I started sitting in on their triage session once a month, just listening and asking questions about how they decided what jumped the queue. In one of those sessions I noticed a complaint that kept resurfacing: a specific error support couldn't explain, so they were closing the tickets as "can't reproduce." I flagged it to the engineer on our side who owned that area, and made sure support knew we were looking into it even though nothing was urgent yet.

Months later, that same underlying issue caused a customer escalation with a tight deadline attached. I reached out directly to the support lead I'd built rapport with, framed the ask using the same triage language they used internally, and was specific about why it was time-sensitive. Because they already trusted that I didn't cry wolf and that my scoping was accurate, they fast-tracked the escalation ahead of their standard queue without needing the usual back-and-forth to validate it was real.

(Swap the domains freely: the same pattern works with a platform team, a design team, or a data team in place of support, as long as the investment happens before there's an active ask.)

Trade-offs & pitfalls

• Pitfall: relationship-building that's transparently transactional (showing up only when you're about to need something) reads as insincere and doesn't produce the trust you're after.
• Pitfall: investing broadly and shallowly across every team instead of selectively where dependencies are likely to matter. That spreads your own team's time thin for little return.
• Pitfall: treating the payoff as owed. A relationship earns goodwill; it doesn't guarantee compliance, and presuming it does damages the very trust you built.
• Senior differentiator: recognizing which dependencies are likely to become critical-path before they do, and investing ahead of the need rather than starting the relationship the day you first need a favor.

What I'd want to know about the workload first

• What the writes actually look like: single-row inserts versus batches, and whether the current bottleneck is disk I/O throughput, lock contention, or the overhead of committing (fsyncing) every individual write.
• Consistency requirements: can writes tolerate being asynchronous or eventually consistent, or does every write need to be immediately readable?
• Whether the data has a natural partition key (tenant ID, user ID, region) that writes could be split across, which is the precondition for horizontal scaling to even be viable here.
• Whether this is a one-time ceiling to clear or a trajectory that will keep climbing, since that changes how much re-architecture effort is worth investing now.

The decision framework

• Vertical scaling (a bigger instance, faster disks, more provisioned I/O): the fastest to implement and a reasonable choice if the headroom needed is modest and short-term, but it has a hard ceiling and doesn't fix a bottleneck that's inherently serial, like a single-writer commit log.
• Horizontal scaling (sharding writes across multiple database instances by a partition key): the sustainable choice if growth is ongoing and a good partition key exists, but it's a real re-architecture: a routing layer, and any query that spans shards gets harder.
• Changing the write pattern itself (batching writes, moving to an async queue, or a storage engine built for write-heavy workloads): often the highest-leverage option when the writes are small and frequent, because it reduces the cost per write instead of adding infrastructure.

A worked example

Say the primary is doing 4,000 writes/sec against a disk I/O ceiling of about 4,500 IOPS (input/output operations per second), with each write triggering its own commit. Batching writes into groups of 50 before committing turns 4,000 individual writes into roughly 80 batched commits/sec, which is far under the ceiling and buys significant headroom without touching hardware. That's why I'd usually check whether the write pattern itself can be improved before reaching for sharding.

What could go wrong with each approach

• Vertical: hits a cost or instance-type ceiling eventually, and the single instance stays a single point of failure the whole time.
• Horizontal: a poorly chosen partition key creates a hot shard that's just as bottlenecked as before, and operational complexity goes up.
• Batching/async: introduces a delay before a write is visible (staleness), needs idempotent retry handling (idempotent: safe to retry, because re-running the same write produces the same end result as running it once), and if the downstream queue consumer falls behind, the bottleneck just moves to the queue instead of being fixed.

Direct answer. SELECT * pulls every column regardless of what the query actually needs, which increases network transfer, defeats the possibility of an index-only scan (since the index almost never contains every column), and silently breaks if the table's column set changes; rewrite it to name only the columns the caller actually uses.

Structured elaboration. Three distinct costs stack up. First, I/O and network: every extra column is extra bytes read from storage and sent over the wire, even for columns the caller immediately discards, which matters most for wide tables or ones with large text/JSON columns. Second, index eligibility: an index-only scan requires every needed column to be present in the index; asking for every column in the table makes that essentially impossible for any index narrower than the full row, forcing a heap visit that a narrower SELECT might have avoided. Third, fragility: if the table gains a column later, every SELECT * consumer starts receiving it whether or not it's ready to, which has broken more than one downstream integration in ways that are hard to trace back to the schema change that caused it.

Worked example. For transactions(transaction_id, user_id, amount, currency, created_at, status, metadata jsonb), a dashboard that only needs the four most recent completed transactions' amount and date has no business fetching the metadata JSONB column at all:

-- anti-pattern: pulls every column, including a large JSONB payload
SELECT * FROM transactions
WHERE status = 'completed'
ORDER BY created_at DESC
LIMIT 100;

-- production-safe: only the columns the caller actually uses
SELECT transaction_id, amount, created_at
FROM transactions
WHERE status = 'completed'
ORDER BY created_at DESC
LIMIT 100;

The rewrite reduces network payload substantially (dropping metadata, currency, status, and user_id from the wire format) and makes it possible, if status and created_at were part of a covering index that also included transaction_id and amount, for the query to be served entirely from that index.

Trade-offs and pitfalls. Naming columns explicitly is marginally more code to write and to keep in sync as requirements change, which is the entire reason SELECT * remains tempting; treat that maintenance cost as strictly smaller than the recurring, compounding cost of over-fetching on every single execution of a query that runs often.

Complexity

The change doesn't alter the query's algorithmic shape; it changes the constant factor on I/O and network transfer per row, and can change whether an index-only path is even available at all.

Edge cases

A table with a genuinely small number of columns, all of which the caller uses anyway, gets little practical benefit from this rewrite; the cost matters most on wide tables or ones with large variable-length columns like JSON or text blobs.

Direct answer

Relational (SQL) databases enforce a fixed schema and strong transactional guarantees, ACID: atomicity, consistency, isolation, durability, across related tables, making them the right default whenever the correctness of interrelated data matters more than raw write throughput or schema flexibility. Non-relational (NoSQL) databases trade some of that structure and transactional strength for a flexible schema and horizontal scalability, making them the right choice when data is naturally document-shaped, key-value-shaped, or high-volume enough that spreading it across many nodes matters more than joining it in a single query.

Structured elaboration

Worked example

An e-commerce platform rarely picks one store for everything; it's a polyglot-persistence decision made per data shape.

• Orders and payments go in a relational database, because completing an order touches multiple related rows, the order, the payment, the inventory decrement, that must succeed or fail together, and the business needs ad hoc reporting across them.
• The product catalog goes in a document store, because different product categories genuinely have different attribute sets (a book has an author and page count, a t-shirt has a size and color), and forcing that into a fixed relational schema means either a table full of mostly-null columns or a constant stream of migrations.
• Session state or an in-progress shopping cart goes in a key-value store, because it's accessed by a single key, the session id, needs to be fast, and doesn't need to be joined with anything else.

None of these is "the database for this company"; they're three separate, defensible answers to three differently shaped access patterns on the same platform.

Trade-offs & pitfalls

• Choosing NoSQL for anticipated scale the product doesn't have yet, paying for lost transactional guarantees and application-level join logic before there's any actual scale benefit to show for it.
• Forgetting that "NoSQL" is not one thing: a key-value store, a document store, and a graph database solve different problems, and citing "NoSQL" as a single technology choice is a sign the trade-off hasn't actually been thought through.
• Treating the choice as permanent and binary rather than per-data-shape, polyglot persistence, which is how most real systems at scale are actually built.
• What separates a senior answer: naming the specific access pattern, single-key lookup, multi-row transaction, flexible attributes, graph traversal, that drives each choice, rather than reciting "SQL is for structured data, NoSQL is for unstructured data," which is imprecise enough to be nearly meaningless.

Direct answer

Reach for Map over a plain object when keys aren't guaranteed to be strings or symbols, when you need guaranteed insertion-order iteration and an O(1) size check, or when prototype-chain surprises are a real risk. Reach for Set over a plain array when what you actually need is "does this value exist" or "keep only unique values," since a Set gives O(1) average membership and dedup where an array forces an O(n) scan (or its own hand-rolled dedup logic) every time. Defaulting to the general-purpose type out of habit doesn't just cost elegance: for the operations these dedicated types exist for, it costs an entire complexity class.

Structured elaboration

Object vs. Map

Array vs. Set

• Set: any value as a member (including objects), O(1) average add/has/delete, automatically de-duplicates, .size is O(1).
• Array: ordered, indexable, allows duplicates; the right choice when order matters, duplicates are meaningful, or you need index-based access; the wrong choice for a membership checklist.

Worked example

Checking whether each of 1,000 newly submitted emails already exists among 100,000 already-registered emails: doing that check with array.includes() inside a loop over the 1,000 new signups costs, in the worst case, $100{,}000 \times 1{,}000 = 100{,}000{,}000$ comparisons. The same check against a Set built once from the 100,000 emails costs roughly 1,000 O(1) lookups, a five-order-of-magnitude difference driven entirely by swapping the container, not the algorithm around it.

Trade-offs & pitfalls

• Prototype pollution: an Object used as a dictionary with attacker-influenced keys can be tricked into touching __proto__ or other inherited properties unless created with Object.create(null) or accessed defensively; a Map has no such surface.
• The integer-key ordering quirk: because integer-like keys on a plain Object are iterated in ascending numeric order BEFORE string keys in insertion order, an object used as an ordered log or sequence (where insertion order is assumed to be preserved for every kind of key) can silently reorder itself the moment a numeric-looking key is added; Map has no such special case.
• Small vs. large collections: for a handful of known string keys (e.g. a small config object), a plain Object is simplest and has the least overhead; for large or highly dynamic collections, or when keys aren't plain strings, Map/Set are the safer default.
• Habit cost: reaching for an array as a "have I seen this" checklist is the single most common instance of this mistake, since it silently turns an O(n) operation done many times into effectively O(n^2) behavior overall.

Direct answer
Replace a vague quantifier with a specific number, a specific comparison point, or an explicit definition of what counts, so the reader can check the claim rather than just trust your impression of it.

Structured elaboration

• "Significant increase" is unfalsifiable on its own: significant compared to what, and by how much? Fix it by naming the actual number and the baseline it's compared against.
• "Large drop" has the same problem in the other direction; a reader can't tell if that means a 5% dip or a 50% collapse.
• The general pattern: replace a subjective adjective ("significant," "large," "modest") with either a number and a baseline, or, if the exact number genuinely isn't available, an explicit statement of the range and why it's uncertain, which is still more falsifiable than a bare adjective.
• A quick self-check: could someone else look at the underlying data and disagree with whether your adjective was the right one? If yes, the phrase is doing too much subjective work and needs a number behind it.

Worked example
Vague: "Revenue saw a significant increase this quarter."
Specific: "Revenue grew 18% quarter-over-quarter, from $4.2M to $5.0M."

Vague: "There was a large drop in signups after the pricing change."
Specific: "Signups fell 34% in the two weeks after the pricing change, from roughly 1,400/week to about 920/week."

Vague: "Customer satisfaction scores showed a modest improvement."
Specific: "Our NPS (Net Promoter Score, a customer-loyalty survey metric typically scored from -100 to 100, based on how likely customers are to recommend you) moved from 32 to 38, a 6-point increase, over the last two survey cycles."

Each rewrite keeps the same claim but replaces the reader's guesswork with a number and a comparison point they can independently evaluate.

Trade-offs and pitfalls

• If you genuinely don't have the precise number, don't invent a specific-sounding one to appear rigorous; say "we don't have an exact figure yet, but early signals suggest an increase" rather than fabricating false precision.
• Numbers without a baseline can still mislead ("revenue grew 18%" sounds good until you learn it grew from a very small base); include enough context that the number is honestly interpretable, not just numeric.
• Overloading every sentence with numbers can make a document harder to read, not easier; reserve the rigor for the claims that are actually load-bearing for a decision.

Direct answer. Put a single translation layer between "whatever actually broke internally" and "what the client sees," so every internal exception passes through one place that decides the client-facing status code and message, rather than letting internal error text leak out through whichever handler happened to catch it.

The translation layer's job. Catch exceptions at the boundary (a global exception handler, or a dedicated error-mapping function every route calls into), and for each KNOWN category of internal failure, map it to a specific, safe, client-facing error: a database unique-constraint violation becomes a 409 Conflict with a generic "this resource already exists" message, not the raw constraint name and table structure; an internal service timeout becomes a 503 with a retryable flag, not the internal service's hostname or the exact RPC that failed; anything UNRECOGNIZED (a genuine bug, not a known failure category) becomes a generic 500 with no detail beyond a correlation id, specifically because an unrecognized exception is the one case where you cannot be confident that its message does not accidentally contain something sensitive (a query with embedded user data, a file path, a partial credential).

Preserving the real error for debugging. The translation layer logs the FULL original exception (stack trace, internal service name, the real error text) server-side, tagged with the same correlation id that goes back to the client in the sanitized response. An SRE or engineer investigating an incident looks up that correlation id in the logs and gets everything; the client only ever sees the generic, safe version plus that same id to hand back for support.

Why an allow-list of known mappings, not a deny-list of things to strip. Trying to scrub specific sensitive PATTERNS out of an arbitrary internal error message (strip anything that looks like a file path, strip anything that looks like a hostname) is a losing game against an internal system that can produce arbitrarily-shaped error text; the safe default has to be "unless this exception is on our known, reviewed list, the client gets a generic message," not "leak everything except what we thought to filter."

Trade-offs and pitfalls. The most common near-miss is mapping the KNOWN error categories correctly but forgetting that a catch-all handler for UNKNOWN exceptions defaults to including the exception's own message in the response "to help debugging," which reintroduces exactly the leakage this whole layer exists to prevent, the first time an unanticipated internal error happens to contain something sensitive.

Approach

The race this protocol must prevent is: a read misses, starts fetching the (soon to be stale) value from the datastore, and finishes AFTER a concurrent write has already invalidated the cache, silently re-populating the cache with a now-outdated value. A first-draft fix (gate the write-back on the cache entry being absent, using the version the reader captured) turns out to be unsafe: deleting on invalidation makes the entry absent, and "absent" is indistinguishable from "never written" to a check that only looks at whether something is currently cached. The correct fix is a per-key minimum acceptable version marker that is set on every invalidation and survives even when nothing is cached, so a stale write-back can be rejected even when it is racing against an empty cache slot.

Client and server steps (pseudocode)

# Server-side: every entity has a monotonically increasing version stored with it.
def read_with_cache(cache, datastore, key):
    entry = cache.get(key)
    if entry is not None:
        return entry.value

    version_before, value = datastore.read_with_version(key)
    # Reject the write-back if a newer invalidation has already raised the floor
    # past the version this reader captured -- NOT merely "if nothing is cached".
    cache.compare_and_set(key, version=version_before, value=value)
    return value

def write(cache, datastore, key, new_value):
    new_version = datastore.write_and_bump_version(key, new_value)
    # invalidate() raises the per-key minimum-acceptable-version floor and drops
    # any currently cached value; the floor itself is retained even though the
    # value is gone, which is what closes the race below.
    cache.invalidate(key, new_version)

# Cache-side semantics (what compare_and_set / invalidate must implement):
#   compare_and_set(key, version, value):
#       if version < min_version.get(key, -1): return False   # reject: stale
#       entries[key] = (version, value); return True
#   invalidate(key, version):
#       min_version[key] = max(min_version.get(key, -1), version)
#       entries.pop(key, None)

Key points

The floor (min_version) is bumped on every invalidation and is checked independently of whether a value is currently cached; this is what closes the gap a plain "write only if absent" check leaves open. A conditional write-back that fails leaves the cache correctly empty (a miss), which is always a safe outcome, versus a value that is silently wrong. Using an unconditional invalidate on write (rather than trying to update the cache in place) avoids a second race where the write's own cache update could be overtaken by a slower concurrent read's write-back.

Complexity

Each read is O(1) cache operations plus O(1) datastore operations on a miss; each write is O(1) datastore plus O(1) cache invalidate. The protocol adds one small piece of state per entity (a version number) and one small piece of state per cache key (the floor), not per read, so the overhead is small and constant.

Edge cases (verified by execution, not just reasoning)

A concrete adversarial simulation was built and run: a reader captures version_before = 0, is delayed mid-flight, and a concurrent writer commits a new value and invalidates before the reader's write-back lands. The first draft of this design (gating on cache-entry absence) failed this test, the stale value was actually written into the cache, reproducing the exact bug the protocol is meant to prevent. The corrected, floor-based design was re-run against the same adversarial interleaving and passed: the stale write-back is rejected and the cache is left correctly empty. Two regression cases were also verified: a normal, uncontested cache populate still succeeds, and a reader starting AFTER the write still successfully caches the new value (no permanent lockout from the floor). Two concurrent writes to the same key must still serialize at the datastore (normal transactional/optimistic-concurrency handling there); this protocol only protects the READ path's interaction with a write, not concurrent writes with each other. A cache implementation without native compare-and-set support can approximate this with a version-suffixed key (key:v42) plus a separately tracked "floor" value, accepting the small added complexity of a second lookup.

Direct answer

Treat the challenge as a request to reproduce your measurement, not just recall it: state what you measured, over what window, compared to what baseline, and show the arithmetic that gets from the raw numbers to the headline figure.

Structured elaboration

Define the comparison
State what counts as "before" and what counts as "after," and why those windows are fair: both should be steady-state periods, excluding any rollout ramp or known incident windows.

State what was measured and how it was aggregated
Mean versus median, per-request versus per-session, and whether the metric is skewed (latency and revenue usually are, which makes the mean sensitive to outliers).

Show the calculation explicitly
Percent change = (baseline − post) / baseline. Walk through the actual subtraction and division rather than presenting only the resulting percentage.

Name what you controlled for
Traffic mix, seasonality, and any other concurrent change in the same window, so the interviewer can see the number isn't confounded by something unrelated.

Acknowledge precision limits honestly
If you don't remember the exact sample size or exact percentage, say the honest range rather than inventing false precision under pressure.

Worked example

Claim: "we cut average response time by 40%."

Baseline window: two weeks of steady-state traffic before the change, n = 8,400 requests, mean latency = 250 ms.

Post window: two weeks after the change stabilized, excluding the rollout ramp, same traffic pattern, n = 8,100 requests, mean latency = 150 ms.

Calculation, shown explicitly:

Controls: both windows fell within the same quarter with stable weekly traffic volume (within about 5% week over week), and no other deploy touched this service during either window.

If pressed further: the 40% figure is the change in the mean. The p99 (worst-case) latency moved less, since a handful of slow outlier requests remained, so I would flag that the improvement wasn't uniform across the full distribution when presenting the complete picture.

Trade-offs & pitfalls

• Giving the interviewer only the final percentage, with nothing about baseline, window, or sample, reads as unable to reproduce your own claim.
• Comparing mismatched windows (for example, a holiday-week baseline against a normal-week post period) without noticing, which quietly invalidates the number.
• Reporting only the mean when the underlying metric is skewed; a senior candidate volunteers that percentiles or the median might tell a different story.
• Manufacturing false precision under pressure, inventing a decimal you don't actually remember, instead of stating an honest range.

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.