Spotify Staff Product Designer Interview Preparation Guide

Direct answer

I'd use Branching (a feature that spins off a separate, linked copy of a file so you can work in isolation until you deliberately merge changes back into the main file) to give each experiment variant its own protected space to iterate in, keep the main file as the single agreed source of truth, and use Version History (Figma's automatically saved timeline of a file's past states, which you can name and restore from) as the safety net and audit trail inside each branch rather than as the collaboration mechanism itself.

Step-by-step workflow

1. Branch per variant, not per person, unless two designers exploring the same variant risk stepping on each other's messy in-progress state. Figma's own real-time multiplayer canvas already lets multiple people co-edit one file live without conflict, so branching is for isolating explorations that shouldn't interfere with each other, not for basic simultaneous editing.
2. Name branches predictably: {feature}/{variant}-{short-desc}, e.g. checkout-ab/variant-a-single-column and checkout-ab/variant-b-progressive-disclosure. Tag the branch or a page inside it with the same experiment ID used in the analytics/experimentation platform, so a PM can map "Variant B" straight back to the exact Figma branch.
3. Snapshot inside the branch: save named checkpoints to Version History at meaningful moments ("v1, initial layout," "v2, after PM feedback") so exploration attempts inside that one branch can be compared or rolled back without leaving it. If a branch's history needs to jump back to an earlier explored state, use Restore on that named version rather than manually rebuilding it.
4. Review before merge: request a review on the branch; Figma shows what changed relative to main, and a reviewer comments directly on it, the same way a pull request gets reviewed in code.
5. Merge the winner: once the experiment read-out or design review picks a direction, merge that branch into main. Figma flags a conflict if main changed underneath the branch in the meantime (for example, a shared component both variants used got updated independently).
6. Close out: keep the losing variant's branch around read-only for the record rather than merging it, and immediately save a clearly named version on main ("post checkout A/B merge, variant B shipped") so anyone auditing later can jump straight to the agreed state instead of scrolling raw history.

Worked example

Two designers, Ana and Marcus, are exploring a checkout redesign for an A/B test. Main file: "Checkout Flow, source of truth." Ana branches checkout-ab/variant-a-single-column, Marcus branches checkout-ab/variant-b-progressive. Each saves two or three named versions as they iterate. After a week, the design review likes variant B's layout but variant A's button styling. Because Figma merges a whole branch at once rather than reconciling individual layers the way git merges lines, the fix isn't a partial merge; Ana updates the button styling directly inside Marcus's branch using the shared component library, and only that single combined branch gets merged into main.

Trade-offs and pitfalls

• Branching solves file-conflict isolation, not design disagreement; the human call over which parts of which exploration win still has to happen before the merge, since Figma can't automatically reconcile two branches' edits to the same layer tree the way git reconciles non-overlapping code lines.
• Version History inside a branch is only useful if someone actually saves named checkpoints; left to pure auto-save, it becomes a wall of untitled snapshots that's hard to navigate mid-experiment.
• A common shortcut, duplicating pages inside one file per variant instead of branching, avoids the merge step but pollutes the single source-of-truth file with dead-end explorations, and makes it easy for a shared component update to silently reach a variant nobody's using anymore.

Direct answer

Structure the site around what each audience needs to do, not a generic sitemap: fast component lookup for engineers, pattern and rationale browsing for designers, and governance visibility for PMs, all reachable from one global search rather than three separate silos that each audience has to know to look for.

Structured elaboration

Main sections, in navigation priority order:

flowchart TD
  Home[Home and Search] --> Found[Foundations]
  Home --> Comp[Components]
  Home --> Pat[Patterns]
  Home --> Tok[Tokens and Theming]
  Home --> Play[Playground]
  Home --> Gov[Contribution and Governance]
  Home --> Res[Resources]

• Foundations: tokens, grids, motion, accessibility principles, the vocabulary the rest of the site assumes.
• Components: the catalog, with variants, props, and states per component.
• Patterns: composed flows and templates (a full form, a settings page layout), one level above individual components.
• Tokens and theming: downloadable/exportable tokens and theming guidance, separated from Foundations because it's a distinct consumption path (engineers pulling raw values vs. designers reading principles).
• Playground: live, editable examples.
• Contribution and governance: how a change gets proposed, reviewed, and decided, plus the decision records themselves.
• Resources: downloadable assets, support channels, links to source repos.

