Lyft Technical Product Manager (Staff Level) Interview Preparation Guide

Direct answer

A personal dispute is different from a technical disagreement in one important way: there usually isn't a single correct outcome to mediate toward, so your job shifts from finding the right answer to restoring enough working trust that the two people can collaborate again. That starts with hearing each side separately before you ever put them in a room together.

Structured elaboration

• Notice the signal, not just the complaint. Friction often shows up first as missed handoffs, curt messages, or one person routing around the other, before anyone names it as a conflict.
• Talk to each person separately first. Understand each person's version and what they actually need, without either performing for the other.
• Look for the operational root, not just the personality clash. What reads as a personality conflict is often an unclear boundary (who owns what), an old unresolved incident, or an unequal workload, and naming that concretely helps more than asking people to just get along.
• Bring them together with a narrow, concrete goal. Not "resolve your differences," but agree on a specific working agreement for the specific deliverable at risk.
• Follow up privately with each person. A one-time joint meeting rarely fixes an interpersonal pattern, check in again afterward.

Worked example

Two engineers on my team stopped talking to each other directly, routing requests through Slack messages to me or a third teammate instead, and code review turnaround between the two of them had slowed to the point it was putting a release at risk. I noticed it in standup, where one kept mentioning being blocked on the other's review, and confirmed it by looking at the review queue myself. I talked to each of them separately: one felt their work was being nitpicked more harshly than everyone else's on the team, the other felt they were being asked to approve risky changes without enough time to review them properly. Neither issue was really about the other person, one was about review standards feeling inconsistent, the other was about review time not being protected. I set up a joint conversation focused narrowly on one question: what does a fair review turnaround agreement look like for this release. We agreed on a same-day review target for smaller changes and a shared checklist so "thorough" meant the same thing for both of them. I checked in with each of them separately over the following weeks rather than assuming one meeting had fixed it.

Trade-offs and pitfalls

Rushing straight to a joint meeting before you understand each side separately can turn the meeting into the first time either person hears the other's actual grievance, which usually makes things worse, not better. Framing the fix purely as a process change, like a review agreement, can paper over a genuine interpersonal rupture if there's real hurt underneath, so don't mistake a good process fix for the relationship actually being repaired. And if what you're hearing crosses into something like harassment or a protected-category concern rather than a garden-variety personality or working-style clash, that's no longer something to mediate yourself, it goes to HR (human resources) or your own manager.

Direct answer
Coaching a genuine underperformer starts with diagnosing why (skill gap, unclear expectations, motivation, or something outside work like a health or personal issue) before assuming it's a will problem, then moving to a private, honest conversation with specific examples, a written and time-bound improvement plan with objective checkpoints, and a clear, stated understanding of what happens if the bar still isn't met. The hard part isn't the first conversation, it's staying honest and consistent through every checkpoint after it.

Structured elaboration

Diagnose before you coach

Below-the-bar performance has different root causes that call for different responses:

• Skill gap: they don't yet know how to do the thing. Response: targeted teaching, pairing, smaller scoped tasks.
• Unclear expectations: they don't know what "good" looks like here. Response: make the bar explicit and concrete, with examples.
• Motivation or engagement: they can do it but aren't. Response: a more direct conversation about what's changed and why.
• Something outside work: a health issue, a personal crisis, burnout. A private, non-judgmental check-in on wellbeing belongs early in this process, both because it's the right thing to do and because it changes what the right intervention is (support and possibly a formal accommodation, not a performance plan).

