Senior Technical Product Manager Interview Preparation Guide - Lyft

Direct answer

A full rewrite wins when the legacy system's structure fights every incremental change so hard that the accumulated cost of working around it, in time, in bugs, in the parts of the team's attention it consumes, exceeds a realistic (padded) estimate for building it again from what you now know. What has to go right: the team genuinely understands the system's current behavior well enough to not silently drop requirements, the business can tolerate a real delivery gap, and there's a credible plan for the parts of the estimate that are hardest to predict, data migration and the long tail of edge cases nobody remembers exist until they break in production.

Structured elaboration

The risks a rewrite introduces that incremental work avoids:

• The estimate is a guess dressed as a plan. You cannot fully know what a legacy system does until you've read every path through it, and if you could do that cheaply, you probably wouldn't need a rewrite. Rewrites reliably underestimate the "long tail," the 20% of behavior that's undocumented, weird, and only matters for edge cases, because that's exactly the part that's hardest to discover in advance.
• All-or-nothing delivery. An incremental effort can stop, ship partial value, and reassess. A rewrite typically can't ship real value until most of it is done, which means the business is exposed to the full cost of the effort before seeing any of the benefit, and a rewrite that stalls at 80% delivers zero value for the investment made.
• Data migration risk concentrates at the end. Incremental approaches migrate data piece by piece, catching problems early on a small blast radius. A rewrite often defers data migration to a single cutover at the very end, which is exactly when the team has the least remaining slack to absorb a surprise.

The risks incremental work introduces that a rewrite avoids:

• Running two systems for longer than planned, with the ongoing cost and the risk of the migration simply never finishing.
• The seam itself becoming a source of bugs, translation errors at the boundary between old and new that a from-scratch rewrite wouldn't have to deal with.
• Slower overall delivery of the target end state, since incremental work is deliberately paced to be safe rather than fast.

Concrete mitigations for the rewrite risks: build characterization tests against the legacy system's actual behavior before writing a line of the replacement, so the estimate is grounded in observed behavior rather than assumed behavior; plan the data migration and cutover as a first-class, staged piece of the project rather than a final step; and set an internal checkpoint (not a public commitment) partway through where the team honestly reassesses whether the estimate is holding, with permission to fall back to a hybrid approach if it isn't.

Worked example

A retrospective example: a team decided a legacy inventory system's coupling to a proprietary rules engine made incremental extraction impractical, so they chose a rewrite. What made it work: they spent the first month purely on characterization testing against the legacy system, capturing behavior for every product category and edge case they could enumerate, before writing any new code. That testing surfaced a rounding rule for one product category that looked like a bug but turned out to be a deliberate accommodation for a regulatory requirement in one region, exactly the kind of hidden logic a rewrite risks silently dropping. Because they'd captured it in a test before starting, the new system preserved it correctly, and the team could point to a passing test suite, not just confidence, when they cut over.

An architectural decision that limited scale, brought up in the same retrospective: the original system had used a single shared table for all regions' inventory data, which made the regulatory rounding rule and a dozen similar region-specific rules invisible in the schema and discoverable only by reading application code path by path. The rewrite's replacement schema made region-specific rules an explicit, first-class concept, directly because the team had been burned by how hard the old shape made those rules to find.

Trade-offs and pitfalls

The single biggest risk-reducer for a rewrite is treating "we understand the current behavior" as a deliverable to prove, via characterization tests against real behavior, rather than an assumption to proceed on. Teams that skip this step and start writing new code based on what they believe the system does, rather than what it's actually observed to do, are the ones whose rewrites silently change behavior and discover it in production months later.

Direct answer
Functional requirements state what a system must DO; non-functional requirements state how well it must do it, and both need to be explicit for a public API because engineers will otherwise make an implicit, unreviewed choice about the non-functional side.

Structured elaboration
Four functional examples for a public REST API:

1. Clients can create a resource via a POST request and receive the created object with a generated identifier.
2. Clients can retrieve a paginated list of resources filtered by a query parameter.
3. Clients can authenticate using an API key passed in a request header.
4. Clients receive a structured error response with a machine-readable error code when a request is invalid.

