DoorDash Product Designer Interview Preparation Guide - Junior Level

Direct answer
Prop drilling is passing a value through intermediate components that never use it themselves, purely so a deeply nested descendant can read it. The fix is always to shorten the distance between where a value lives and where it's read, and which technique does that best depends on how many components need the value and how often it changes.

Structured elaboration

From a usability angle, the same tree that suffers prop drilling for a callback is often better served by composition (the callback rarely needs to be "global"), while the same tree's theme or locale value is a better fit for context because it genuinely is global and changes rarely.

Worked example
Before, a click handler is drilled through two layers that don't use it:

function Layout({ onSelect }) {
  return <Sidebar onSelect={onSelect} />;
}
function Sidebar({ onSelect }) {
  return <Item onSelect={onSelect} />;
}
function Item({ onSelect }) {
  return <button onClick={onSelect}>Select</button>;
}

After, composition removes the drilling entirely because Layout and Sidebar never needed onSelect in the first place, they only needed to render whatever was handed to them:

function Layout({ children }) {
  return <Sidebar>{children}</Sidebar>;
}
function Sidebar({ children }) {
  return <>{children}</>;
}
// usage: the component that owns onSelect renders Item directly
<Layout>
  <Item onSelect={onSelect} />
</Layout>

Trade-offs & pitfalls
Reaching for Context as the default fix for every instance of prop drilling is a common wrong turn: it solves the syntactic annoyance but can introduce a re-render fan-out if the context value changes often and isn't split by concern. Reaching for a global store for state that's really local to one small subtree hurts colocation and testability, since now a component's behavior depends on an external store's setup rather than its own props. Composition is the cheapest fix but doesn't help with values that genuinely need to be read by many unrelated branches of the tree, that's what context and stores are for.

Brief overview
As a UX Designer I use a checklist to run smooth 45-minute remote-moderated usability tests: prepare tech, participants, consent/recording, contingencies, and privacy safeguards.

Tools (recommended)

• Video + recording: Zoom or Microsoft Teams (cloud recording)
• Screen-share & remote control: Lookback, UserTesting, or Zoom
• Prototype: Figma/Adobe XD with share link
• Scheduling & reminders: Calendly + Google Calendar
• Notes & analysis: Otter.ai (transcripts), Airtable/Notion for session notes

Participant setup (pre-session email)

• Confirm date/time, timezone, and duration (45 min)
• Ask to use a laptop and latest browser; provide test link
• Include quick tech-check steps (camera, mic, internet >10 Mbps)
• Ask to close other apps and use headphones
• Share consent form and study purpose with link to sign before session

Consent & recording

• Begin session by restating purpose, voluntary nature, and recording use
• Obtain verbal consent on-record and note timestamp
• Offer option to pause/stop recording anytime
• Clarify how recordings/transcripts will be used and stored

Contingency plans

• If participant loses connection: try reconnecting for 5 minutes, then reschedule remaining time
• If screen-share fails: ask participant to narrate while you guide via shared prototype link or use remote control
• Backup: phone call + step-by-step verbal test
• Have spare participant(s) or buffer slots in schedule

Data privacy

• Limit recording access to core research team; store in encrypted drives (Google Workspace with 2FA or company S3 with encryption)
• Anonymize transcripts; remove PII before sharing
• Retention policy: state duration (e.g., 12 months) and deletion process
• Ensure vendor tools are GDPR-compliant if applicable

Session logistics (timeline for 45 min)

• 0–5 min: welcome, consent, tech check
• 5–10 min: warm-up/background questions
• 10–35 min: tasks & think-aloud (3–4 tasks)
• 35–42 min: debrief & follow-ups
• 42–45 min: wrap-up, compensation instructions

This checklist ensures reliable sessions, clear consent, resilient contingencies, and protected participant data.

Direct answer

I prepare by making sure my analysis is genuinely solid, not just an opinion dressed up as data, present it as a business trade-off rather than a taste contest, and if the executive still wants to proceed after hearing it, I make the decision and its known risk explicit and shared, then execute it as well as I would execute anything else, rather than relitigating it after the call is made.

Structured elaboration