Navigation and search priorities: global fuzzy search first, since it beats browsing for time-to-answer on a known component name; status facets (stable / beta / deprecated) so nobody builds against something about to be removed; role-based landing shortcuts so a PM's first click doesn't dead-end in an engineering reference page.

Search features: index component names plus common aliases and prop names (so searching "loading state" surfaces the right components even if none of them are named "Loading"), filter by platform and status, and deep-link directly into a specific prop table anchor rather than just the page.

Interactive docs (playgrounds): a live prop-driven example where changing a prop in a panel updates the rendered output and shows the generated code snippet to copy. This beats a static screenshot specifically because an engineer can copy working code directly instead of re-deriving the right prop combination from a picture.

Surfacing governance: attach the relevant decision record (an RFC or design-exploration-and-choice record) directly on the component's own page, with a status badge and date, instead of burying it in a separate wiki. The "why" needs to be visible exactly where someone is deciding whether to depend on the component.

Worked example

A PM viewing the "Modal" page sees an amber "Beta" status badge next to the component name. Clicking it links to the governance record documenting that Modal is replacing a deprecated "Dialog" component, with a stated target date for full adoption. The PM can now factor that into their own roadmap as a dependency, instead of discovering mid-sprint that the component their team built against is being phased out.

Trade-offs and pitfalls

Putting governance records in a separate top-level tab is the single most common mistake: PMs and engineers rarely browse a standalone governance section, so the record only earns attention when it's inline on the component people are actually about to use. Building custom search infrastructure (bespoke ranking, NLP) before proving basic fuzzy search is insufficient wastes effort most teams don't need to spend. Hand-maintained playgrounds go stale the moment the component's real API changes underneath them; generating the playground's prop table from the component's actual type definitions at build time avoids that drift entirely.

Direct answer

Teaching a skill you don't have natural talent for means separating what you know intuitively from what's actually teachable. You diagnose the real gap first, build an explicit, decomposed framework for the skill (even though you perform it by feel), and validate progress by watching the person apply it independently, not by how confident the coaching sessions felt.

Approach to teaching outside your natural strength