Four non-functional examples for the same API:

1. Latency: 95th-percentile response time under a stated threshold (e.g., 200 milliseconds) for read endpoints.
2. Availability: a stated uptime target (e.g., 99.9% monthly) for the public-facing endpoint.
3. Rate limiting: a defined maximum request rate per API key, with a documented behavior on exceeding it.
4. Backward compatibility: no breaking changes to a response schema without a new API version.

Worked example
Taking the latency non-functional requirement: the SLI (service-level indicator) is the 95th-percentile response time for a read endpoint, measured at the API gateway. The acceptance test validates it by running a load test at the expected production traffic pattern (not an idle-system benchmark, which would understate real latency) and confirming the measured 95th-percentile falls under the stated threshold across a sustained test window, not just a single request.

Trade-offs and pitfalls
The most common mistake is writing non-functional requirements as vague aspirations ("the API should be fast and reliable") instead of measurable targets, which makes them impossible to verify or hold anyone accountable to. The second common mistake is over-specifying non-functional requirements with no basis in actual user need (an arbitrarily strict latency target that costs significant engineering effort for no real benefit), which is why every non-functional requirement should trace back to a reason a real user or business outcome needs it.

Overview (role lens)
As a TPM I balance developer experience with predictable revenue. Pricing/commercial levers should lower friction for evaluation while preventing free-riding and enabling clear upgrade paths.

Freemium quotas & sandbox limits

• Offer generous, well-documented free quotas that cover PoCs (e.g., 10k calls/month or 5k compute-minutes) so devs can build end-to-end prototypes.
• Sandbox isolates production-only features (webhooks, guaranteed SLAs) and enforces throttles to prevent production use under free tier.

Trial durations

• Time-based trials (14–30 days) for full-feature trials work best when paired with usage credits; extend trials based on engagement signals (active API calls, team invites).

Rate limit tiers

• Expose clear rate tiers (eg. 60/min, 600/min) and show throttling behavior in docs/console. Soft limits with warning webhooks encourage upgrade before hard blocks.

Price transparency & overage behavior

• Publish per-unit prices and common bill examples. Use permissive overage: auto-bill modest overages with caps plus notifications; allow immediate self-serve upgrade to avoid disrupted workflows.

Bundling & packaging

• Bundle metered credits, team seats, and essential integrations in entry Enterprise packages. Offer pay-as-you-go for early-stage users and volume discounts + committed contracts for enterprises.

Encourage self-service while protecting revenue

• Progressive gating: free → paid PAYG → committed Enterprise. Use metered thresholds to trigger proactive outreach (sales + technical onboarding) before revenue risk. Instrument funnels and A/B test quotas, trial lengths, and overage caps to find optimal conversion vs. abuse trade-offs.

Direct answer

A vanity metric is one that tends to go up regardless of whether the product is actually getting better, while an actionable metric changes in response to something the team did and, when it moves, tells you clearly what to do next. The distinction matters because a metric can look impressive on a slide and still be useless for making a decision.

Structured elaboration

Vanity metrics are usually cumulative totals or simple counts that grow mechanically over time or scale with unrelated factors like marketing spend or app-store visibility: total downloads, total registered accounts, or total page views are the classic examples, because each one mostly reflects how much traffic arrived rather than whether that traffic found value. Actionable metrics are typically rates, ratios, or cohort-based measures that isolate a specific behavior change: conversion rate, day-7 retention, or the completion rate of a specific onboarding step are actionable because a team can point to a change they made and check whether the metric moved in response.

The practical test is to ask, for a given metric, "if this number went up 10% next week, would I know what to do about it, and would I trust that the change reflected something real about the product rather than just more raw traffic." A metric that fails that test belongs on a slide, not on a decision-making dashboard.

Worked example

For a consumer mobile app, "total app downloads this month" is a vanity metric: it can rise purely because a marketing campaign or a seasonal app-store feature drove more installs, with zero information about whether those new users found any value, and there is no specific action a product team can take in response to the number alone beyond "spend more on acquisition," which is a marketing lever, not a product one. By contrast, "percent of new installs that complete the core first action within 24 hours" is actionable: if that rate drops after a release, the team has a specific, testable hypothesis (something in the new-user flow broke or got harder) and a specific lever to pull (revert or fix the flow, then watch the rate recover), and the metric is normalized to new installs rather than a raw count, so it is not conflated with acquisition volume.