Preparing for the conversation. I pressure-test my own analysis first: is the research actually relevant to this specific proposal, is the cost estimate realistic rather than inflated to discourage the idea, and what is the strongest version of the executive's case, the one I should address directly rather than a weaker version that is easy to beat. I also try to find out what is actually driving the request, sometimes an executive preference is standing in for a real signal, a customer complaint they heard directly, a competitive concern, worth understanding before I present anything.

Presenting the case. I frame it as a trade-off, not a veto: here is what the data shows, here is the implementation cost, here is what else that cost could buy, rather than telling them the idea is wrong. I bring the data plainly, what the research and analytics actually show, not overstated, and propose a lower-cost alternative if I can find one that addresses the executive's underlying goal, giving them a real option rather than just a rejection.

Handling it if the executive still wants to proceed. I state the decision and the known risk explicitly, and get it in writing where appropriate: "understood, we'll move forward with the overhaul, for the record our research suggests it's unlikely to move the metric in question, and it will take roughly the estimated cost." This is not a defensive move, it keeps the record honest and expectations calibrated rather than silently hoping it turns out fine. Then I execute it as well as I would execute anything I fully believed in, since half-hearted execution of a call I lost produces a worse outcome than either agreeing or successfully pushing back would have.

Worked example

An executive wants to overhaul the product's entire visual style to match a competitor's recent rebrand, believing it looks more modern. Preparing: checking existing usability research and analytics shows no actual friction tied to the current visual style, engagement and satisfaction metrics have been flat to improving over the relevant period, and a cost estimate shows the overhaul would take roughly one quarter of the design and frontend team's capacity given how many screens are involved. Asking around also surfaces that the request was triggered by a specific board comment about the product "looking dated" next to a competitor's demo.

Presenting: "the data doesn't show the current visual style is costing us on engagement or satisfaction. A full overhaul is roughly a quarter of design and frontend capacity, the same capacity that would otherwise go to a specific roadmap item we've committed to. If the board's concern is really about looking current, here's a lower-cost option: a focused refresh of the highest-visibility screens, achievable in about three weeks, that addresses the 'looks dated' impression directly without the full rebuild."

If the executive still wants the full overhaul after hearing this: "understood, we'll proceed with the full overhaul. For the record, our data doesn't show it will move engagement or satisfaction, and it will cost roughly a quarter's capacity against that roadmap item. I'll plan the work now." I then execute the overhaul as carefully as any other project, rather than letting my disagreement show up as reduced effort.

Trade-offs and pitfalls

Presenting the analysis as a way to win the argument, rather than to genuinely inform the decision, reads as combative even when the data is solid. Silently complying without stating the known risk erases the chance for anyone to learn from the outcome later, whichever way it goes. Proposing a lower-cost alternative risks looking like an attempt to talk the executive out of the idea entirely, worth the risk because it is a genuinely useful option to have on the table, without one the only choices left are yes or no. Executing a lost argument half-heartedly produces a worse outcome than either agreeing fully or continuing to push back through the appropriate channel would have.

Direct answer

Don't treat "ship now" versus "delay" as a single yes/no call. Score each flagged inconsistency against a few concrete criteria (how visible or usability-breaking it is, how many places it will get copied into, and what the deadline is actually protecting), let that scoring produce the recommendation, and put the trade-off in writing before the decision is final.

Framework

Score each inconsistency on:

1. Severity and visibility: cosmetic drift (spacing, font-weight) versus something that breaks usability or trust (two different visual treatments for the same action, an ambiguous affordance).
2. Blast radius: how many screens it touches now, and critically, whether it lives in a shared component that other screens will keep copying going forward.
3. Cost of fixing now versus later: fixing a shared component once, at the source, is cheap; fixing it after five more screens have copied the same broken pattern is not. Call this compounding iteration debt.
4. What the deadline protects: a hard external commitment (a marketing date, a contractual delivery) that genuinely cannot move, versus an internally set target with a few days of real slack.

The decision rule that falls out of this: ship now with patches when the flagged issues are cosmetic-only and the deadline is genuinely external and fixed; take a short, scoped delay when an issue is usability-breaking or sits in a shared component that will multiply if shipped as-is.

Worked example