Diagnose before prescribing. "Struggles with X" is rarely one problem. Watch or review their actual attempt and separate the layers: is it a knowledge gap (they don't know the structure), a delivery gap (they know the structure but execution is shaky), or a confidence gap (they know it and can do it, but freeze under real stakes). Each needs a different intervention.

Decompose your own tacit skill into explicit steps. If you're good at something without having consciously learned it as a framework, you have to reverse-engineer your own process before you can teach it. Skipping this step and just saying "do what feels right" doesn't transfer anything.

Practice at graduated, increasing stakes. Start with low-stakes reps where mistakes are cheap and recoverable, then move toward the real, higher-stakes version. Jumping straight to the real thing conflates skill-building with performance evaluation in the person's head, which raises anxiety and slows learning.

Give feedback on the mechanism, not just the outcome. "That worked" or "that didn't work" is much less useful than pointing at which specific move in their approach caused the result.

Worked example

Situation: someone you're mentoring is excellent at the core technical work but has a real gap in a skill that doesn't come naturally to you either, say, communicating findings clearly to people outside the immediate team. Their material was always technically sound, but reviews ran long and the point often got lost.

Task: help them close that gap over a defined stretch, without pretending you have natural talent for it yourself.

Action: you watched a recording of one of their sessions together and separated content problems (no clear headline, too much detail up front) from delivery problems (pace, not anticipating pushback). You gave them a simple structure to practice against: state the conclusion first, then the supporting evidence, then the recommendation. You ran a couple of low-stakes rehearsals where you played a skeptical stakeholder, then let them run the real session solo.

Result: over a few sessions, their reviews needed fewer clarifying follow-up questions from the room, and the structure started showing up unprompted in written material too, not just live presentations. The real signal wasn't how the coaching sessions felt: it was watching them handle a session you weren't part of and hearing secondhand that it landed cleanly.

Trade-offs and pitfalls

A common junior-mentor mistake is trying to transfer your own tacit competence directly ("just do what I do") instead of decomposing it. That fails specifically because the skill you're teaching is one you never consciously learned as steps.

Another mistake: avoiding coaching on gaps you don't personally excel at, on the theory you're not qualified. You don't need to be naturally gifted at a skill to teach its structure. You need to be willing to build the explicit framework, which sometimes non-naturals do better than naturals, because they had to learn it deliberately themselves.

The real trade-off is time. Teaching a skill outside your own strength takes longer to prepare for, because you can't rely on instinct in the room. That prep time is where the actual coaching value gets built.

Direct answer

Credibility with people who have no track record with you is earned in the first few interactions, not argued for. The fastest reliable path is to listen before recommending anything, make your reasoning visible rather than just your conclusions, and deliver one small, real result quickly, before you ever ask them to trust a bigger claim.

Structured elaboration

A framework for the first interactions with a new stakeholder or team.

1. Intake before opinion: understand what decisions they're actually trying to make and what's gone wrong for them before, before offering any recommendation.
2. Show your work: when you do produce something, make the validation visible (trace a number back to its source live, walk through how a result was derived) instead of asking them to trust a polished output.
3. Deliver a small, real win fast: a scoped result within the first couple of weeks does more for trust than a comprehensive plan that ships in month two.
4. Telegraph how you handle being wrong: tell them up front how you'll flag it if something in your work turns out to be off. People trust someone who has already shown you a plan for your own mistakes.

The first 30 days. New cross-functional partners are evaluating you the whole time, not just at the big review. Being proactive about the relationship in the first 30 days, rather than waiting for a natural moment, is itself a credibility move. A first 1:1 with a new partner can open with something like: "What decisions are you trying to make in the next month that you don't feel confident about today?" followed by "What's gone wrong before when someone tried to help with this?" Both questions do real work: the first surfaces what would actually count as a win to them, the second surfaces the specific way trust was broken before, so you don't repeat it by accident.

Three behaviors that quietly erode credibility across teams, and the remediation for each:

Credibility repair is a different problem from rapid trust-building, and worth naming separately. Rebuilding credibility across engineering, product, and customers after an architecture decision failed in production is credibility repair, not the repair of a single personal relationship: it spans multiple functions at once, each of which needs something different. Engineering needs an honest technical postmortem without blame-shifting. Product needs clear, early communication about impact and timeline. Customers need a concrete remediation plan and a channel that doesn't go quiet. Treating this as "smoothing over one relationship" misses that trust has to be rebuilt with several audiences in parallel, each judging you by different evidence.

Worked example

Situation: in the first month partnering with a new team (the fraud-risk team, which had just started requesting weekly modeling support from the analytics group for the first time), the working relationship started skeptical, because past deliverables from this kind of collaboration had shipped late and with numbers nobody trusted.

Actions: an early 30-minute intake conversation confirmed exactly which decisions the partner team needed to make (specifically, which transaction-flagging threshold to set for the coming week) and which metrics actually mattered to them (the false-positive rate on flagged transactions, not just the raw flag count), rather than assuming. A one-page plan with milestones and explicit validation steps went out so expectations were unambiguous. A working version, a weekly false-positive-rate dashboard for the fraud-risk team's review queue, shipped inside the first two weeks, and in the walkthrough, a couple of numbers the partner flagged as surprising (the false-positive rate for one transaction category showing 22% instead of the roughly 8% they expected) were traced live, back to the source data, in the room, instead of being defended from memory. The trace showed the 22% figure was correct: a recent change to that category's flagging rule had not been backed out of the historical comparison period, inflating the apparent rate.

Resolution: the partner team began using the dashboard for real weekly threshold decisions within the two-week window. What changed their minds wasn't the polish of the output, it was watching the 22% number get traced back to its source live and seeing that the plan they'd agreed to up front was the plan that got delivered.

Trade-offs & pitfalls

• Rapid trust-building tactics (intake, quick win, visible validation) and credibility-repair tactics (postmortem, cross-function communication, remediation plan) are not interchangeable; using a "quick win" playbook after a public failure reads as minimizing what happened.
• An intake-only approach that never produces anything can itself read as stalling; the first small delivery needs to land within roughly the same window as the intake conversation, not months later.
• Under-promising protects credibility but can look like low ambition if you don't also communicate what you're deliberately holding back on for now.

Direct answer

First, check whether it is truly a contradiction. A 50/50 split among a small set of interviews is a prompt for questions, not a market finding. Then turn the tension into four testable questions about who wants what, what they actually do, what each word means, and whether one design can serve both. For next steps, choose the cheapest evidence that would change the design decision: re-code what you already have, then usage data, then a prototype test.

Structured elaboration

Four testable questions:

1. Does the split line up with a user attribute? (for example daily users vs occasional users, expert vs novice, role). Re-code the existing interviews by that attribute: go back through your notes and tag each participant with it (for example daily or occasional user), then see whether the two camps differ. This costs nothing.
2. What is behind "customization"? A specific unmet need, a wish for control, or a workaround already in use? Check what people do today, not what they say.
3. What does "simplicity" mean to each person? Fewer options, fewer steps, or less to learn are different design problems.
4. Can defaults plus progressive disclosure serve both? Progressive disclosure means showing a simple path by default and revealing advanced options on request. Test with a prototype that has both paths. In practice, a settings-heavy screen opens with sensible defaults (the pre-chosen settings most people never change) and one "Advanced" panel. Give each participant a task such as "set up a weekly report for your team" and watch whether occasional users finish unaided on the default path and whether frequent users find and change the advanced controls without help.

Deciding what to learn next: rank by how much the answer changes the design decision and how cheap it is. (1) Re-code existing data; (2) pull product usage: what share of users ever change a setting today; (3) prototype test of question 4. A survey comes later, and only to size a segment difference (estimate how many users fall into each group and how their needs differ) once found.

Worked example

Illustrative. Twelve interviews: 6 ask for customization, 6 for simplicity. Re-coded by usage frequency, the customization group is 5 daily users and 1 occasional user; the simplicity group is 2 daily and 4 occasional. Daily users total 7 and occasional users 5, so 12 in all. The split now looks like a frequency split, which gives a sharper hypothesis: "frequent users want control, occasional users want a clean path." Twelve interviews cannot confirm it, so I would check usage data for how many people change the default settings, then run a prototype with a simple default and an advanced panel and watch whether occasional users finish tasks unaided and frequent users find the controls.

Trade-offs and pitfalls

• Counting opinions is weak evidence. A 6 to 6 split in 12 people says nothing about the proportions in the user base.
• Do not average the two groups into a middle design that satisfies neither.
• Stated wants and behaviour diverge. What people ask for in interviews often differs from what they use.
• What would change my call: if usage data shows almost nobody changes any setting, I would lean toward simplicity and park customization.

Direct answer

Do not treat the metric win and the UX risk as opposing bets. Before building anything, agree with design and product on the primary success metric and on explicit guardrail metrics chosen specifically to catch the kind of harm the primary metric would not see, then validate cheaply with a prototype or a small qualitative test before committing to a live experiment sized to detect both.

Structured elaboration

Agree on what "good" means before anyone builds

The primary metric, say a conversion or engagement number, tells you if the change works on its own terms. Guardrail metrics are chosen specifically because they would catch harm the primary metric is blind to, such as task completion, return usage a week later, or support-ticket volume. Naming guardrails upfront, with agreed thresholds, prevents "we'll know it if we see it" arguments after the fact.

Validate cheaply before going live

A clickable prototype or a small moderated usability session can surface confusion or trust issues that the metric alone cannot catch, at a fraction of the cost of a live experiment. This is not a substitute for the experiment, it is a cheap filter that catches the worst ideas before they reach real users.

Run a bounded experiment, not a full rollout

Start with a small slice of traffic, watch both the primary metric and the guardrails, and decide the stopping rule, meaning what result on which metric ends the test, before the test starts, not after you see the numbers.

Decide and communicate together

If the primary metric improves but a guardrail moves the wrong way, that is a real finding, not a technicality to explain away. Whether to ship, iterate, or drop the idea is a joint call between design, product, and whoever owns the guardrail metric, made against the thresholds agreed upfront.

Worked example

Design proposes reordering a list of recommended items to increase click-through rate. The concern is that users may have learned to expect a stable, predictable order, and reordering it could hurt their ability to quickly find what they are looking for on repeat visits, something click-through rate would not show because a user can click more and still be more frustrated.

Before building, the group agrees the primary metric is click-through rate, and the guardrails are task completion rate (did the user's search end in the outcome they were after) and a return-usage check at one week out. A moderated usability test with a handful of participants on a clickable prototype surfaces that new users find the reordered list fine, but a couple of returning participants mention it "looks different" and take longer to find what they normally click first. That is a signal, not a stop sign: the team ships the change to a small slice of traffic, watches both metrics for an agreed window, and only expands the rollout if task completion holds steady alongside the click-through gain.

Trade-offs and pitfalls

Over-instrumenting every change with a full guardrail suite slows teams down and trains people to skip the process for anything that feels small. Guardrails should be chosen deliberately for the specific risk in question, not applied as a blanket checklist.

The sharpest failure mode is agreeing on guardrails in principle but not on thresholds, so when a guardrail moves slightly, the debate about whether it is a real regression happens after the data is already in and someone has already committed emotionally to shipping. Fixing the threshold before the test removes that fight.

Direct answer

Qualitative research tells us why people struggle and what they need; it does not tell us how many people are affected or whether our specific solution fixes it. Engineering cost tells us what the answer will cost. So I would not choose between "believe the research" and "believe engineering". I would turn the recommendation into a testable claim, price the cheapest way to test it, and choose among proceed now, postpone, or test an alternative on that basis.

Process

1. Restate the recommendation as a problem and a hypothesis (a testable guess about cause and fix). "Users cannot find X, which blocks Y. We believe moving it to Z fixes this." Separate the observed problem (strong, from interviews) from the proposed solution (a guess).
2. Probe the evidence with the researcher. How many participants, which segments, how consistent, what did people do versus say? A handful of interviews is good at surfacing problems and weak at sizing them, so I look for a cheap quantitative check (support ticket counts, funnel drop-off at that step: the share of users who reach a step in a flow but do not continue past it) to size the problem.
3. Unpack the engineering "expensive" with the engineers. Ask what drives the cost: new back-end work, a design-system change (editing the shared set of interface components that many screens reuse), migration of existing users? Ask for the smallest slice that tests the idea and a rough range, not a single number.
4. Generate options at different costs. Typical ladder: a clickable prototype test (days), a partial change to the most-hit screen, a feature-flagged experiment (the change shown to a random share of users behind an on/off switch, compared with everyone else), the full redesign.
5. Decide with explicit criteria: size of the problem, confidence the solution works, cost, reversibility, and what else the team would not build.

Worked example (illustrative)

Eight interviews show people abandoning the setup flow at the account-linking step. Engineers estimate 10 engineer-weeks (one engineer working one week each) for the full redesign. A funnel check shows 1,000 sign-ups a month reach account linking and 600 complete it, so 400 (40%) abandon, and the problem is real. Instead of 10 weeks, we spend 1 week on a clickable prototype test with new users and 2 weeks building a simplified version behind a flag for an experiment, 3 weeks of team effort before the experiment can start. The calendar time to a read is longer: the 500-per-group sample needs 1,000 users, and only 1,000 sign-ups a month reach account linking, so the experiment runs for about a month after the build, roughly 7 calendar weeks in all (1 prototype + 2 build + about 4 running). Decide the thresholds first. Lift means the increase in completion rate compared with the control group. If the simplified version lifts completion by 10 points or more (60% to 70%, 100 extra completions a month), proceed to the full redesign or ship the simple version permanently. If lift is under 3 points, postpone and log it. Between 3 and 10 points, extend the test, because with 500 users per group the random noise is about 3 points (square root of 0.6 x 0.4 / 500 x 2 is about 0.031), so small differences cannot be trusted.

Pitfalls

• Treating "5 of 8 said it" as a measured rate. It is a clue, not a percentage.
• Letting engineering cost veto without asking for a smaller slice; or letting the research sponsor dismiss cost.
• Closing the loop poorly: tell the researcher and engineers what was decided and what evidence would reopen it.

Visual hierarchy is the deliberate use of visual properties, size, color, spacing, and position, to signal which elements on a screen matter most, so a user's eye lands on the right thing first without having to read everything to figure that out. On a screen with a lot competing for attention, hierarchy is what keeps it scannable instead of overwhelming.

Three core techniques, plus one that's easy to forget

1. Size and weight (typography). A larger, bolder element reads as more important simply because it takes up more visual space and effort to render. Example: on a pricing page with a headline at 16px regular and a plan price at 40px bold, a user's eye lands on the price before reading a single word of the headline, because size alone does the sorting.
2. Color and contrast. A saturated, high-contrast color surrounded by neutral tones pulls the eye toward it, because the eye is naturally drawn to what's different from its surroundings. Example: if the only saturated color on an otherwise gray-and-white settings screen is the "Save" button, that button becomes the obvious next click even before a user reads its label.
3. Spacing and isolation. Giving an element more surrounding whitespace than its neighbors signals that it's separate and worth pausing on, since crowded elements read as routine and isolated elements read as deliberate. Example: a promotional banner surrounded by 48px of empty space, versus 16px around ordinary list items, makes users' eyes stop on the banner instead of scanning past it as just another row.
4. Position. In left-to-right reading cultures, users scan roughly top-to-bottom and left-to-right, so placing the most important element first in that path (top of the screen, or the start of a row) gives it a head start on attention before a viewer has consciously decided what to look at.

How these combine, and where interaction states fit in

None of these techniques work alone in a real interface; a strong screen usually stacks two or three of them on the one element that matters most (the primary action might be the largest, most saturated, AND most isolated thing on the screen), while everything else stays comparatively quiet on all three dimensions. Hierarchy also isn't static: interaction states like hover, focus, and selected add a temporary layer of emphasis on top of the base hierarchy, for example an item highlighting on hover to say "this is clickable" or a focus ring appearing for a keyboard user. That temporary emphasis has to be consistent with the underlying hierarchy, not fight it, or the interface will feel like it's changing its mind about what matters.

Trade-offs and pitfalls

The most common mistake is treating hierarchy as "make everything important stand out," which cancels itself out: if five elements are all large, bold, and saturated, none of them wins and the screen reads as noisy rather than clear. Good hierarchy usually means suppressing far more elements than it emphasizes.

Opening framing (one line)
As a Product Designer I build buy‑in by pairing user-centered evidence with clear financial modeling, low-risk pilots, and tailored executive narratives that connect long‑term retention to strategic KPIs.

Stakeholder mapping

• Identify: Executives (CEO, CRO, CFO), PMs, Eng leads, Growth/Analytics, CX, Sales, Legal.
• Map influence/concern: e.g., CFO = short-term revenue focus, Growth = acquisition velocity, CX = NPS/retention.
• Define asks per stakeholder: risk mitigation for CFO, implementation cost for Eng, metrics for Growth.

Evidence to gather

• Qualitative: user interviews, churn exit surveys, usability testing highlighting pain points causing churn.
• Quantitative: cohort retention curves, LTV by cohort, funnel dropoffs, A/B historical lift/decline, support ticket volume.
• Competitive benchmarks and case studies showing product changes that improved LTV.

Business‑case modeling

• Build a 12–36 month model showing scenarios: baseline, conservative, optimistic.
• Key inputs: change in retention rate, ARPU, conversion %. Compute incremental LTV and payback period.
• Sensitivity analysis for worst‑case short‑term revenue drop and time to breakeven.

Pilot strategies

• Start with a targeted cohort (new users or high-churn segment).
• Implement feature toggles, run A/B test measuring short-term revenue, retention at 30/60/90 days, NPS, and support load.
• Use rollout gating (50% → 100%) and rapid iteration based on telemetry.

Executive communication tactics

• Lead with business impact: one-slide LTV delta and breakeven timeline.
• Show user stories and evidence succinctly; present pilot plan and mitigations.
• Offer clear asks: decision, budget, guardrails (timebox, KPIs).
• Commit to regular updates and a rollback plan to reduce perceived risk.

Result: structured, data‑backed path that aligns design tradeoffs with long‑term company value while managing short‑term financial concerns.

Direct answer

A strong answer gives two anchors, not one: a specific, checkable one-to-three year target that's a real scope upgrade from today, and a five-to-ten year horizon described in terms of the scope of impact and the kind of problems you'd be solving, not just a title. The through-line between the two should be explicit: the near-term move is a deliberate step toward the longer one.

Structured elaboration

1. Pick the long horizon first, described by scope. "Owning a function," "operating at a staff-level technical scope," "leading a product area," rather than a bare job title.
2. Use a title only as illustrative shorthand. Something like a Staff Data Engineer role, a VP of Product role, or a Principal Solutions Architect track, named as one example of that scope, not a rigid claim, since exact titles vary widely by organization.
3. Work backward to the near-term milestone. What capability or ownership increase has to happen in the next one to three years before the longer horizon is even attemptable.
4. Name how you'd know you're on pace. Skills acquired, scope taken on, feedback received, described qualitatively rather than with invented numbers.
5. Keep both horizons on the same through-line so the answer isn't two disconnected wishes.

Worked example

"Right now I own a single project end to end. In the next one to three years I want to be the person a team turns to for the hard, ambiguous calls, not just execution, roughly a senior or staff-level scope. Five to ten years out, I picture something like a Principal Solutions Architect role, or a VP of Product path if I lean toward the product side, wherever this trajectory naturally leads, setting direction for a whole area instead of a single project. I frame it that way instead of naming one exact title because titles vary a lot org to org. What stays constant is the scope."

Trade-offs & pitfalls

• Naming only a title with no scope behind it, "I want to be a director", signals the goal hasn't been thought through.
• Giving only the long horizon and skipping the near-term milestone dodges the "walk me through both" part of the question.
• Overfitting to one exact title from one specific company you researched can read as scripted. Illustrative language ("something like...") is safer than a rigid claim.
• Being so vague, "somewhere senior, doing meaningful work", that it reads as having no real plan at all.