Senior Technical Product Manager Interview Preparation Guide - Lyft

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. Cache-Control tells any cache (browser, CDN, shared proxy) how long a response can be reused and who is allowed to store it; ETag and Last-Modified let a client ask "has this actually changed since I last saw it" so the server can answer with an empty 304 instead of resending the whole body; Vary tells a cache that the SAME URL can have different valid responses depending on a request header (like Accept-Language), so it must not serve one client's cached copy to another.

The header exchange.

Cache miss (first request):

GET /products/42 HTTP/1.1

HTTP/1.1 200 OK
Cache-Control: public, max-age=60
ETag: "a1b2c3"
Last-Modified: Tue, 28 Jul 2026 09:00:00 GMT

The client (or an intermediate cache) stores the body along with the ETag and remembers it is fresh for 60 seconds.

Within 60 seconds: the cache serves its stored copy directly, no request to the origin at all; this is the fast path and the entire point of Cache-Control.

After 60 seconds (cache hit, revalidation):

GET /products/42 HTTP/1.1
If-None-Match: "a1b2c3"
If-Modified-Since: Tue, 28 Jul 2026 09:00:00 GMT

HTTP/1.1 304 Not Modified
Cache-Control: public, max-age=60
Last-Modified: Tue, 28 Jul 2026 09:00:00 GMT

Most real APIs send both validators together, as shown above: ETag for a precise, byte-level check and Last-Modified as a coarser, human-readable fallback for a cache that only understands the older mechanism. Per the HTTP caching spec, when a client sends both If-None-Match and If-Modified-Since, the server MUST evaluate If-None-Match first and ignore If-Modified-Since once that comparison already resolves the request, since ETag is the more precise of the two.

The resource has not actually changed, so the server sends only a status line and fresh Cache-Control, no body at all. This is meaningfully cheaper than a full 200 response when the underlying resource changes rarely relative to how often it is read.

After 60 seconds (cache miss, resource actually changed):

GET /products/42 HTTP/1.1
If-None-Match: "a1b2c3"
If-Modified-Since: Tue, 28 Jul 2026 09:00:00 GMT

HTTP/1.1 200 OK
Cache-Control: public, max-age=60
ETag: "d4e5f6"
Last-Modified: Tue, 28 Jul 2026 09:30:00 GMT

A new ETag means the client discards its stale copy and stores the fresh one.

When to reach for stale-while-revalidate instead of a hard max-age. Cache-Control: max-age=60, stale-while-revalidate=600 tells the cache: serve the stale copy IMMEDIATELY if it is within 600 seconds of going stale, while fetching a fresh copy in the background for the NEXT request. Use this for content where a few extra seconds of staleness is invisible to the user but a slow, blocking round-trip to the origin on every 61st-second request is not (a product listing page, a news feed), as opposed to a hard max-age where you genuinely need every request past the TTL to wait for a fresh answer (an inventory count you cannot afford to show as stale even briefly).

Trade-offs and pitfalls. Vary is easy to forget and expensive to get wrong in both directions: omit it when you actually vary by a header, and a shared cache serves the wrong locale's or wrong content-negotiated response to the wrong client; add it for a header that never actually changes the response, and you needlessly fragment your cache into many near-identical copies that each individually cache-miss more often.

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

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
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.

Direct answer. I would pursue a narrow wedge first (an initial foothold: one workload where the platform is clearly better), build the differentiators that compound with usage, and fund few bets. "Default" means developers choose it without comparing alternatives; you earn that by being best for a specific job first, then widening.

Use the Playing to Win cascade (Lafley and Martin). Their five choices are: winning aspiration, where to play, how to win, capabilities, and management systems. Applied here:

• Winning aspiration: be the default ML inference layer (running trained models to serve predictions in production).
• Where to play and how to win: the markets and differentiators below.
• Capabilities (what we must be excellent at): a fast, cost-efficient serving runtime, and developer tooling that makes deployment trivial.
• Management systems (how we track and steer): one owner per bet, a quarterly review of a few metrics (time to first deployment, cost per request, share of new projects), and a rule that a bet missing its targets two quarters running is re-scoped or cut.

Markets first. Pick segments with painful, frequent inference needs and short buying cycles. Example (illustrative): startups shipping AI features that need low latency and predictable cost, before regulated enterprises with long security reviews. Sequence: wedge segment, then adjacent teams in the same companies, then enterprise.

Real differentiators (not claims anyone can copy):

• Developer experience: deploy a model in minutes with sane defaults.
• Cost and performance per request, backed by published, repeatable benchmarks (standard tests of speed and cost anyone can rerun).
• Reliability and observability (monitoring and debugging in production) that make it safe to depend on.
• Ecosystem pull: integrations with the frameworks and model formats (the file types trained models are saved in) people already use, so switching in is easy.

Few bets to fund (three, not eight): (1) the fastest path from model to endpoint (the web address an app calls to get predictions); (2) cost-efficiency work in the serving layer; (3) the integrations that feed adoption. Illustrative sizing: with 30 engineers, three teams of about 12, 10 and 8 is workable, while eight bets would leave under four engineers each (30 / 8 = 3.75), too few to ship anything. Explicitly decline custom training, a model marketplace and bespoke enterprise consulting for now.

Biggest risk. The category commoditizes (offerings become interchangeable and compete on price): large cloud providers (hyperscalers) bundle comparable inference into their existing plans at low margin. Mitigation: win on developer workflow and switching cost (the pain a customer faces moving away, created here by tooling and integrations), and watch signals with targets. Illustrative: usage per customer growing about 10% quarter over quarter, and the share of new projects in the wedge segment started on us rising from 5% to 20% within a year.