Say a release has 14 flagged inconsistencies. Sorting them: 9 are pure visual drift on secondary screens (spacing, font-weight), low severity and low blast radius, so these become fast-follow tickets shipped after launch. 3 are the same action ("Save") rendered as both a filled button and a plain text link depending on the screen, a usability-breaking inconsistency but isolated to those 3 screens, so they're fixed pre-launch since the change is small. 2 live in a shared button component with inconsistent disabled-state styling that's reused across roughly 30 places in the app; shipping it as-is means the same bug gets copied into every future screen that reuses that component. Fixing it at the source costs a short, scoped delay of a few days; fixing it after the fact means finding and re-patching it everywhere it got copied into. The framework says: patch the 9 after launch, fix the 3 quickly before launch, and take the short delay on the 2 shared-component issues, because the cost asymmetry (fix once now versus fix in 30 places later) is the whole argument.

Stakeholder communication plan

Before the decision is finalized, share a short written note (not just a meeting) that lists the categorized issues, the criteria used, and a specific recommendation, for example: "we're shipping with 9 known cosmetic issues logged as fast-follow tickets, and taking a 3-day delay on the shared button component because fixing it after launch means touching roughly 30 places instead of one." Give stakeholders a real chance to weigh in, with their own short deadline to respond, rather than presenting the decision as already made. Once decided, write it down as a short decision record so it isn't re-litigated later in the release, and publish the fast-follow ticket list so "shipped with known issues" stays visible and tracked instead of quietly forgotten.

Trade-offs and pitfalls

Two failure modes sit on either side of this. Using "ship now, patch later" as a way to permanently avoid a hard conversation about design debt: if the same category of issue slips every release, that isn't a trade-off being made, it's debt being accumulated silently. On the other side, delaying for cosmetic issues that only the design team notices burns trust with stakeholders, who start treating "the designers want more time" as a tax rather than a signal. The reliable heuristic is asymmetric: bias toward shipping visible-but-shallow issues, bias toward a short delay on shared or systemic issues, because those get more expensive, not less, the longer they wait.

Situation & goals (one line)
Design a dasher-facing flow that quickly recovers when they can’t find an address, minimizes delivery delay, protects customer privacy, and triggers support escalation only when needed.

Flow overview (steps & UI)

1. "Can't find address" CTA on order card — prominent red/white button. Tapping opens a modal with: pin-on-map snapshot, customer-first-name only, ETA, and three Quick Actions (large buttons): Call, Message, Navigate.

2. Quick Actions:

• Call: single-tap VoIP with masked number (shows "Call customer — masked") and call timer; log recorded.
• Message: templates dropdown (e.g., "I'm outside building A. Can you confirm entrance?") + editable field; shows estimated expected reply time. Messages go via platform channel; customer phone masked.
• Navigate: opens in-app step-by-step or deep-links to maps with suggested parking/entrance pin.

3. Retry & Resolve: After any action, show two on-screen buttons: "Found — Deliver" and "Still stuck". Selecting "Found" resumes normal flow and records time to resolution.

Escalation thresholds

• Auto-escalate to in-app support after 2 failed attempts or 8 minutes since first action.
• Immediate escalation if dasher selects “Unsafe / No access” or reports locked gate. Escalation modal collects short structured reason and attaches GPS trace + screenshots (opt-in).

Privacy protections

• Show only customer first name and masked phone; all communications routed through platform proxy numbers.
• Customer map pin coarse-grained (50-100m) until dasher initiates contact; when contacting, reveal exact delivery instructions only after customer responds or support approves.
• Audit log and consent: customer notified when dasher requests location clarification; data retention limited.

Design considerations & research notes

• Microcopy reduces friction ("Try messaging — typical reply 2 min").
• Use progressive disclosure to avoid overwhelming the dasher.
• Test with dashers for timing thresholds and A/B test masking granularity vs. resolution time.

Direct answer. Inclusive design sometimes reveals that the actual best solution for everyone differs from the original, non-inclusive starting point, not just an accommodation bolted onto it, because designing for a genuine constraint (a specific disability, a specific situational limitation) often exposes an assumption baked into the original idea that turns out to be unnecessary or actively limiting for the broader population too.

A concrete case study, stated honestly. A settings page originally designed as a dense, single long-scroll list of toggles was being evaluated for screen reader usability; testing revealed that navigating dozens of undifferentiated toggle switches by heading/landmark was genuinely difficult since they had no grouping structure a screen reader user could navigate by. The discovery method was a moderated session with a screen reader user attempting to find and change a specific setting, timed against how long it took, revealing the flat structure meant scanning nearly the whole list serially.

