Senior Backend Engineer Interview Preparation Guide - Lyft

Direct answer: "Most impactful" is a claim about scale, reach, or durability of a change, not automatically the project with the single biggest percentage. Come with a short comparison across two or three candidate projects on a common yardstick (people affected, durability of the fix, or how core the process was), and be ready to justify why that yardstick and not just report a number.

A framework for ranking impact across projects

When you don't have hard numbers

• Use proxy metrics: adoption rate, ticket volume, "still in use N months later," or direct stakeholder feedback.
• State explicitly that it's a proxy, not a causal measurement, rather than dressing it up as a precise result.
• Reach and durability are often easier to state honestly than a precise causal percentage, and they're still a legitimate basis for "most impactful."

Worked example (illustrative, arithmetic shown)

Two candidate projects: Project A fixed a rare edge-case bug, reducing its error rate from an estimated 3% to under 1% on the narrow path it affected. Project B rebuilt the new-user onboarding flow that every signup passes through; its effect on conversion wasn't cleanly isolated, but it has been in production for 12 months and the product runs roughly 2,000 signups a month. Reach comparison: Project B touches 2,000 x 12 = 24,000 users over that period, versus Project A's narrow edge case affecting a small estimated fraction of a much smaller baseline. Project B is presented as "most impactful" on reach and durability grounds, even though Project A has the cleaner percentage, and that trade-off is named explicitly rather than hidden.

Trade-offs and pitfalls

• Picking the project with the single biggest reported percentage without checking how narrow its scope was is a common overclaim.
• Confusing "impactful to me personally" with "impactful to the business" weakens the answer under questioning.
• Presenting a proxy metric as if it were a measured causal result erodes credibility once challenged.
• Failing to acknowledge a plausible rival project when asked invites doubt about the whole answer.

Direct answer: Graceful degradation means a system keeps serving its core value under partial failure by deliberately shedding non-essential features, instead of failing completely because one dependency is unhealthy. It matters because most real outages are partial, not total, and a system that can't distinguish "checkout is down" from "product recommendations are down" ends up treating both the same way: total outage, when only one of them actually deserved it.

Structured elaboration

The core discipline is ranking features by how essential they are to the user's actual goal, then deciding in advance what happens to each tier when its supporting dependency fails:

How you decide what's "core": ask whether the feature is on the path the user came for. For a checkout service, that's the cart-to-payment path; product recommendations, reviews, and "recently viewed" are enrichment around that path, valuable but not why the user is there. For a search service, returning some relevant results is core; typo-correction, personalized re-ranking, and query autocomplete are enrichment that can be dropped without breaking the user's ability to search.

Detecting when to degrade: this has to be automatic, not something a human decides mid-incident. Health checks and latency/error-rate thresholds on each dependency feed a circuit breaker; when the breaker for the recommendations service opens, the front end (or an API gateway) simply omits that section rather than waiting on a call that's failing. The degraded state should be visible in monitoring (a "degraded mode" flag, not silence) so the team knows it's active and can address root cause.

Trade-offs & pitfalls

• Degrading too aggressively removes revenue-generating features (recommendations often drive real conversion) for failures that didn't actually require it; the tiering has to be based on actual dependency health, not a blanket "anything non-core gets cut."
• Degrading too conservatively (waiting too long, or requiring a human to flip a switch) means the cascading failure the degradation was supposed to prevent happens anyway, because by the time a human reacts, the core path is already backed up.
• Static thresholds don't generalize across traffic levels; a latency threshold tuned for average traffic can either never trigger during a real incident at peak load, or trigger too eagerly during a routine traffic spike that isn't actually a failure.
• Testing degraded paths is easy to skip because they're rarely exercised in normal operation; without deliberately forcing dependencies to fail in staging (or via chaos testing in production), the first real test of the degraded path is during an actual incident, which is the worst time to discover it's broken.
• The same tiering logic applies outside typical web services: an ML-serving system facing a slow or unavailable model can fall back to a cached prior response, swap to a smaller/cheaper model that's faster but less accurate, or return a safe default decision, the exact same "protect the core interaction, shed the enrichment" reasoning, just with "model quality" instead of "page richness" as the thing being traded off.

Direct answer