Getting this wrong (coaching a skill gap like it's a motivation problem, or the reverse) wastes the improvement window on the wrong intervention.

The conversation and the plan

• Deliver the message privately, plainly, and with specific examples: what's below the bar, what the bar actually is, and why it matters.
• Put the plan in writing: two or three concrete, observable goals, a defined timeframe, and what evidence would count as "met."
• Set a regular check-in cadence shorter than your normal 1:1 rhythm; below-the-bar performance needs tighter feedback loops, not the same cadence as everyone else.

When to involve HR formally

This is a judgment call many candidates get wrong by either never mentioning HR (naive) or looping HR in immediately (overcautious, and it can undermine trust). A reasonable line: loop in HR or your manager as soon as the conversation could plausibly lead to a formal employment outcome (a documented warning, or separation), even if you're optimistic it won't get there, because that's exactly when documentation and process need to be right from the start rather than reconstructed after the fact.

Protecting the team

The rest of the team usually already knows something is off; silence reads as either denial or unfairness. Without disclosing private performance details, it's reasonable to acknowledge you're aware of the gap and are addressing it, and to be transparent about redistributing work if needed, so the team doesn't quietly conclude the issue is being ignored.

Worked example

Situation

An engineer on a team I was supporting had been reliably strong for over a year, then their output quality and delivery reliability dropped off sharply over a couple of months: reviews were taking longer, deadlines were slipping, and the pattern didn't match a normal bad sprint.

Diagnosis

Before assuming a motivation problem, I had a private, low-pressure conversation focused on checking in rather than accusing. That surfaced that part of the issue was a skill gap on a newer part of the codebase they'd been assigned to without much ramp-up, but there was also something going on outside work affecting their focus.

Action

We set a short, explicit improvement plan: two concrete, observable goals tied to real upcoming work, a shorter check-in cadence, and pairing time on the unfamiliar codebase area. I also made sure they knew about the option to talk to HR about support resources for the personal situation, kept separate from the performance conversation so the two didn't get conflated.

Result

Performance recovered within the plan's window once the skill gap closed and the external situation stabilized. Because the conversation started from genuine diagnosis rather than an assumption, the plan addressed the actual cause instead of just adding pressure, and the person stayed on the team and rebuilt trust with the group.

The other branch (when it doesn't turn around)

Not every case ends this way. When someone doesn't meet a documented plan's criteria despite real support, the path is a harder, well-documented conversation, formal HR involvement, and eventually separation if there's no path forward. The mentor's job at that point shifts from "close the gap" to making sure the process is fair, well-documented, and handled with dignity, and to being honest with the rest of the team (without violating privacy) that a change is coming so it doesn't land as a surprise.

Trade-offs & pitfalls

• Treating every case as a motivation problem. The single biggest junior mistake here is skipping diagnosis and going straight to "try harder" messaging, which fails skill-gap and external-cause cases and can be actively harmful if there's something like burnout or a health issue underneath.
• Involving HR too late (or too early). Too late, and you've lost the documentation trail that protects everyone, including the underperformer, if it does become formal. Too early or too visibly, and it can read as punitive before the person's had a real chance, damaging trust unnecessarily.
• Optimizing for the individual at the team's expense, or the reverse. A senior answer holds both: real support for the person, and honesty with the team about workload and timeline impact, rather than pretending nothing's happening.
• No exit criteria stated up front. A plan without a clear "what does not-met look like, and what happens then" isn't actually a plan, it's a delay, and it's unfair to the person because they don't know what they're actually being measured against.

Direct answer

For consent and privacy-sensitive fields, favor explicit invalidation and versioned keys over a passive time-to-live (TTL), and treat a long TTL as a direct legal-risk decision, not just a performance tuning knob, because a stale consent state can mean processing data the user has explicitly withdrawn permission for.

Structured elaboration

• TTL alone is insufficient: a TTL bounds staleness but does not guarantee it; a user withdrawing consent expects that to take effect promptly, and "eventually, within the TTL window" is not a defensible position if that window is, say, an hour.
• Explicit purge on consent change: a consent withdrawal should trigger immediate, explicit invalidation of the cached consent state (and ideally, propagate to every system that reads it), rather than relying on the next natural TTL expiry.
• Versioned keys: bump a version on consent change so any cached read of the OLD version becomes unreachable immediately, avoiding a race where a slow, in-flight read repopulates the cache with the just-withdrawn consent state after the invalidation (the same race pattern seen elsewhere in this topic, here with legal consequences instead of just a UX inconvenience).
• Event-driven invalidation for regulatory correctness: propagate consent changes as events to every downstream consumer that might have cached consent state, since a consent decision often needs to be honored by multiple systems (advertising, analytics, data processing pipelines), not just the primary service.
• Recommended design minimizing legal risk while balancing latency and cost: a short TTL (as a safety-net backstop, not the primary mechanism) combined with event-driven, explicit invalidation on any consent change gives near-immediate correctness for the common case while still self-healing if an invalidation event is somehow lost, rather than choosing one mechanism alone.

Worked example

A user withdraws marketing-communications consent; an event fires immediately, invalidating their cached consent state across every consuming service (the marketing service, an analytics pipeline, a personalization engine) within roughly the propagation latency of the event system (typically well under a second), rather than each of those systems independently waiting out its own TTL (which, if inconsistently configured across systems, could mean some honor the withdrawal in seconds and others in minutes).

Trade-offs and pitfalls

Treating regulatory correctness as "just another caching performance trade-off" and choosing a TTL purely for latency/cost reasons is a serious mistake; involve legal/compliance stakeholders in defining the acceptable staleness window for consent data, do not decide it unilaterally as an engineering optimization. Relying purely on event-driven invalidation with no TTL backstop reintroduces the risk that a lost event produces unbounded (rather than bounded) staleness, which is a worse regulatory posture than a short, explicit TTL ceiling.

Direct answer. Statelessness means every request must carry everything the server needs to process it: authentication, the resource being addressed, any filters or pagination position. The server is not allowed to remember what this client was doing between one request and the next. It is allowed to hold state about a resource (a row in a database), just not state about a specific client's conversation.

What it forbids, concretely. The classic violation is a login session: request 1 authenticates and the server stores "this session id is now logged in as user 42" in server memory; request 2 arrives with only the session id and the server looks up who that is from its own memory. That is exactly the per-client conversational state statelessness prohibits, because it means request 2 can only be served correctly by the specific server instance that handled request 1.

Two techniques that avoid it.

1. Signed, self-contained tokens (e.g. a JSON Web Token, JWT). The client presents a token on every request; the server verifies its signature and reads the user identity and permissions directly out of the token, with no server-side lookup of who this session is. Any server instance can validate any request with only its own signing key, which is what makes statelessness pay off: you can add or remove instances freely.
2. A session id backed by a shared, external store (for example Redis). The server still looks up session data, but the data lives outside any one instance's memory, so any instance can serve any request by querying the shared store. This is a middle ground: it is stateless from the server instance's point of view, even though state still exists somewhere.

What you get, and what you give up, when traffic spikes. With true statelessness (technique 1), you can add ten more instances behind a load balancer during a spike and route any incoming request to any of them, with zero coordination needed between instances, and you can kill an unhealthy instance immediately without worrying about losing anyone's conversation. What you give up: revocation is harder (a signed token is valid until it expires; you cannot instantly invalidate one without an extra deny-list mechanism), and the token itself grows with however much identity or permission data it carries, adding a small amount of bytes to every single request.

Trade-offs and pitfalls. Teams often reach for the shared-store approach (technique 2) because it feels like a smaller change from an in-memory session, but it quietly reintroduces a single dependency every request now needs, and if that store is slow or down, every request is affected, which is a different failure mode than the server that happened to hold your session being down.

I would forecast marketplace health by merchant quality, not just merchant count. A campaign can add supply and still hurt the market if the new merchants have low volume, poor prep performance, or create long delivery distances.

Leading indicators I would monitor in the first few weeks

• Activation rate, meaning merchants that actually go live
• Menu completeness and orderability hours
• First-order conversion and reorder rate by new merchant cohort
• Prep time, cancellation rate, and order defect rate
• Courier wait time and delivery distance for orders from the new cohort
• Average order value and item mix, since very low basket sizes can hurt economics

How I spot the wrong mix early
If new merchants go live but few receive orders, or if they receive orders only through heavy discounts, that is a bad sign. If prep times rise, couriers wait longer, or the new cohort skews toward very low-volume, far-flung stores, the campaign may be adding noise instead of useful supply.

Worked example
If 100 new merchants are onboarded and only 30 get an order in two weeks, while their prep time is 4 minutes slower than the existing baseline, I would question the campaign quality before waiting six months.

I would use cohort tracking, not just city averages, because the average can hide a weak merchant mix.

Direct answer

Contribution margin per user (what each user leaves after the costs that scale with that user) falls by $0.30 per month, from $8.50 to $8.20. The feature adds $0.20 of revenue per user but $0.50 of hosting cost per user, so each user is $0.30 worse off. On unit economics alone (profit per customer, before any retention or sales effect) it is not justified. It would only be justified if it measurably improves retention or conversion enough to offset that loss, which unit economics alone cannot show.

Terms used here: ARPU is average revenue per user per month. Gross margin is (revenue minus the cost of serving that revenue) divided by revenue. Contribution margin per user is revenue per user minus all the variable costs that scale with each user (hosting, payment fees, support per user). Here the 85% gross margin is the only variable-cost information given, so I treat the cost of serving as the whole variable cost and treat the new hosting cost as an addition to it.

The calculation (per user, per month)

The same answer falls out of the incremental view: change = +$0.20 revenue - $0.50 cost = -$0.30. The incremental view is the one to say out loud, because it ignores everything that does not change.

What would make it justified

Three ways to close the $0.30 gap, in the order I would test them:

1. Cut the cost. The hosting add-on needs to be at most $0.20 per user (equal to the revenue it brings) just to break even on margin.
2. Raise what it earns. The ARPU lift needs to be at least $0.50 per user (so $10.50), meaning the feature should carry a price or upgrade rate about 2.5 times what is assumed ($0.50 / $0.20).
3. Show it retains users. Margin per user per month is only half of lifetime value. As an illustration, suppose monthly churn (share of users who cancel in a month) is 2%. Simple lifetime contribution is margin / churn: $8.50 / 0.02 = $425. With the feature, $8.20 / churn must reach $425, so churn must fall to $8.20 / $425 = 1.93%. That is a relative cut of 3.5% in churn (2.00% to 1.93%). The 2% is an assumption of mine, not a given. The conclusion to carry is the shape: a small retention gain can pay for a small margin loss, and the break-even churn is cheap to compute for any real churn rate.

Pitfalls and judgement

• Who pays the hosting cost? If $0.50 is spread over all users but only 20% adopt the feature and carry the $0.20 uplift, the per-adopter economics are far worse. Confirm whether both numbers are per user across the same base (blended) or per adopter.
• Fixed vs variable. Hosting that scales per user is variable and belongs here. A one-off build cost is not part of per-user contribution margin; it belongs in a separate payback calculation.
• Strategic features. A feature can be justified on retention, win rate against competitors or enabling a higher tier. I would say that explicitly, and then ask for an experiment (holdout: a comparable group of users who do not get the feature) to measure the retention and conversion effect instead of assuming it.
• My recommendation: do not ship it at the current cost and price. Go back with a cheaper implementation (cached or batched hosting) or a priced add-on, and ship only if a holdout shows the retention lift. What would change my call: evidence that churn falls by roughly 3.5% or more (at the illustrative 2% base), or hosting cost below $0.20 per user.

Direct answer

I would split cross-team investment calls by size and reach, give each tier one named decider (one person, never a pair), require a one-page proposal with a few fixed pieces of evidence, and close each decision for the quarter unless defined triggers are hit. Enforcement comes from tying the decision to capacity in the plan: once funded, the people are booked and cannot be quietly reassigned, and the decision is logged where the planning meeting starts from.

Decision rights model

A person-week is one person working full time for one week, so 8 person-weeks is, for instance, two people for four weeks. Thresholds below are illustrative; calibrate to your company.

Every call gets two measures: its size (total person-weeks across all teams) and its reach (how many teams other than the proposer must give up people's time). Each measure maps to a tier, and the call takes the higher of the two tiers, so no case falls between rows.

Traced cases:

• 8 person-weeks, needs two other teams: size tier 2, reach tier 3, so tier 3.
• 5 person-weeks, needs one other team: size tier 2, reach tier 2, so tier 2.
• 3 person-weeks, one team only: tier 1 on both measures, so tier 1.

The chair is the senior leader who owns the shared outcome, such as the head of engineering. Product, infrastructure and data science each contribute but do not vote.

Evidence required in every proposal

1. The problem and the metric it should move (for example, 95th-percentile response time, the time that 95 out of 100 requests beat, which shows how slow the slow end is; or a revenue target) with the current value.
2. Cost in person-weeks per team, and the other work displaced.
3. At least two alternatives, including "do nothing".
4. The dependency: which team must do what, by when.
5. What would make the proposer withdraw it.

Trigger rule: if the cost exceeds the tier limit, it moves up a tier automatically.

A worked proposal: product proposes a real-time recommendations API. Product's own work is 2 person-weeks, infrastructure needs 5 and data science needs 3. Total size is 2 + 5 + 3 = 10 person-weeks, which is size tier 2. Two other teams are involved, which is reach tier 3. The higher is tier 3, so the council decides. If product split it into three proposals of 2, 5 and 3, each would look like tier 1 or 2 on size alone, but related proposals are summed (10 again), and the reach is still two other teams, so it still goes to the council.

Enforcing it once made

• Decision log with owner, date, rationale and the capacity committed, reviewed at the start of each planning session.
• Capacity is booked in each team's plan, meaning the named people's time is reserved against the decision, so reassigning it is a visible tradeoff the manager must raise.
• Reopen rule: a decision can be reopened only if a named trigger occurs: the estimate rises by more than one third (a decision funded at 6 person-weeks reopens only if the estimate passes 8), or a stated assumption proves false. Otherwise it is closed until the next quarter. Illustrative threshold.
• Visible consequences: when a team breaks a decision, the chair raises it at the next council with the log.

Rolling the process change out across ten teams

Pilot with two or three teams for one planning cycle, then widen. Success measures: decisions reopened without a trigger (target: none), days from proposal to decision, and planning-meeting hours. Expand in waves, for example 3 teams, then 6, then all 10, with a retrospective between waves.

Trade-offs

• Thresholds in person-weeks are easy to game by splitting work; require the sum of related proposals to count.
• A council that meets quarterly is slow for urgent items, so permit the chair to decide an urgent item within 3 business days.
• What would change my call: if most disputes are about priorities and not capacity, I would fix the shared goals first.

Situation & goal
I’d balance urgent customer commitments with progress on the platform refactor so we don’t lose revenue or momentum toward long-term scalability and velocity.

90‑day roadmap (tactical)

• Triage: categorize work into P0 (blocker/security), P1 (sales commitments), P2 (nice-to-have).
• Protect a fixed “sprint tax” (20–30% capacity) for refactor/platform enablers.
• Deliverables: all P0/P1 shipped within SLA; 2–3 small, high‑value refactor stories (API contracts, shared libs) that reduce future friction.
• Quick wins: automated regression tests, CI improvements, and a small modularization pilot.

12‑month roadmap (strategic)

• Quarter-by-quarter ramp of platform work: Q1–Q2 stabilize & modularize, Q3 abstract core services, Q4 deliver platform APIs and migration paths.
• Define migration milestones and measurable outcomes (reduced lead time, fewer regressions, X% improvement in deploy frequency).
• Maintain a backlog of customer fixes and a fast-path process for critical sales requests.

Trade‑offs

• Short term: slower feature velocity for new functionality due to capacity tax.
• Long term: reduces maintenance cost, faster onboarding, and improved SLA compliance.

Stakeholder communication

• Weekly status for engineering; biweekly business reviews with clear RAG, impact on revenue, and migration timelines.
• Publish a public roadmap with “what’s protected” vs “what’s opportunistic.”

Securing engineering capacity

• Negotiate a committed capacity percentage with Eng Manager and Leadership tied to KPIs.
• Propose a temporary hire/contractor to handle surge customer fixes or shift some support to Customer Success for nontechnical patches.
• Use measurable milestones (OKRs) to keep platform work funded and visible.

This plan balances immediate obligations while making deliberate, measurable progress toward the platform vision.

Direct answer

Before sketching anything, I separate three questions: who is this for and what must it do (functional scope), what quality bar does it have to hit (non-functional requirements like scale, latency, and compliance), and what am I explicitly choosing to leave out for this iteration. I get there by asking a short list of targeted questions, writing down the assumptions I have to make when answers aren't available yet, and drawing an explicit line between what ships now and what's deferred, instead of letting scope grow implicitly as the conversation continues.

Structured elaboration

A repeatable order of operations

1. Clarify the primary user and the one core job the service must do for them.
2. Ask about scale and growth (expected load today, expected growth rate, read-versus-write ratio), because these numbers, not taste, determine how much architecture is actually warranted.
3. Ask about non-negotiable constraints: compliance obligations, systems it must integrate with, budget, deadline.
4. Ask what's allowed to degrade: is a few seconds of staleness acceptable, is brief downtime during a deploy acceptable, does every read need to be exact.
5. State assumptions explicitly wherever a real answer isn't available yet, and mark them as assumptions to validate, not facts to build on silently.
6. Draw the scope line: list primary use cases that must ship, and secondary or deferred use cases that are explicitly out of scope for this iteration, written down so nobody discovers the gap later.

The judgment underneath the checklist
A senior candidate treats every "yes, and also" as a scope decision with a cost, not a free addition, and pushes back on a vague ask like "make it fast" by translating it into a testable target before designing a single component, which is the same move a strong answer makes when a client says a product must "feel fast" for users worldwide.

Worked example

Take the one-line prompt "design a URL shortener." Before sketching components, I'd ask: how many new links are created per day, and what's the read (redirect) to write (creation) ratio? Suppose the answer is 10,000 new links/day with a 100:1 read-to-write ratio, typical of a link-sharing product:

$\text{redirects/day} = 10{,}000 \times 100 = 1{,}000{,}000$

$\text{avg redirect RPS (requests per second)} = \frac{1{,}000{,}000}{86{,}400} \approx 11.6 \text{ req/s}$

That single clarifying question, the read-to-write ratio, turned a vague prompt into a concrete, low-single-digit-RPS system, which tells me this is a read-heavy, cache-friendly problem, not a write-scaling problem, before a single box has been drawn. If the interviewer instead says the product is a bulk-import tool with a roughly 1:1 read-to-write ratio, the answer to nearly every later design question changes, which is the point: the clarifying question, not the diagram, is where the real design decision happens.

Scope line for this example: in scope for a first version is create-and-redirect with a randomly generated short code. Explicitly out of scope for the first version, stated to the interviewer rather than silently dropped, are custom vanity aliases, click analytics, and link expiration, each a real feature with its own cost that can be added once the core path is validated.

Trade-offs & pitfalls

• Designing before scoping: sketching a box diagram before knowing the read-to-write ratio, scale, or constraints wastes limited interview time on a shape that may not fit the real problem.
• Silently assuming numbers instead of stating them, so a listener can't tell you're reasoning from an assumption rather than a fact.
• Treating scope-cutting as a failure rather than a design decision; a strong candidate narrates what they are choosing not to build and why, instead of trying to design everything at once.
• Requirements-gathering theater: asking a long, generic checklist of questions instead of the two or three that would actually change the design.

Direct answer

The error {"error": "invalid request"} with a 400 tells the developer that they are wrong but not what, where or how to fix it. A good error names the field, says what was expected, gives a stable machine-readable code, carries a request ID for support, and links to help. The safe way to do this is to build errors from a controlled catalogue of messages you wrote, never from raw exception text (the internal error message your code throws, which can reveal how your system is built).

Critique

• Tautology. "Invalid request" restates the 400. No new information.
• No location. Which field or header? Maybe the JSON did not even parse.
• No cause or fix. What was wrong and what is valid?
• No machine-readable code, so client code cannot branch on the failure without string-matching the message.
• No request ID, so support cannot find the log line, which forces a ticket.
• No documentation link.

Rewrite

{
  "error": {
    "code": "invalid_parameter",
    "message": "amount_cents must be an integer of at least 1. Received the string \"25.00\".",
    "param": "amount_cents",
    "request_id": "req_8f3a2c",
    "doc_url": "https://docs.example.com/errors/invalid_parameter"
  }
}

The response also carries Content-Type: application/json (or application/problem+json, the media type of RFC 9457 "Problem Details for HTTP APIs", if you follow that standard; a media type is the label in the Content-Type header that says what format the body is in, and an RFC is a numbered internet standards document). For several problems at once, return an array of {param, code, message} items so the developer fixes everything in one pass rather than one round trip per mistake.

Keeping errors from leaking sensitive detail

1. Catalogue, not exceptions. Map each failure class to a code and a message a person wrote. A catalogue is just a lookup table kept in your code, for example:

invalid_parameter  ->  "{param} must be {rule}."
not_found          ->  "No such resource."
rate_limited       ->  "Too many requests. Retry after {n} seconds."

The code picks the row and fills in only safe values such as the field name. Anything not in the table becomes a generic internal_error plus the request ID. Never pass an exception's text to the client: it can contain SQL, file paths, hostnames or stack traces (the listing of internal code locations printed when a program crashes).
2. Log the detail server-side under the request_id. The developer gets the ID, support gets the internals.
3. Do not echo secrets. If the invalid value could be a token or password, name the field but do not repeat the value. Truncate long echoed input.
4. Avoid enumeration (letting an attacker learn what exists by trying guesses and reading the differences in your answers). Do not say "no account with that email" versus "wrong password" on login; return the same message. Return 404 for another tenant's resource rather than 403, so existence is not confirmed. A tenant is one customer account in a system shared by many. If customer A requests /invoices/1042 and it belongs to customer B, a 403 Forbidden tells A that invoice 1042 exists (just not for them), so A can probe IDs and map B's data. A 404 Not Found is the same answer A would get for an ID that never existed, so nothing leaks.
5. Keep validation messages about the caller's own input, never about internal structure ("column customers.tax_id is null").
6. Test it. Send malformed and hostile inputs in CI and assert responses never contain a stack trace, file path or internal hostname. CI (continuous integration) is the automated test run on every code change.

Pitfalls

• Messages helpful to attackers ("SQL syntax error near...").
• Changing messages breaks clients that parse them: that is why the code, not the message, is the stable part.