The alternative solution adopted. Rather than simply adding ARIA landmarks to the existing flat structure (the minimal accommodation), the finding prompted grouping the settings into labeled sections with real heading hierarchy, which also turned out to measurably help SIGHTED users complete the same "find and change a specific setting" task faster, since the visual scanning problem (undifferentiated long list) had the same root cause as the screen reader navigation problem, just expressed differently for each population. In the follow-up usability round, median completion time for that task dropped from roughly 40 seconds on the flat list to under 15 seconds on the grouped, headed version for sighted participants, and the screen-reader session that had originally required scanning most of the list serially came down to under 30 seconds once landmarks let the participant jump straight to the right section.

Implementation details. <section aria-labelledby> groups per category (Account, Notifications, Privacy), consistent heading levels, and a persistent in-page "jump to section" navigation for both sighted and screen-reader users, replacing the single flat list entirely rather than patching it with landmarks alone.

Trade-offs and pitfalls. The genuinely honest part of this story is that the initial instinct WAS to just add ARIA landmarks as a minimal accommodation, and it took the actual usability session, not just an accessibility audit checklist, to surface that the deeper structural problem (no grouping at all) was the real issue underlying both the accessibility gap and the general usability complaint that had been separately reported but not yet connected to it.

Direct answer

The difference between an organized summary and an actionable insight is that a summary describes what people said, while an insight explains why it matters and implies what to do about it. Getting there requires a repeatable synthesis process: coding raw transcripts into patterns, clustering those patterns into themes with enough evidence behind them, and converting each theme into a stated insight the team can weigh against other priorities.

Structured elaboration

1. Code before you cluster. Read or skim every transcript and tag statements with short, consistent labels (a pain point, a workaround, a desire, a point of confusion). This is mechanical on purpose: it turns unstructured text into something that can be counted and compared, rather than relying on memory of "what stood out."

2. Cluster codes into themes, and track evidence strength per theme. Group related codes together and note, for each resulting theme, how many separate participants raised it, how severe the impact seemed, and whether any participants explicitly contradicted it. A theme that eighteen of twenty participants raised independently carries more weight than one raised by two.

3. Convert each theme into an insight statement, not a restated observation. "Several users mentioned onboarding was confusing" is a summary. "New users abandon onboarding because they can't tell which step is required versus optional, which the flow does not currently signal" is an insight: it names a specific mechanism, not just a sentiment.

4. Corroborate with quantitative data where it exists, and be honest where it doesn't. Qualitative signals are best at explaining why something happens and surfacing problems nobody thought to measure; quantitative signals are best at showing how often and how much. Pairing them (an insight from interviews checked against a funnel metric) upgrades a theme from "suspected" to "confirmed" and should change how confidently the team acts on it. If no quantitative check is available, say so rather than implying more certainty than the evidence supports.

A lightweight rule for deciding what to run first, for example when support tickets spike: check existing analytics and past research (secondary, quantitative) before commissioning new interviews, since it is faster and may already answer "how big and where." Only run new primary qualitative research once the quantitative picture narrows down what needs explaining.

flowchart LR
    A[Raw transcripts] --> B[Code: tag statements]
    B --> C[Cluster: themes + evidence strength]
    C --> D[Corroborate with quantitative data]
    D --> E[Insight statements]
    E --> F[Prioritized, actionable next steps]

Worked example

A reasonable way to prioritize which insight to act on first, once you have several candidate themes, is a simple scoring formula such as RICE:

Hypothetical inputs for illustration: a theme raised by 18 of 20 interview participants (high reach), judged to meaningfully affect task completion (high impact), corroborated by a funnel metric (high confidence, say a weight of 0.8 on a 0-1 scale versus 0.3 for an uncorroborated theme), and addressable with a moderate-effort change gets a materially higher RICE score than a theme raised by 2 participants with no quantitative backing and a similar effort estimate, since reach, impact, and confidence all multiply together in the numerator while only effort sits in the denominator. This is a prioritization tool applied on top of the synthesis, not a replacement for the judgment used to write the insight statements in the first place; most interviews only need you to demonstrate the synthesis process itself, RICE-style scoring is a depth technique worth mentioning briefly rather than walking through in full.

Trade-offs and pitfalls