Trade-offs and pitfalls

A metric is not intrinsically vanity or actionable forever; total downloads becomes actionable if the team's current job is specifically to grow top-of-funnel awareness and nothing else is changing about the product, so the classification depends on what decision the metric is meant to support, not on the metric's name alone. The bigger pitfall in practice is reporting a vanity metric alongside actionable ones without labeling the difference, since a rising vanity number sitting next to a flat or declining actionable one can make a genuinely stalled product look like it is improving.

Direct answer

I track a mix of leading indicators I can observe soon and lagging outcome indicators that take months, and I treat any single outcome metric with real suspicion, because most of the obvious ones have confounders that have nothing to do with the mentoring itself. If it isn't working, the signal usually shows up in behavior long before it ever shows up in an outcome number.

Leading indicators (fast, but softer)

• The mentee proactively brings a problem before being asked, rather than only responding when prompted.
• They apply a technique from an earlier conversation without being reminded.
• They can articulate their own reasoning, not just repeat a conclusion.
• They start contributing to others, a strong late signal that something has actually been internalized rather than just followed along with.

Lagging indicators, and why they alone are not enough

Promotion, retention, and performance rating movement all matter, but none of them are clean measures of mentoring on their own. Promotion timing is affected by team budget, level-bar changes, and reviewer variance, not just capability growth. Retention is affected by pay, personal circumstances, and the direct manager relationship, often far more than by a mentoring relationship. Treating either as a dashboard number risks giving mentoring false credit when someone would have succeeded anyway, or false blame when the real cause was entirely outside the relationship. That's the reason to pair outcome numbers with direct, harder-to-fake behavioral signals rather than reporting them alone.

Telling it isn't working, and what to do