A strong answer names the specific sources used (not "I looked at the website"), what those sources revealed about the business and its current priorities, and at least one signal a surface skim would miss, ideally including how the company sizes up against a competitor.

The framework

1. Layer your sources. Primary: the careers page, the product itself (used firsthand where possible), recent public posts (engineering blog, press, investor updates for public companies). Secondary: employee reviews, LinkedIn org and team changes, industry press. Comparative: at least one competitor, so you can speak to positioning, not just isolated facts.
2. Extract signal, not just facts. A fact is "they raised a new funding round" or "they have several hundred employees." Signal is what that implies: are they scaling a specific function, pivoting a product line, entering a new market. Interviewers can tell the difference between reciting facts and drawing a conclusion from them.
3. Compile it into something usable in the room: a short mental brief or 2-3 talking points, plus one smart question that only makes sense if you did the research, referencing something specific you noticed rather than a generic "what's your growth strategy."
4. Use it twice: once to explain your interest with specifics, once to ask an informed question near the end of the conversation.

Worked example

I used [company]'s product directly the way a customer would, read their [engineering blog / recent press / public roadmap], and checked how they compare to [a competitor or category of competitors] on [a specific dimension]. What stood out: [one signal, e.g. "they'd recently shipped a feature closing a usability gap I'd noticed myself, which told me the team is actively closing gaps rather than only adding scope"]. That's what I'd ask about given the chance: [a specific, research-grounded question].