The most common failure is stopping at the clustering step and calling a well-organized set of themes "insights," when nothing has actually been converted into a stated mechanism or an implication for the team. A second failure is treating a single vivid quote as representative without checking how many other participants said something similar. A third is over-trusting quantitative corroboration that does not actually measure the same thing the qualitative theme is about, which produces false confidence rather than real triangulation (multiple independent sources of evidence actually agreeing).

Direct answer

Saturation is the point where new interviews stop teaching you anything new: participants keep repeating themes and problems you have already heard instead of surfacing fresh ones. I don't wait for a magic number of sessions; I track how much new material each interview adds and use a stopping rule I can point to (a defined run of interviews with no new material), not a gut feeling.

Structured elaboration

There are two things people mean by "saturation," and it's worth naming both:

• Code saturation (breadth): new interviews stop producing new codes (a short label for a recurring idea or topic in the data, like "confused by pricing tiers"). This tells you when you've heard the range of things that come up.
• Meaning saturation (depth): new interviews stop adding nuance to the themes you already have, even if no brand-new code appears. This tells you when you actually understand the things you've heard, not just that you've heard them.

In practice I keep a simple running log during the interview round: for each interview, how many genuinely new codes did it add? When that count drops to zero for several interviews in a row, that's my signal.

Worked example

Say I planned 12 interviews on "why users abandon the onboarding checklist." My new-codes-per-interview log looks like this:

By interview 9, three interviews in a row (7, 8, 9) added zero new codes. That's my pre-agreed stopping rule met, three interviews early, so I stop at 9 of the planned 12 rather than running the remaining 3 just because they were on the calendar.

To defend that to a stakeholder who wanted more sessions, I don't argue from confidence, I show them the same table. The pitch is concrete: "we budgeted 12 sessions to be safe, but the data told us we hit diminishing returns three sessions early. The last three interviews confirmed what we already knew instead of adding anything new, so the marginal value of sessions 10 to 12 is low relative to their cost in participant incentives and your team's time." If there's a specific known gap (say, one user segment was underrepresented in the 9 completed interviews), I'll spend 1 to 2 of the freed-up sessions closing that gap deliberately rather than banking the savings blind.

Trade-offs & pitfalls

Saturation is a heuristic, not a mathematical proof; a table like this is evidence of diminishing returns, not a guarantee that interview 10 would add nothing. Two pitfalls to watch: declaring saturation from a vague feeling with no log to show for it (indefensible under pushback), and applying saturation logic uniformly across a study with several distinct user segments, since one segment can look saturated while another (recruited later, or smaller) still hasn't shown its full range of themes.

Overview
Deliverable: developer-ready interaction spec for Search Autosuggest component covering states, keyboard, ARIA, timing, selection, mobile responsiveness, and acceptance criteria.

States

• Idle: input empty or blurred, no dropdown visible.
  • Acceptance: no network calls; no list rendered.
• Loading: query in-flight; spinner shown.
  • Acceptance: spinner visible within 150ms of request; loading state cancellable on new input.
• Results: list shown sorted by relevance; highlights for keyboard focus.
  • Acceptance: results render within 300ms of response; first result not auto-selected.
• No-results: single row “No results for ‘…’”.
  • Acceptance: accessible message announced (aria-live="polite").

Keyboard & Selection

• ArrowDown / ArrowUp: moves focus through list (wrap disabled).
• Enter: selects focused item; if none focused and input has exact match, select best match.
• Escape: closes list, returns focus to input.
• Tab: commits focused item if open; otherwise behaves normally.
• Acceptance: every key action updates aria-activedescendant and visually highlights; Enter triggers select handler.

ARIA

• input: role="combobox", aria-autocomplete="list", aria-expanded="true|false", aria-controls="{list-id}", aria-activedescendant="{item-id}".
• list: role="listbox", id="{list-id}".
• item: role="option", id="{item-id}", aria-selected="true|false".
• Live region: aria-live="polite" for no-results and error messages.

Debounce / Throttle

• Debounce input by 200ms (reduces calls while typing).
• Throttle type-ahead network retries to at most 1 request per 150ms when programmatic changes occur.
• Acceptance: network calls only after 200ms idle; rapid typing does not exceed 1 req /150ms.

Selection Behavior

• Selecting populates input, closes list, and emits onSelect(id, label).
• If user clicks outside, closes list and preserves input.
• Acceptance: onSelect called with correct payload; analytics hook fired.