Signs it's not working: no observable change in independence over a reasonable window, the mentee still routes every decision through you, flat or disengaged body language in 1:1s, or the mentee saying directly that it isn't useful. Once suspected: ask directly rather than only inferring from behavior, check for a format mismatch (wrong cadence, wrong topics, or the mentee not feeling safe raising what's actually going on), adjust before assuming failure, and if the mismatch is genuinely personal rather than fixable, consider a different pairing without treating that as anyone's fault.

Worked example

After several weeks, a mentee was still checking in before making small, reversible decisions that should have been theirs to make. Rather than assuming a skill gap, a direct conversation surfaced that the actual blocker was fear of being wrong, not lack of ability. The adjustment was explicit permission to make a defined class of reversible decisions without approval, plus a standing offer to review the reasoning after the fact rather than before. Over the following sessions, they started making more of those calls on their own and explaining the reasoning unprompted.

Trade-offs and pitfalls

A junior answer to this question is usually a list of KPIs and stops there. A stronger answer explains why the obvious outcome metrics can lie, and pairs them with behavioral signals that are harder to fake. A common pitfall is over-attributing outcome metrics to the mentoring relationship (selection bias: motivated people who get assigned strong mentors were often already on a good trajectory). Another is waiting too long to check in because outcome metrics take a quarter or more to move, by which point a struggling relationship may have already quietly failed.

Direct answer

Turn "handle spikes" into numbers by asking for the spike multiplier over baseline, its duration and arrival shape, the peak concurrency it implies, and what is allowed to degrade versus what must stay within the service-level agreement (SLA) during it. Those four answers are what actually let you size autoscaling, connection pools, and a degradation plan; without them, "handle spikes" is a feeling, not a requirement.

Structured elaboration

The four questions that make it measurable

The general skill, applied to a different vague ask

The same discipline works on any vague requirement, not just traffic spikes. "Handle a fifteen-year-old legacy system with no APIs" is exactly as unmeasurable until you ask the analogous questions: what data-access surfaces actually exist (direct database reads, nightly file exports, screen automation), who owns changes to that system, what staleness is tolerable in whatever gets extracted, and what happens to your system if that legacy system goes down for a day. "No APIs" becomes a concrete integration contract the same way "handle spikes" becomes a concrete capacity contract, by naming the constraint that changes the design instead of accepting the vague label.

Worked example: turning "5x for ten minutes" into a server count

Assume measured baseline steady-state traffic of 1,000 requests per second (RPS), and product says the spike is "5x for about ten minutes." Assume each server instance safely handles 200 RPS at target latency:

$$\text{baseline servers} = \frac{1{,}000}{200} = 5$$ $$\text{spike RPS} = 5 \times 1{,}000 = 5{,}000$$ $$\text{spike servers needed} = \frac{5{,}000}{200} = 25$$

Now check whether autoscaling can even react in time. Assume it takes 3 minutes from scale-out trigger to a new instance serving traffic:

$$\text{spike duration (10 min)} > \text{scale-out reaction time (3 min)}$$

Autoscaling alone is workable here, with roughly 3 minutes of degraded capacity at the start of the spike. If the same 5x spike instead lasted 60 seconds (a flash-crowd shape rather than a sustained one), the 3-minute scale-out reaction time would exceed the entire spike duration, and the only real fix is pre-warmed standby capacity, not faster autoscaling. That is why duration and arrival shape change the design, not just the multiplier.

Trade-offs & pitfalls

• Pitfall: designing for "handle any spike" instead of a bounded one. Every system has a ceiling; the point of these questions is choosing it deliberately instead of discovering it during an incident.
• Pitfall: assuming autoscaling reaction time is negligible. If it is not faster than the spike itself, pre-provisioned headroom is needed, which costs money sitting idle.
• Graceful degradation (returning cached or partial results, shedding low-priority requests) is usually cheaper than provisioning for the absolute peak, but only if product has said which features are allowed to degrade.

Plain exponential backoff (double the delay after each failed attempt) reduces load on a struggling dependency over time, but it has a hidden flaw: if many clients failed at roughly the same moment (which is exactly what happens when the dependency itself goes down), they all compute the same delay sequence and retry in lockstep, so the "backoff" just delays the same synchronized spike instead of spreading it out. Jitter fixes that by randomizing the delay so clients that failed together don't retry together.

Jitter strategies compared

Worked example: how much jitter actually reduces the spike

Pin a concrete scenario: 1000 clients failed at the same moment, base delay = 1 second, and this is their 3rd retry attempt (attempt = 3), so the backoff cap is:

$$\text{cap} = 1\text{s} \times 2^3 = 8\text{ seconds}$$

Without jitter: every one of the 1000 clients computes the identical 8-second delay and retries at exactly the same instant, a spike of 1000 concurrent requests hitting the dependency in one moment, right as it may just be starting to recover.

With full jitter, each client independently draws a delay uniformly from $[0, 8]$ seconds. Dividing that 8-second window into 100 ms buckets gives $8000 / 100 = 80$ buckets, and under a uniform distribution the expected number of clients landing in any single bucket is:

$$\frac{1000}{80} = 12.5 \text{ requests per 100ms bucket}$$

That's a peak-to-average reduction factor of $1000 / 12.5 = 80\times$ under this modeling assumption (uniform, independent draws), turning one instantaneous spike of 1000 into a smooth trickle of roughly 12-13 requests every 100 ms across the full 8-second window, which a recovering dependency can absorb where a single 1000-request spike would knock it back down.

Why retries shouldn't make recovery worse

Jitter alone doesn't prevent the retry storm from getting worse over time if attempts aren't capped: a client that keeps failing and keeps retrying at $\text{base} \times 2^{\text{attempt}}$ forever will eventually be sending requests at a cap so large it's functionally giving up, or, worse, if the cap is bounded, converges back to a steady drumbeat of load that never lets the dependency fully recover. The fix is a hard cap on both the maximum delay and the maximum number of attempts, plus honoring any explicit signal the server provides (a Retry-After header or a 429/503 status) as authoritative over the client's own backoff schedule, since the server is in the best position to know its own recovery state.

Trade-offs and pitfalls

Full jitter maximizes spread but means some unlucky clients draw a near-zero delay and retry almost immediately, which is fine in aggregate (that's still only ~12-13 requests per 100ms bucket in the example above) but means full jitter alone doesn't guarantee a minimum backoff for any individual client; equal jitter trades some of that spread for a guaranteed floor, useful when even a small number of near-instant retries is unacceptable. A pitfall specific to mobile or otherwise unreliable-network clients: retries are only safe to jitter and reattempt if the underlying operation is idempotent (repeating it produces the same end result as doing it once, so a duplicate attempt is harmless), a non-idempotent submit (a payment, an order) retried after a client-side timeout can double-execute if the server had actually processed the first attempt and just failed to deliver the response, so the fix belongs on the server (idempotency keys deduping identical requests) not just in the client's backoff logic, jitter reduces load, it does not make an unsafe retry safe.

Overview (role perspective)
As a Technical Product Manager I propose a two-track API deprecation policy balancing predictable lifecycle management with an accelerated emergency path when business risk mandates faster removal.

Normal deprecation timeline (recommended)

• Deprecation announced: Day 0
• Dual-support period: 90 days (old + new)
• Final removal: Day 180
• Post-removal grace logs: 30 days

Accelerated/urgent path

• Trigger: security, legal, or critical business need + executive approval.
• Timeline options: Emergency (7 days) or Fast (30 days) based on risk level.
• Requirements: mitigation plan, roll-back window, account-by-account impact assessment.

Communication & automation

• Channels: Developer portal deprecation page, automated emails to registered app owners, in-SDK runtime warnings, API response headers (Deprecation, Sunset), integration with status page.
• Automation: API gateway injects deprecation headers, daily reports of active callers, staged webhook notifications to owners.

Incentives & migration support

• Migration tooling (migration guides, client library updates, sample scripts) and temporary free credits or engineering migration hours for high-value customers.
• Migration scorecard and dedicated Slack channel / SRE/DR support for top 20% impacted accounts.

Impact mitigation

• Offer temporary compatibility proxy for high-risk customers, extended paid support, and optional staggered shutoffs per account. Provide clear rollback path and post-mortem.

Example - fast deprecation scenario
We discover a data-exposure bug in v1 GET /users that requires removal in 7 days. I’d trigger emergency path: notify via email + portal + SDK warning immediately, enable gateway-level block for unsafe fields while keeping read-only endpoint for safe fields, offer target customers a migration script and two dedicated engineering sprints (free) to update integrations, and schedule a one-week rollback window if major regressions surface. This minimizes business risk while protecting developer trust.

Direct answer
I'll use Amazon's "Customer Obsession" as the example: in plain terms it means starting from the customer's actual experience and working backward to the decision, rather than starting from what's easiest or cheapest for the team and working forward to how it will land on the customer. In day-to-day work that shows up as a specific, repeatable habit: before finalizing a decision, explicitly write down what the customer will experience as a result, not just what the team will ship.

Structured elaboration

1. State the value in plain language first, in one or two sentences, before layering on any nuance. A stated value is only useful if you can restate it without jargon; if you can't, you probably don't understand it well enough to apply it.
2. Trace two or three concrete decisions the value would actually change, not just decisions it would be compatible with. The test is not "does this decision fit the value" (almost any reasonable decision can be described as fitting almost any value after the fact); the test is "would I have decided differently without this value in mind."
3. Be specific about the mechanism, not just the outcome. It's not enough to say "I'd focus on the customer"; describe the actual practice (writing the customer-facing consequence down explicitly, reviewing a metric that measures customer impact rather than only internal effort, asking a specific question in a design review) that operationalizes the value day to day.
4. Acknowledge the value has a cost or a trade-off, because a value with no real cost usually is not being taken seriously. A genuinely operative value changes what you'd otherwise have done, which means it sometimes means doing the harder or slower thing.
5. Connect it back to your own role specifically, since the same value plays out differently for different functions; the mechanism for a backend engineer, a designer, and an analyst are all different concrete practices in service of the same underlying value.

Worked example
Say you're building a dashboard intended to help a seller reduce order defects. A team NOT applying customer obsession as a working discipline might ship the dashboard once the underlying data pipeline is stable and the metrics are technically correct, treating "the data is right" as the finish line. Applying the value changes the finish line: before shipping, you'd sit with two or three actual sellers using an early version and ask what decision they're trying to make when they open it, which might surface that they need same-day defect data to catch a bad batch before it ships further, not a metric that's accurate but a day stale. The concrete decision that changes: you invest in a same-day data refresh even though it's more engineering effort than the weekly batch job you'd planned, because the customer's real decision-making need, not the easier technical path, is what determines what "done" means. The cost is real (more pipeline complexity, tighter SLAs to maintain) which is exactly why it's evidence the value is actually operative rather than decorative.

Trade-offs & pitfalls
The most common failure is reciting the value's definition fluently and then giving an example so generic it would apply to any company with any stated value ("I always think about the user"), which demonstrates you've read the careers page rather than that you understand the mechanism. A second pitfall is picking an example where the value cost nothing: if every example you give was also simply the obviously correct engineering or business call regardless of the stated value, you haven't actually shown the value did any independent work in your reasoning. A third is over-indexing on one company's specific phrasing so heavily that the answer would sound out of place at any other employer; the goal is to show you can genuinely reason from a stated principle to a concrete decision, a transferable skill, not that you've memorized one company's vocabulary.

Direct answer

As an engineering manager evaluating this design, the useful lens is: each caching layer trades cost, staleness, and operational complexity for latency, and the invalidation strategy and eviction policy paired with each layer follow directly from how far it sits from the origin and how quickly its data changes. Client-side and edge/content delivery network (CDN) caching are cheap and fast but coarse-grained; a reverse proxy and an in-memory service cache give finer control at the cost of infrastructure to run; a persistent caching tier and the database itself are the fallback of record. Getting this right is less about picking the "best" layer and more about not making every layer behave the same way.

Caching layers

Two terms in the table are worth spelling out plainly, since this question is aimed partly at a Technical Product Manager audience: an ETag is a version tag the client can check to see if its cached copy is still fresh, and a surrogate key is a label attached to cached content so many different URLs sharing that label can be purged together in one call, instead of purging URL by URL.

The persistent caching tier is worth calling out as distinct from the in-memory service cache above it: an in-memory cache is fast but starts empty after every restart or deploy, which means a deploy can itself cause a temporary spike in origin load as the cache refills. A persistent tier (a disk-backed cache, or an in-memory cache configured to snapshot and reload) avoids that cold-start cost at the price of slightly higher latency than pure in-memory and some added operational surface to manage.

Invalidation strategies

• Time-to-live (TTL): the cache entry simply expires after a fixed window. Simplest to reason about, and appropriate when some staleness is acceptable.
• Cache-aside (lazy loading): the application checks the cache first; on a miss, it reads from the database and writes the result into the cache. The most common pattern, since it only caches what's actually requested.
• Write-through: the cache is updated synchronously as part of every write, so reads are always consistent with the cache, at the cost of added write latency.
• Write-back: the write lands in the cache first and is flushed to the database later. This is faster for writes but risks data loss if the cache fails before the flush happens, so it needs a durability plan (like a write-ahead log) before it's safe to use.

Choose based on the consistency requirement of the data: user-facing counts and prices tolerate a short TTL; anything where "stale" means "wrong in a way a user or auditor would flag" needs write-through or event-driven invalidation instead.

Eviction policies

• LRU: a safe default, evicts whatever hasn't been used recently.
• LFU: better when a stable set of items stays hot over time, since it protects popular-but-recently-quiet items that LRU would wrongly evict.
• TTL-based / FIFO (first-in first-out): simple and predictable, useful less for memory pressure and more for enforcing a maximum staleness window.

Trade-offs and pitfalls

The recurring failure mode across teams is not choosing a bad individual layer, it's applying one policy uniformly across data with very different consistency needs, which either under-caches fast-moving data (wasting the performance benefit) or over-caches slow-moving data as if it were volatile (adding unneeded invalidation complexity). The second common gap is skipping the persistent tier and treating the in-memory cache as if it always stays warm, which understates the load spike a deploy or restart actually produces on the origin.