What would flip the plan. If wedge customers churn to bundled offerings at renewal, move toward enterprise reliability and governance.

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:

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:

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.

Context & goals
Enable continuous delivery for many backend teams and third-party clients while preventing consumer breakage, minimizing release friction, and making governance lightweight and measurable.

Policy overview

• Enforce semantic versioning for APIs/schemas (MAJOR.MINOR.PATCH). MAJOR for breaking changes.
• Central Schema Registry (e.g., Confluent Schema Registry / Apicurio / AWS Glue) as source-of-truth for Avro/JSON Schema/Protobuf.
• Consumer-Driven Contracts (CDC) using Pact or Postman contract tests stored in a Contract Broker.
• Automated breaking-change detection in CI via compatibility checks against registry and CDC verification.
• CI/CD gating: automated checks → integration/staging deployment → contract verification → Canary + feature flag rollout.
• Escalation: automated rejection of breaking changes unless exception approved via a lightweight RFC & change window; emergency path with rollback runbooks.

Tools & processes

• Schema Registry + Git-backed schema repo with PR policy and signed commits.
• Pact Broker + consumer/provider pipelines that publish/verif reports.
• CI plugins: pact-verifier, registry-compatibility-checker, automated contract matrix.
• Release orchestration: Jenkins/GitHub Actions/Spinnaker with policy-as-code (OPA) gating.
• Observability: contract verification dashboards, consumer test coverage, runtime telemetry (api-usage, error rates).

Compliance & metrics

• Gate pass rates (% of PRs passing compatibility checks)
• Contract coverage (% consumers with CDC tests)
• Time-to-detect breaking change (mean time)
• Number of escalations & emergency rollbacks
• Consumer error rate post-release
  Automate reporting into weekly governance dashboard; enforce SLA targets (e.g., 95% pass rate, <1% post-release consumer errors).

Why this works
Balances developer autonomy with safety: automated, early feedback via CDC and registry checks prevents most breakage; policy-as-code and clear exception paths keep governance light and auditable—suitable for a Technical PM to champion and operationalize.

Situation: I joined a team that was skeptical of cross-functional partners because they had experienced a lot of noisy requests and little follow-through.

Task: I needed to earn credibility quickly without pretending I was technical owner of the work.

Action:

• In my first weeks, I listened more than I spoke and asked engineers what wasted their time.
• I came prepared to meetings with context, not opinions.
• When I made a promise, I followed through the same day or explained the delay early.
• I made sure decisions were written down so no one had to re-litigate them.

Result: The team started engaging more because they saw I was reducing friction rather than adding it. A good sign was that engineers began bringing me risks earlier and asking for help before issues became urgent.

What told me trust was building was not praise. It was behavior change: they attended meetings more consistently, challenged ideas directly, and used me as a partner instead of seeing me as another layer of process.

Direct answer

SLI, SLO, and SLA are three layers of the same idea, stated with increasing weight. An SLI (service level indicator) is what you actually measure. An SLO (service level objective) is the internal target you set for that measurement. An SLA (service level agreement) is the external promise, usually contractual, built on top of that target, with consequences if you miss it. In plain terms: the SLI is the speedometer, the SLO is the speed limit you've set for yourself, and the SLA is the speed limit you've promised a customer you won't exceed, with a penalty if you do.

Picking the example and the threshold

• Choose one measurable thing the executive already cares about, not an internal engineering metric they have no context for. "Percent of requests that succeed" beats a raw latency percentile for this audience, because success or failure needs no further explanation.
• State the SLO as a number deliberately below what looks achievable. This is the part executives most often misread: an SLO of 99.9% isn't "we're at 100% and slipping a little," it's a chosen buffer that leaves room to ship changes and absorb normal failures without over-investing in reliability nobody needs.
• The SLA number sits below the SLO, with a consequence attached, and that gap is itself worth explaining: it exists so that missing the internal target doesn't automatically mean breaking a customer promise.
• The same three-layer structure holds outside web services too, whether you're onboarding a new product manager on a team's SLOs for the first time or defining an SLI/SLO for a streaming data pipeline (there the SLI might be how stale the data is, instead of whether a request succeeded), the relationship between the three layers doesn't change, only what's being measured does.

Worked example

Say the team sets it up this way for a checkout API. SLI: percent of checkout requests that return successfully within two seconds. SLO: 99.9% of checkout requests meet that bar, measured over a rolling 30 days, the number engineering is held to internally. SLA: 99.5% of checkout requests meet that bar, measured monthly, written into the enterprise customer contract; falling below it triggers a service credit specified in the contract.

Business consequence of missing the SLA (say the month comes in at 99.3%): this is a contractual breach. The customer is owed the agreed credit, and depending on the contract, may have grounds to escalate or walk away. It's a direct, quantifiable cost and a trust hit that shows up outside engineering entirely.

Business consequence of exceeding the SLO (say the month comes in at 99.97% against a 99.9% target): this isn't a "consequence" in the SLA sense, it's a signal. Consistently beating the SLO by a wide margin means either the target is stale and could absorb more risk (ship faster, take on more ambitious changes), or the team is over-investing effort in reliability the product doesn't need. Either way it's a prompt to revisit the number, not something to report as a win on its own.

Trade-offs and pitfalls

The most common executive misunderstanding is treating the SLO as the promise, when the SLA is the promise and the SLO is the internal cushion above it. Say that gap out loud every time, or the SLO number will get quoted externally by mistake. The second pitfall is picking a metric that's technically correct but means nothing to the audience, an uptime percentage without saying what "down" costs the business, always translate the metric into what the customer actually experiences before attaching a number to it.