(Domain swap: an Information Security Analyst might compare public incident-disclosure practices against a competitor; a Data Analyst might compare a company's public data-maturity signals, like a published data blog, against a peer.)

Trade-offs and pitfalls

• Reciting facts without a conclusion ("you were founded a decade ago and have several offices") reads as an encyclopedia entry, not research.
• Over-researching into information that isn't public or verifiable creates awkward moments; stick to what you can source and be ready to say where it came from.
• Skipping the competitor comparison misses a chance to show you understand the company's actual position, not just its own marketing framing.

I would use caching selectively, with different rules for each data type.

Cache strategy

• Listing metadata: good candidate for cache-aside because it changes relatively infrequently.
• Host profile: also cacheable, usually with a medium TTL.
• Availability summary: cache very cautiously, with a short TTL or event-based invalidation, because stale availability can cause incorrect booking decisions.

Key design
I would build cache keys from stable identifiers and versioning, for example listing ID plus a data version or locale. That helps avoid collisions and makes invalidation safer after edits.

Invalidation

• On listing edits or host profile updates, publish an update event and evict or rewrite the related cache entries.
• On booking or hold creation, invalidate availability immediately or update it atomically.
• For high-risk data, prefer short TTLs plus invalidation instead of long-lived caching.

What I would never cache blindly

• Final booking authorization state
• Inventory counts that must be exact for correctness
• Any response that decides whether a slot is still bookable

For booking flows, I would rather pay a small latency cost than serve stale availability and create double-booking risk. Caching should improve read performance, not weaken correctness.

Direct answer

The second explanation almost never wins by being louder or more detailed than the first. It wins by changing the format, meaning I switch from telling to showing, and by rooting the explanation in a decision the person actually needs to make rather than in the mechanics of the tool itself. To avoid condescension, I treat the first miss as information about my explanation, not about their ability.

Structured elaboration

When a first explanation does not land, I go through a specific adjustment process rather than just repeating myself more slowly:

1. Diagnose what actually did not land, by asking a targeted question rather than re-explaining immediately. Usually the gap is one of three things: the vocabulary I used, the lack of a concrete example, or the fact that I explained the mechanism instead of the decision it enables.
2. Change the format, not just the pace. If the first pass was verbal, the second pass gets a visual or a live walkthrough. If the first pass was abstract, the second pass starts from a specific, real example the person already cares about.
3. Anchor the explanation in a decision they need to make, not in how the underlying system works. People retain "here is what you do when you see X" far better than "here is how X is calculated."
4. Check understanding by having them use it themselves, not by asking if it makes sense. Watching someone operate the thing and narrate their reasoning out loud surfaces exactly where the model in their head diverges from reality.

To avoid condescension, I frame the second attempt as "let me show you a different way to look at this" rather than "let me try explaining this more simply," and I never reference the fact that this is a repeat explanation in front of other people.

Worked example

I owned a dashboard that tracked monthly customer churn, acquisition channel, and cohort value for Product and Customer Success managers, most of whom were not technical. After my first walkthrough, several of them still could not use it to decide which customers to prioritize for retention outreach; they nodded along in the room but did not use it afterward.

For the second attempt, I changed three things. First, storytelling: instead of walking through the chart types, I opened with a real scenario, "we're seeing a spike in churn from one acquisition channel this quarter, here is what that costs us and how we'd catch it," and used the dashboard to answer that story as it unfolded. Second, guided filters: rather than describing the filters, I handed them the dashboard and had each person isolate a cohort and change the date range themselves while I coached, so the tool's behavior stopped being something I described and became something they had just done. Third, annotated visuals: I added in-dashboard annotations next to each chart naming the business question it answers, so the connection between a chart and a decision was visible without me being in the room. Afterward, I gave each person a short realistic scenario and had them talk through, using the dashboard, what they would do, which told me directly whether the explanation had landed rather than relying on their saying it made sense.

Trade-offs and pitfalls

• Switching format on the second attempt costs more preparation time than repeating yourself; it is worth it specifically because a second identical explanation rarely succeeds where the first one failed for the same underlying reason.
• Anchoring purely in decisions can under-explain the tool for a stakeholder who later needs to use it in a situation you did not walk through. If the audience needs durable independence, not just one correct decision, the mechanism has to come back in briefly, just after the decision framing rather than before it.
• The biggest condescension risk is not tone, it is implying the person should have understood the first time. Framing the second pass as offering a different angle, rather than a simpler one, avoids that without softening the actual content.
• Hands-on practice only works if you can tolerate the person making a visible mistake in front of you or others; rushing to correct every misstep undercuts the exact learning-by-doing effect you are relying on.

Direct answer

For a user-owned-content service where a small number of accounts are extremely hot, the base sharding strategy should be simple (shard by owner id so a user's own content lives on one shard, minimizing cross-shard operations for owner-centric reads and writes), and hotspot handling should be a separate, targeted layer on top: detect the hot owners, give them dedicated capacity or split their data across sub-shards, and cache aggressively in front of them so the base sharding scheme doesn't have to be redesigned around a handful of outliers.

Structured elaboration

Base sharding scheme
Shard primarily by owner_id, using consistent hashing with virtual nodes (nodes and keys are placed as points on a circular hash space, the ring, and virtual nodes give each physical node many small points on it instead of one) so a user's content is colocated on one shard. This keeps the common case (read or write a user's own content) single-shard and avoids cross-shard joins or fan-out for the majority of traffic, which is the correctness and performance baseline everything else builds on.

Hot-key mitigation, layered

1. Detection: track per-shard and, where feasible, per-key request rate, CPU, and I/O. An owner whose shard consistently runs hot relative to peers on the same hardware is a hot-key candidate.
2. Dedicated shards: once an owner is confirmed hot, move them to a shard (or set of shards) sized specifically for their load, isolating their traffic from unrelated tenants so their load spikes don't degrade other users.
3. Sub-sharding for extreme cases: for an owner too hot even for a dedicated shard, split that single owner's content across N sub-shards, keyed by hashing (owner_id, content_id) mod N. A small per-owner routing map (only needed for owners flagged as hot) tells the router which sub-shard a given piece of content lives on, so this cost is paid only where it's needed.
4. Caching: for read-heavy hot owners, keep a precomputed or cached view of their content (their public feed, their most-requested posts) in an in-memory cache colocated with their shard, so reads don't have to hit the database at all in the common case. A content delivery network (CDN) or edge cache in front of that absorbs anonymous, public read traffic before it reaches the application tier.
5. Write smoothing: for write bursts (a celebrity posting during a live event), queue or rate-limit writes at the edge so a burst becomes a controlled backlog instead of a shard-saturating spike.

Routing layer
A lightweight router service maps owner_id to shard (or, for hot owners, to a sub-shard set) and caches that mapping with a short time-to-live (TTL), falling back to the consistent-hash computation if the cache misses. This keeps the common path fast while still allowing the exception-case owners to be redirected.

flowchart LR
    C[Client request] --> R[Router: owner_id to shard map]
    R -->|normal owner| S1[Shard via consistent hashing]
    R -->|hot owner| SS[Sub-shard router: owner_id + content_id]
    SS --> S2[Sub-shard 1]
    SS --> S3[Sub-shard 2]
    SS --> S4[Sub-shard N]
    S1 --> Cache[Read-through cache]
    S2 --> Cache
    S3 --> Cache
    S4 --> Cache
    Cache --> Client2[Response]

Rebalancing
Consistent hashing with virtual nodes lets ordinary rebalancing (adding capacity, redistributing normal-load owners) move only a small slice of the ring at a time. Migrating a newly-hot owner to a dedicated shard is a targeted operation: dual-write to the old and new location, backfill the new shard from the old, cut routing over once the backfill catches up, then retire the old copy. This is a small, scoped migration rather than a full resharding of the cluster.

Worked example

Take a platform where a normal owner generates on the order of 50 requests per second (a stated planning assumption, not a measurement) and shards are provisioned for roughly 2,000 requests per second of headroom each, so a shard can comfortably hold dozens of normal owners. A celebrity account goes viral and its request rate rises to 80,000 requests per second, roughly $80{,}000 / 50 = 1{,}600$ times a normal owner's load and $80{,}000 / 2{,}000 = 40$ times a single shard's entire provisioned capacity. Leaving that owner on a shared shard under the base hashing scheme would overload every other owner colocated with them; a dedicated shard alone still exceeds one shard's headroom by 40x. The system detects the spike (per-owner request-rate metric crossing a threshold), migrates the owner to a dedicated set of sub-shards (splitting by content_id across, for example, 40 sub-shards to bring per-sub-shard load back near the normal 2,000 requests/second baseline), and places a read-through cache in front holding their most-requested content so that a large share of the 80,000 requests/second never reaches a database shard at all.

Trade-offs & pitfalls

• Sub-sharding a single owner's data trades away single-shard transactional simplicity for that owner: an operation that needs to see all of that owner's content atomically now has to reason across sub-shards, so keep sub-sharding as a targeted exception, not the default.
• Precomputing and caching a hot owner's feed reduces read cost but adds write-side complexity (every write has to invalidate or update the cache); a hybrid where only confirmed-hot owners get precomputation avoids paying that cost for the long tail of normal users.
• Detecting hotness reactively (after a shard is already degraded) is a common gap; alerting on request-rate trend, not just absolute threshold, catches a viral spike earlier.
• Over-provisioning dedicated shards for every borderline-hot owner "just in case" wastes capacity; reserve dedicated shards and sub-sharding for owners that clear a measured threshold, and let the routing layer's cache absorb moderate hotspots first.

Direct answer. A Cartesian join happens when two tables are combined with no matching condition between them at all, pairing every row of one with every row of the other; here it's caused by the old-style comma-join syntax, where the WHERE clause filters customers on its own but never specifies how orders should relate to customers, so every surviving customer row is paired with every single row in orders.

Structured elaboration. The comma-join syntax (FROM a, b WHERE ...) treats the join condition and the filter condition identically, both just end up in the WHERE clause, which makes it easy to write a WHERE clause that filters one table correctly while forgetting to specify any relationship to the other table at all. The database has no way to distinguish "you forgot the join condition" from "you genuinely want every combination," it just executes exactly what was written, which is why this defect produces a plausible-looking, syntactically valid query that silently returns far too many rows rather than an error.

Worked example. I verified this with a small dataset: two customers in region 5 and two orders (one per customer).

-- accidental Cartesian join: no relationship specified between customers and orders
SELECT c.customer_id, o.order_id
FROM customers c, orders o
WHERE c.region_id = 5;

-- corrected: an explicit join condition ties orders to the customer they belong to
SELECT c.customer_id, o.order_id
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
WHERE c.region_id = 5;

The first form returns four rows (every one of the two region-5 customers paired with every one of the two orders in the table, regardless of which customer actually placed which order); the corrected form returns exactly two rows, each customer paired only with their own order, which is almost always the actually-intended result.

Trade-offs and pitfalls. In production, detect this pattern by watching for a query whose result row count is suspiciously close to (rows in table A) times (rows in table B), especially right after a schema or query change; the most durable prevention is banning the comma-join syntax in code review or via a linter entirely, requiring explicit JOIN ... ON syntax everywhere, since that syntax structurally forces you to state a join condition rather than making it optional and easy to omit by mistake.

Complexity

A genuine Cartesian join costs O(rows in A times rows in B), which is why it's usually catastrophic on any pair of non-trivial tables rather than just mildly wrong.

Edge cases

A DELIBERATE cross join (generating every combination of two small reference sets, for instance) is a legitimate use of the same underlying mechanism; the distinction from a bug is entirely about whether the row-count explosion was intended, which is exactly why an accidental one is dangerous: it looks structurally identical to a correct query someone meant to write.

Direct answer
The strongest mentoring story names a concrete starting point (not "they were new," but what specifically they didn't yet know or couldn't yet do), describes what you actually did differently because of that starting point, and points to a real change in what the person could do independently afterward as the evidence of growth, not just that time passed or that they were nice about it.

Structured elaboration

What "starting from" should actually specify

Vague ("they were junior") is weak. Specific ("they could write correct code but always needed help scoping the actual problem before writing it") is strong, because it sets up a real before and after.

What "what you did" should show

The interesting part isn't a list of activities (pairing, reviews, 1:1s); it's the judgment behind them: why you chose that particular intervention for that particular gap, and what you adjusted when the first approach didn't fully work.

What "how you know they grew" should show

This is the part candidates under-answer. Two things separate a senior answer here:

• Independence as the real signal, not sentiment. The strongest evidence isn't "they thanked me," it's a concrete example of them handling something on their own that they previously couldn't, ideally something you didn't have to prompt.
• Reframing your own impact as leverage, not personal output. A senior candidate can articulate that developing someone else who can now independently do the work is a multiplier on team capacity, arguably more valuable than the same hours spent on your own individual output, because it compounds. That's a different, and stronger, claim than "I helped someone and it felt good."

The real tension: mentoring time vs. delivery

Mentoring genuinely competes with your own delivery time, especially early in a relationship when the payoff hasn't materialized yet. A senior answer is honest about this rather than pretending mentoring is free: it names a moment where mentoring time actually cost something (a deadline got tighter, you did more of the work yourself that cycle) and explains the judgment call for when it's right to deliberately scale mentoring back temporarily to protect a real deadline, versus when protecting the mentoring time is the higher-leverage call even under pressure.

Worked example

Situation

I mentored someone who was technically capable but consistently needed help before they'd start: given an ambiguous problem, they'd wait for someone to scope it into clear steps rather than attempting that themselves.

Action

Instead of continuing to scope tasks for them, I deliberately started handing over problems one level more ambiguous than they were comfortable with, then worked through their proposed scoping with them afterward rather than before, so the struggle happened on their side first. Early on this slowed things down, and I redid some of their scoping myself before it went further, which cost real time on a couple of deadlines.

Result

Over time the gap between their first attempt at scoping and a workable plan narrowed, until they were handling genuinely ambiguous problems without needing that step from me at all. The clearest evidence wasn't a compliment, it was a specific instance of them independently scoping and delivering something ambiguous while I was out, without anyone asking them to check with me first.

The trade-off moment

Partway through, we had a hard deadline where I made a deliberate call to scope their next task myself rather than continuing the hands-off approach, because the team couldn't absorb the risk of a slower first pass that cycle. I was explicit with them about why, so it didn't read as a loss of confidence in them, just a temporary trade-off.

Trade-offs & pitfalls

• Confusing activity with growth. Listing pairing sessions and 1:1s isn't evidence of anything; a senior answer points to a specific, observable change in independent capability.
• Never naming the cost. A story where mentoring never competed with anything else usually isn't a very real story. Naming a moment you scaled it back, and why, is more credible than claiming it was free.
• Missing the leverage framing entirely. Describing mentoring purely as "helping a nice person" misses the stronger claim: that growing someone else's independent capability is a real multiplier on what the team can deliver.

Direct answer

Match the store to the shape of the access pattern and the guarantees the component actually needs, not to whichever store the team already operates: relational for data needing multi-record transactions and ad hoc joins, key-value for simple point lookups by a known key at very low latency, document for semi-structured records usually fetched whole, wide-column for very high write throughput on wide, sparse rows accessed by a known key plus a range, and graph for data whose primary queries traverse relationships across multiple hops rather than filtering on attributes.

Structured elaboration

Guiding factors, in the order a competent decision usually walks through them: what is the dominant query, a lookup, a scan, a join, or a traversal; how many hops does a typical query need to walk, zero or one hop rarely justifies a graph database, several hops usually does; how strict does the transactional guarantee need to be; and what is the actual sustained write rate and row shape, not just the current team's default toolchain.

Worked example

A single e-commerce platform, choosing per component rather than one store for everything:

• Order and payment ledger: relational, because it needs multi-row transactions across order, inventory, and payment state that must all succeed or fail together.
• User session cache: key-value, point lookups by session identifier, no joins, and very low latency is the only real requirement.
• Product catalog: document, records vary by product category and are typically read whole on a product page.
• Clickstream and event ingestion: wide-column, an extremely high write rate queried later by user identifier plus a time range, exactly the access pattern wide-column engines are built for.
• "Customers who bought this also bought" and fraud-ring detection: graph, because the actual query traverses relationships (co-purchase edges, shared payment instruments) several hops deep, which is expensive to express as repeated joins in a relational engine.

Trade-offs & pitfalls

• Defaulting to whichever store the team already runs, then discovering the real query pattern needs relationship traversal or very high wide-row write throughput, and bolting it onto the wrong engine, shows up later as application code re-implementing joins or graph-walks, or a single store buckling under a write pattern it wasn't designed for.
• Choosing a graph database for data with only shallow, one-hop relationships is over-engineering, a foreign key in a relational table is simpler and has better tooling for that case.
• Choosing a wide-column store for workloads that need ad hoc filtering across arbitrary attributes works against its design, wide-column stores are fast specifically because queries are restricted to key plus range, arbitrary attribute filtering is its weakest fit.
• The same logical dataset can legitimately live in more than one store at once, for example a relational system of record with a derived graph or search index kept in sync, when no single store serves every access pattern well, but that adds an explicit synchronization problem that needs an owner, not an assumption that it will stay consistent on its own.

Direct answer. Idempotency means calling an operation N times has the same effect as calling it once. A read (GET) is naturally idempotent: reading a balance ten times does not change it. A state-changing operation matters more: charging a credit card must not happen twice just because the client retried after a timeout. The technique that makes a POST idempotent under retry is a client-supplied idempotency key.

How the key design works. The client generates a unique key (typically a UUID) once, before the first attempt, and sends it in an Idempotency-Key header on every attempt of that logical operation, including retries. The server:

1. On first sight of a key, records that the key is in progress (inside the same transaction or lock that reserves it, to close the race where two near-simultaneous retries both think they are first) and then does the real work.
2. Once the real work completes, stores the result (the exact response body and status code) against that key, not just a "done" marker.
3. On any later request with the same key, does not re-run the work at all: it looks up the stored result and replays it verbatim.
4. If a request with the same key arrives while the first one is still in flight, it returns a distinct signal (commonly 409 Conflict) rather than either re-running the work or blocking indefinitely, since the client should simply wait and retry, not assume the operation failed.

Storage and TTL. Store the key with the resulting resource id, the response body, and response status, keyed uniquely (a unique index on the idempotency key in the same database as the resource, so the check-and-create is atomic). Expire keys after a bounded window, commonly 24 hours, long enough to cover realistic retry storms (a client that gives up on retrying after a few minutes, or a batch job that retries hours later after being paged) without keeping every idempotency key forever.

Read-only example. GET /orders/123 is naturally idempotent: calling it a hundred times in a row just returns the current state, with no design work required, because nothing changes as a side effect of reading.

State-changing example. POST /orders with an Idempotency-Key: retrying after a dropped connection returns the same order id and body as the original successful attempt, instead of creating a second order.

Trade-offs and pitfalls. The single most common mistake is checking whether the key has been seen and creating the resource as two separate, non-atomic steps; a race between two near-simultaneous retries can then both pass the check before either has stored the key, creating two resources anyway. The check-and-reserve step must be atomic (a unique constraint violation on insert is a reliable way to get this for free from the database).