Responsive (Mobile)

• Mobile breakpoint < 600px: full-width dropdown, touch targets ≥44px, virtual keyboard-aware repositioning (dropdown anchored above if keyboard covers).
• Acceptance: touch targets size validated; dropdown remains visible when keyboard open; gestures (swipe) ignored for item selection.

Include component props: value, onChange, onSelect, fetchSuggestions(query, signal), debounceMs (default 200), ariaIds.

Direct answer

A promise made in a sales conversation isn't automatically a commitment the roadmap has to honor, but it also isn't something to dismiss by pointing at process. The job is to find out quickly how big the ask actually is, then either fold it into already-planned work, offer something narrower that satisfies the intent, or explain clearly why it can't happen and what happens instead, rather than letting 'the process says no' be the whole answer.

Structured elaboration

1. Get the real scope fast

Find out exactly what was promised and how technically involved it is. A quick conversation with sales and a fast technical read often turns 'they promised a change' into either 'this is a config toggle' or 'this touches several systems,' and those two cases should be handled completely differently.

2. Route by size, honestly

Small, low-risk asks can go through a lightweight fast-track with the right owner's sign-off. Larger asks go through normal prioritization, with the customer commitment logged as one input among others, not an automatic override of everything else on the roadmap.

3. The urgent-and-risky variant: when the fix means a breaking contract change

Sometimes the promise is a customer-facing bug fix, and fixing it correctly requires a breaking API contract change that frontend and mobile integrations depend on. Other systems, like the mobile app, expect the API to hand back data in an exact, agreed shape (that agreed shape is the contract); changing that shape without warning breaks them, because their code is written to read the old shape and has no way to interpret the new one. Here the stakes shift: this isn't a process-bypass question anymore, it's a technical breakage risk question. The right move is to check who else depends on the contract, see whether the fix can ship as an additive, non-breaking change instead (meaning something new is added without touching what already works, so nothing that currently depends on the contract is disturbed), and if a break is genuinely unavoidable, version it and coordinate a migration window with every dependent integration before flipping it, rather than shipping it hot for one customer's benefit while breaking others silently.

4. The reverse-direction variant: when the roadmap deprioritizes something already promised

Sometimes there's no new promise to accommodate at all; instead, a roadmap shift deprioritizes a feature that was already promised to enterprise customers. Here the job isn't to accommodate a new ad hoc promise, it's to build a walk-back communication plan: get ahead of it with the account team before the customer notices the date has slipped, be specific about the new timeline or an alternative that addresses the underlying need, and give the customer-facing team language they can actually use, rather than leaving them to explain a surprise on their own.

5. Close the loop both ways

Tell the customer-facing team what was decided and why. Tell the team that owns the process whether the promise revealed a real gap worth fixing, such as a fast-track path that didn't exist yet, or a case where sales needs earlier visibility into technical constraints before a call.

Worked example

A rep promises a customer a small label change during a renewal call. A quick check shows it's a low-risk config change, so it ships that week through the lightweight path with the account owner's sign-off, and the exception gets logged. Contrast that with a case where a rep promises a fix to a data-export bug, and fixing it correctly means changing the shape of a public API response that a mobile app and two partner integrations depend on. Instead of pushing a fast fix, the team ships an additive new field alongside the old one, migrates the highest-risk integration first behind a feature flag (a toggle that turns the new behavior on for one group at a time, so it can be tested on a small slice before everyone gets it), and only removes the old field once every consumer has moved over, later than the customer originally hoped, but without breaking anyone else in the meantime. Separately, when a previously promised enterprise feature gets bumped by a roadmap shift, the team gives the account manager a specific revised date and a smaller interim capability to offer, so the customer hears a plan instead of discovering the slip on their own.

Trade-offs and pitfalls

• Using process purely as a shield, with no real attempt to find a legitimate fast path, damages trust with both sales and the customer for no real safety gain.
• Letting one ad hoc exception become the unwritten template invites every future promise to bypass prioritization; log exceptions and periodically check whether the process itself needs a documented fast lane instead.
• Treating a breaking-change fix as a normal prioritization question, rather than a dependency-risk question, is how a favor to one customer quietly breaks several others.
• Not looping back to ask why sales made a promise outside the guardrails in the first place means the same collision happens again on the next renewal call.