Google UI Designer Interview Preparation Guide - Mid Level

Direct answer

Treat visual richness as a budget, not a binary choice: rank each effect by how much perceived polish it actually contributes against how expensive it is to render, and cut from the bottom of that ranking first. Find out where the real pain is by testing on genuinely low-end hardware, not by guessing from a high-end development machine.

Structured elaboration

1. Rank effects by rendering cost against visual payoff. A static drop shadow (box-shadow) is cheap, rendered once and effectively cached, and it carries real value for hierarchy and elevation, so it is usually not the first thing to cut. A live blur (a frosted-glass panel that recomputes what's moving behind it every frame) is one of the more expensive visual effects on a constrained GPU, since it has to resample pixels continuously rather than once, making it a strong first candidate to cut or fake. Continuous, scroll- or gesture-linked animation, like a parallax effect, competes directly with the browser's main thread (the single thread that runs JavaScript, handles scrolling and input, and does most layout work, so anything expensive there can make scrolling itself feel janky) while it is also handling scrolling and input, making it the next candidate after live blur.

2. Anchor the ranking to the frame budget, which is what makes "expensive" a number rather than a feeling. A screen targeting 60 frames per second has 1000/60, about 16.7ms, to produce each frame, and everything on that frame shares it: your effect, the scroll itself, and any application work. That is why the cost that matters is cost per frame, not cost per element. Work done once, at any size, is nearly free by comparison; work repeated every frame is what eats the budget.

3. Find where the pain actually is before cutting anything. Test the product on an actual low-end reference device rather than a throttled setting on a fast development laptop, which under-represents real memory and GPU limits, and profile the specific moments users complain about, usually scrolling a list with many cards or opening an overlay that includes a blur, since the "janky" feeling usually traces back to one or two specific interactions rather than the whole interface uniformly.

4. Cut selectively and prefer solid alternatives over disabling effects outright. Replace a live blurred backdrop with a solid, slightly darkened scrim in the brand's own neutral color, which keeps the same "focus the eye here" effect the blur provided at near-zero rendering cost. Replace a continuous parallax with a single, short entrance transition that plays once and does not run during scrolling. Keep static shadows, but consider a smaller blur radius, which is cheaper to render and usually indistinguishable to users from a larger one.

5. Prefer animating transform and opacity over animating layout properties. Animating a card's position or fade with transform and opacity can typically be handled through GPU compositing (the graphics chip slides and fades the already-drawn pixels around directly, without asking the browser to redraw anything) without recalculating the page's layout (recomputing where every element on the page now sits, a step that cascades to neighboring elements) on every frame, while animating properties like width, top, or a shadow's own values directly usually forces the browser to recompute layout or repaint (redrawing the actual pixels of an element, as opposed to just moving pixels that are already drawn) on every frame, which is the more expensive path on constrained hardware. This is a well-established browser rendering distinction, not device-specific guesswork: transform and opacity are the two CSS properties that are almost always compositor-only, which is why they are the safe default to reach for first when animating anything on a low-end device, even without a deep rendering background.

Worked example

A card list shows 20 visible cards. Each card carries a drop shadow, and each card also has a background image with a parallax effect that shifts it as the user scrolls, so there are 20 shadows and 20 parallax images on screen at once. A bottom sheet with a frosted blur behind it appears on tap. On a low-end device, users report that scrolling specifically feels sluggish while the parallax is active.

Keeping the counts identical is what makes the diagnosis clean, because the only variable left is how often the work happens. The 20 shadows are painted once and then composited, so their cost does not repeat as the user scrolls. The 20 parallax images each need a transform recalculated on every scroll frame, so at a 60fps target that is 20 updates inside each roughly 16.7ms budget, competing directly with scrolling's own work on the main thread. Same element count, same screen, and the difference is entirely once versus every frame. That is the ranking from point 1 showing up as a measurement rather than an opinion.

The fix: keep the shadows exactly as designed, since they are cheap and load-bearing for hierarchy; cap the parallax to only the two or three images currently near the viewport instead of all 20, since a parallax offset on an image the user cannot see buys nothing; and swap the bottom sheet's live frosted blur for a solid, semi-transparent scrim, which still visually separates the sheet from the page but does not have to resample the pixels behind it on every frame.

Trade-offs and pitfalls

A common wrong turn is cutting shadows and elevation first, because they are the most visually obvious "decorative" thing, while the real cost driver, live blur or continuous scroll-linked animation, survives untouched. The worked example is the general case: the thing that looks most expensive and the thing that costs most per frame are frequently not the same thing, and only the per-frame view separates them. A blanket "reduce motion" toggle that strips every animation equally treats a one-time entrance transition, cheap and high value, the same as a continuous scroll-linked effect, expensive and lower value, losing more polish than necessary. A graduated, capability-based approach usually preserves more of the intended feel for users on capable hardware while still protecting the experience on low-end devices, at the cost of more variants to design, test, and keep in sync.

Direct answer

The rhythm runs in three loops of increasing formality: quick async or standup-level syncs for day-to-day blockers, a weekly or per-milestone design review with product and engineering to catch problems before they're expensive, and a structured handoff once a design is ready to build. When timelines or requirements shift mid-cycle, the fix is to renegotiate scope against the same shared artifacts everyone already trusts, rather than letting the change get absorbed silently into someone's individual workload.

Structured elaboration

What a design review is actually checking for
Before anything moves toward handoff, a review should specifically catch:

• Missing or inconsistent states: empty, loading, error, and success, for every meaningful screen or component, not just the happy path.
• Edge cases engineering will hit that the design never addressed (what happens with a very long name, a failed network call, zero results).
• Accessibility gaps: focus order, contrast, labels for anything interactive.
• Whether the design still matches the current data model and API shape, since those sometimes drift during a cycle without design being looped back in.

Handling a mid-cycle shift

• Update the shared artifact (the story map, the flow) first, so the change is visible to everyone rather than living in one person's head.
• Re-run a lightweight version of the prioritization used at kickoff: what's the smallest version that still meets the core need given the new timeline or requirement.
• Flag the change explicitly in the next standup or review rather than letting it surface as a surprise at the next handoff.

Worked example

Mid-cycle, engineering discovers that a third-party API the design assumed would return structured error messages actually just returns a generic failure code. That's a requirement shift, not a scope cut. Instead of the designer quietly reworking the error state alone, it gets raised in the next review: the error-state design is revised together with the constraint now understood, the decision (why the error copy had to become more generic) gets logged, and the story map is updated so it's visible that this flow changed. Handoff for that screen is delayed by one review cycle rather than shipped with a mismatch between the spec and what engineering can actually build.

Trade-offs and pitfalls

• Skipping the review to save time is the most common shortcut that backfires, because missing states and edge cases are far cheaper to catch in review than after implementation.
• Treating handoff as a one-way document drop instead of a conversation misses the chance to catch a misunderstanding before code gets written.
• Absorbing a mid-cycle change silently (just redoing the work without updating the shared artifact or flagging it) hides the real cost of the shift from the team and makes the next timeline estimate less trustworthy.
• Too much ceremony for an easy, low-risk cycle wastes the team's time; the cadence above should scale down for small, low-risk changes and scale up for anything cross-team or high-stakes.

Direct answer

The core move in an incident explanation to a non-technical audience is separating three layers up front: what happened (in plain terms, no root-cause mechanism), what it meant for them (impact, in terms they already track), and what's being done about it, then deliberately leaving out anything that doesn't serve one of those three. Below is an incident where I did that under time pressure, including delivering it live to a mixed engineering-and-business audience.

What to include, what to leave out, and how to decide

• Lead with impact, not sequence. Legal, sales, and executives care about what happened TO THEM first, which customers, how long, what's the exposure, the technical timeline is useful evidence, not the headline.
• Deliberately exclude logs, stack traces, and internal service names; they add authority for an engineering audience and add nothing but confusion for this one. A useful test: if a detail doesn't change what the listener should do next, leave it out.
• Give the cause in one plain sentence with no jargon, something like "a recent configuration change made one of our systems too slow to respond to a partner service in time," rather than either omitting cause entirely (which reads as evasive) or over-explaining the mechanism.
• When delivering this live rather than in a written report, whether it's a hallway update or presenting a postmortem verbally to a room that mixes engineers and business stakeholders, pause after the impact statement for questions before moving to cause. People worried about impact can't absorb a root-cause explanation until that worry is addressed first.

Worked example

Situation: during a high-traffic sales period, our payment service began intermittently failing checkout requests for roughly ninety minutes. Legal, sales leadership, and the executive team needed an explanation quickly.

Task: explain what happened clearly enough for them to act, communicate with affected customers, assess any obligations, decide on immediate next steps, without either alarming them with irrelevant detail or minimizing the impact.

Action: I opened with impact, in the terms they track: which customers were affected, for roughly how long, and that the issue was fully resolved and being watched closely. I gave the cause in one sentence: a recent configuration change made our payment service too slow to respond to our external payment gateway in time, causing some checkout attempts to fail. I described what we did in plain terms (reverted the change, increased how long we wait before giving up on a slow response, added an automatic circuit breaker so a slow dependency can't cascade into a wider outage) and what we were doing next (a deeper review, with a fuller technical writeup available to anyone who wanted it). I left out the specific error codes, service names, and configuration parameter, none of which changed what legal, sales, or the executives needed to do next. I paused for questions right after the impact statement, before moving on, and answered a legal question about customer notification obligations directly instead of routing it back to engineering jargon.

Result: legal and sales left with a clear, accurate picture of exposure and could communicate confidently with affected customers; the executive team approved the follow-up work (the circuit breaker and review) without needing to dig into implementation detail themselves, and a fuller technical postmortem was made available separately for the engineering team that wanted the mechanism-level explanation. I learned that pausing for questions right after the impact statement, before cause, kept people from tuning out a cause explanation they weren't ready to hear yet.

Trade-offs and pitfalls

Leaving out technical detail can read as evasive if you do it silently; I said "I'm not going to walk through the technical internals here, I'm glad to share those separately" so the omission was visible on purpose rather than hidden. The other pitfall is understating severity to keep the room calm, that erodes trust the moment the real scope becomes clear later. State the honest impact even when it's uncomfortable, and let the "what we're doing about it" section carry the reassurance instead of the impact statement itself.

Direct answer

Treat popularity as evidence of a problem, not as a specification. I would find the need behind the request, test whether the UX direction (the intended overall design approach of the product) has good evidence behind it too, and then choose between building it as asked, building a version that fits the direction, solving the need another way, or declining. Whatever I decide, I tell users what we heard, what we chose and why.

How I decide

1. Understand the need: ask what people do with it and what breaks without it.
2. Size it: how many people, how often, and how severe? Compare broad usage data with the loudest forum voices.
3. Challenge both sides: does our direction rest on evidence, or on taste?
4. Weigh the cost of contradiction: more complexity, an inconsistent experience, and extra maintenance.
5. Prefer a small test: a prototype or limited release before committing.

Worked example (illustrative)

Users of a file app keep asking for the old list view, while the team is moving to a card grid. Asking what they do shows they scan file names and sort by date. Instead of bringing back a second layout, the team adds a compact grid density showing full names plus date sorting. That serves the need and keeps the direction.

How I tell users

• Say what we heard ("many of you asked for the list view").
• Say what we decided and why, in plain terms.
• Say what we did instead and what to expect.
• Say when we will revisit, and invite feedback.

Silence reads as being ignored, which costs more trust than a clear no.

Pitfalls

Building the feature because it is loud, or declining because it is inconvenient, without testing the need.

Direct answer

I'd pick one concrete feature, define its behavior as a state machine independent of platform, what triggers each state, what the user sees, how long the system waits before changing state, and hand every platform team the same specification table. That way "consistent" means the same trigger produces the same wait time and the same message everywhere, even though the exact widget used to show it, a banner on web, a native toast on Android, an alert on iOS, can differ.

Worked example: a search-results list

The 300ms, 10s, and 20s thresholds are conventions this team would pick and pin for this feature, not universal constants; the point of writing them down explicitly is that "slow" and "timeout" mean the same number of seconds on every platform, not each engineer's own guess.

How I'd document it so each team implements it the same way

• A single trigger-to-state-to-timing-to-copy table as the source of truth, referenced by all three platform tickets, instead of three separate specs that can drift apart.
• Explicit accessibility notes per state: what a screen reader announces when the state changes, for example the error state should be announced through each platform's live-region equivalent, since a visual-only spec silently produces three different, inconsistent screen-reader experiences.
• Acceptance criteria written as testable statements, "given no network response after 20 seconds, the user sees the timeout state with a Retry action," rather than descriptive prose, so each platform's QA can verify the same behavior independently.
• A single walkthrough meeting with all three platform leads together, not three separate handoffs, specifically to catch platform-specific assumptions, for example "Android already has a system-level offline banner, do we need our own too," before they cause the builds to diverge.

Trade-offs and pitfalls

Specifying identical timing and copy is achievable; specifying identical motion or exact visual chrome usually isn't worth the fight, since each platform has conventions users already expect, a native-feeling error toast on Android versus an iOS-style alert. Push for consistency in what the user learns and how long they wait, not in pixel-for-pixel appearance.

Direct answer

Bring the gap or failure to your manager before they discover it independently, frame it factually rather than either minimizing it or over-apologizing, and pair the admission with a concrete plan you've already started thinking through, so the conversation is about moving forward, not just confessing.

Structured elaboration

• Framing the conversation. State the fact plainly and early, without burying it in caveats or waiting to be asked. Be specific about what happened or what the gap is, rather than vague ("things didn't go great"). Avoid both extremes: minimizing it in a way that undersells the manager's need to know, and being so self-critical that the conversation becomes about reassuring you rather than solving the problem.
• Proposing a development plan. Come with at least a first draft of a plan, even expecting the manager to adjust it, since arriving with only the problem puts the entire solution-finding burden on them. A good plan names a specific action, a way to check it's working, and a rough timeframe.
• The result. Describe honestly what actually happened afterward, including if the plan needed to be adjusted, since a story where everything worked perfectly on the first try can read as too tidy. Showing the plan was adapted when the first version wasn't quite right is itself evidence of the coachability the question is testing.

Worked example

Partway through a project, it becomes clear there isn't enough depth in a specific area, say a particular kind of performance analysis, that the project now needs, and it's starting to slow the team down. The proactive move is going to the manager directly: "I want to flag that my lack of experience with this kind of analysis is slowing this down. Here's what I'm planning to do about it: pair with a teammate who's strong in this area for the next two work sessions, and if I'm still stuck after that, I think we should bring someone else in for this specific piece." The manager agrees, adds one suggestion, a specific internal resource to read first, and two weeks later the candidate follows up with what actually happened: the pairing helped, but a third session was needed rather than two, which was proactively flagged rather than quietly pushing the deadline.

Trade-offs and pitfalls

Waiting until the manager notices the gap or failure independently reads as either avoidance or poor self-awareness. Bringing only the problem with no plan shifts all the work back onto the manager. Over-apologizing in a way that makes the manager spend the conversation managing your emotional state instead of solving the problem is also a risk. And describing a result that's suspiciously perfect is usually less credible than acknowledging the plan needed adjusting, which, done well, still demonstrates the coachability being tested.

Direct answer

Five categories worth having a go-to plugin for, split across the two halves of the question: for prototyping, realistic placeholder content and prototype flow wiring or flow mapping; for design-system work, accessibility or contrast checking, batch layer hygiene, and design-token management. The specific plugin filling each slot is the least durable part of this answer, since these are exactly the kind of tool features that migrate in and out of a product's own built-in feature set over time; the category and the problem it solves matter more than memorizing today's exact plugin name.

Structured elaboration

1. Realistic placeholder content. A plugin that fills text and image layers with plausible names, dates, and avatars instead of generic filler text or gray boxes. It solves the problem that reviewing a design full of obviously fake content hides real issues, like how a layout handles an unusually long name or an odd date format, that only surface with realistic data.
2. Prototype flow wiring and flow mapping. A plugin that generates prototype connections in bulk from a naming or ordering convention, or that renders an existing prototype back out as a labelled flow diagram. It solves the most error-prone repetitive part of prototyping: hand-wiring a twenty-screen flow hotspot by hotspot, where one missed link is invisible in the file and only surfaces when a usability-test participant dead-ends mid-session with the moderator watching. The flow-map direction solves the mirror problem, that a stakeholder or engineer cannot see a prototype's overall shape by clicking through it one screen at a time, so a generated map is what actually gets reviewed.
3. Accessibility and contrast checking. A plugin that scans a selection or frame for color-contrast issues against a target ratio. It solves catching a text-and-background combination that looks fine on a bright studio monitor but fails a legibility threshold, before it ships rather than after a bug report.
4. Batch renaming and hygiene. A plugin that renames or restructures many layers at once against a pattern. It solves the "sixty layers still named generically" problem in one operation instead of clicking into each one individually.
5. Design-token management. A plugin, or increasingly a design tool's own built-in feature, that syncs named values like color and spacing between the design file and the values engineering references in code. It solves manually retyping a value into code by eye, where a small transcription error quietly diverges design and implementation over time. This last category is a good illustration of why naming one specific plugin is risky: a job that used to require a third-party plugin has, in some tools, moved into a native feature over time. The underlying problem, keeping tokens in sync, is the durable thing to understand, not which piece of software currently solves it.

Runner-up worth a slot on some teams: icon library aggregation. A plugin surfacing a large, searchable collection of icon sets in one place, solving the need for a specific icon, a "refresh" glyph in a particular visual style, for example, without hunting across separate icon-set sites and importing each one by hand. It ranks below the five above because a team with its own published icon set has already solved it internally, and because pulling icons from mixed third-party sets is how visual inconsistency enters a library in the first place; it earns a slot mainly on a team that has no icon set of its own yet.

One scenario to avoid plugins entirely: on a file containing genuinely sensitive, unreleased content, an unannounced product name, real financial figures in a mockup, or anything under confidentiality terms, avoid installing a new, unvetted third-party plugin at all. A plugin can read the content of the file it runs against, and an unmaintained or malicious one is a real, if usually low-probability, data-exposure risk that isn't worth taking for a convenience feature. The same caution applies to long-term maintainability: don't build a critical, team-wide workflow around an obscure plugin from a single independent developer with no visible update history. If it's pulled from the plugin marketplace or simply abandoned, the whole workflow breaks at once; prefer a tool's own native feature when one exists for the same job, and if a plugin is genuinely necessary, pick one that's actively maintained or has an internal owner willing to fork or maintain it.

Worked example

A team's spacing and color values used to live in a token-sync plugin that mapped design styles to a file engineering imported. The plugin lost its maintainer right as an incompatible tool update broke it. Because the team had treated its output as replaceable rather than sacred, hadn't built anything else critical directly on top of the plugin itself, they migrated to the design tool's own native token feature over a single sprint instead of it becoming a blocking outage.

Trade-offs and pitfalls

Chasing every trending new plugin instead of standardizing on a small, team-agreed set creates inconsistent files across designers, where one person's personal plugin habits become an invisible dependency for anyone else who opens that file. A plugin that modifies file content, batch renaming or restructuring, run without reviewing its result first can make unwanted changes at exactly the same scale and speed as wanted ones, so a batch operation's result is always worth reviewing before accepting it, never trusted blindly.

Direct answer. Start from the capacity: derive what fits, define the one job the MVP (minimum viable product: the smallest product that tests the core idea) must prove, sort features with MoSCoW, and agree the cut order before work starts. Then explain cuts in terms of the goal, not preferences.

Capacity (illustrative: 2 engineers, 6 weeks). 2 x 6 = 12 person-weeks. Keep a 20% buffer (time held back for surprises): 12 x 0.2 = 2.4, leaving 9.6 person-weeks to plan.

MoSCoW (Must, Should, Could, Won't have this time; an approach from rapid application development, a style of building software in short cycles) with estimates, for a community app where people post and follow each other:

Musts total 8.0, plus the Should 1.5 gives 9.5, within 9.6. Coulds (2.0) are not in the committed plan; they only start if we are ahead. Check the Must share against the DSDM (Dynamic Systems Development Method) guideline. MoSCoW was created by Dai Clegg in 1994 for rapid application development and is used heavily in DSDM, whose published guidance is typically no more than 60% Must Have effort, measured against the planned effort for the timeframe (Won't items excluded), with around 20% Could Have effort as contingency. Planned effort here is 8.0 + 1.5 + 2.0 = 11.5 person-weeks, so Musts are 8.0 / 11.5 = 69.6%, Shoulds 13.0% and Coulds 17.4%. That is above the 60% guideline, so this plan is at the risky end: confidence that every Must lands is lower than DSDM recommends. (Against the whole 12 person-weeks the Musts are 67%, and against the 9.6 plannable weeks 83%, but neither is the basis the guideline uses.) The 2.4-week buffer is my own addition, not part of DSDM's rule, and it does not fix the ratio; the fix is to narrow Musts before the build starts, for example a simpler profile (1.0 instead of 1.5) and a chronological feed (1.5 instead of 2.0), which brings Musts to 7.0 of 10.5 planned (66.7%), closer to the guideline though still above it, and to keep the buffer for the surprises that remain.

What to cut first if it slips. Reverse order of value. Because the Coulds are not in the committed plan, the first cut is simply not starting them (notifications, then analytics beyond one launch event) and spending that time on the buffer. If the slip continues, cut comments next, keeping likes only. Musts are never cut; if even they slip, move the date or the launch audience, not quality of safety features like report and block.

Choosing in/out. I use a PR/FAQ (a press release and customer FAQ written as if launched). Write the headline first, for example: "Neighbours can now sign up, post, follow each other, see a feed and stay safe with report and block." If a feature is not needed to write that headline, it is not a Must; direct messages do not appear in it, so they are a Won't. Another way to cut is to serve one segment first. Suppose the app has moderators (volunteers who review reports), power users (who post daily) and casual users (who mostly read). Pick the segment whose need is sharpest, for example moderators, who need report and block to keep a new community safe, and give the others a clear later path.

Explaining cuts. Show the table and the rule: "This is what the first version must prove. Each cut buys the buffer that protects the date." Give the owner of each Won't a date to revisit.

Direct answer

Measure two different things on purpose: whether people did the target behavior at all right after exposure, and whether that behavior actually persists once the novelty wears off. Most of the risk in a behavior-change measurement plan is mistaking an initial spike for durable change, so the design has to be built specifically to detect decay, not just a single after-the-fact snapshot.

Structured elaboration

• Immediate metrics: activation of the prototype's core feature in week 1 (for example, logging a workout through it) and completion rate of the first prompted session.
• Sustained metrics: weekly exercise frequency (sessions per week) tracked per user for 12 weeks, defined as the actual primary outcome, plus a plateau check like the share of users still logging at least 2 sessions per week during weeks 8 through 12.
• Cohorting and retention strategy: track weekly signup or exposure cohorts on their own retention curves, comparing each cohort at the same number of weeks since exposure rather than the same calendar week, so a cohort exposed during a January motivation spike isn't compared unfairly against one exposed in March.
• Instrumentation: explicit events like workout_logged {user_id, timestamp, source, duration_min} and prompt_shown / prompt_dismissed, so "used the prototype" can be separated from "exercised at all." This matters because the prototype could simply move logging from an old path to a new one without any real increase in exercise, guard against that by also tracking total exercise frequency across all sources, not just prototype-attributed activity.
• Duration: run at least 12 weeks with weekly check-ins. Behavior-change products commonly show an early spike followed by decline in just the first couple of weeks, a 2-week study would only ever catch the spike.
• Confounders and attribution: compare the treatment cohort's own pre-exposure trend against its post-exposure trend using a difference-in-differences approach, with a matched control group that never gets the prototype providing the counterfactual trend for the same calendar weeks, which absorbs shared confounds like weather or a company-wide wellness campaign hitting everyone at once. Where a clean randomized holdout isn't feasible, a regression-discontinuity design (comparing outcomes for users just above versus just below some pre-existing eligibility cutoff, treating which side of the cutoff someone lands on as effectively random) or an instrumental-variable approach (finding a third factor that affects exposure to the prototype but has no direct effect on exercise frequency itself, then using that factor to isolate the prototype's own effect) is a fallback, but a true randomized holdout of eligible users for the full study window is the cleanest option when it's available.

Worked example

Assume the control group's weekly exercise frequency plateaus around 1.8 sessions per week by week 8, with a standard deviation of 1.2 sessions across users, and the goal is to detect a sustained lift to 2.2 sessions per week at 95% confidence and 80% power:

$$n = \frac{2(z_{\alpha/2} + z_\beta)^2 \sigma^2}{\delta^2}$$

With $\sigma=1.2$, $\delta=0.4$, and using the standard z-score lookup values for 95% confidence and 80% power ($z_{\alpha/2}=1.96$ and $z_\beta=0.84$, so $z_{\alpha/2}+z_\beta=1.96+0.84=2.8$): $n = \frac{2(2.8)^2(1.44)}{0.16} \approx 141.1$, so 142 users per arm who are still reporting data at week 8. A 12-week study realistically loses participants to non-reporting or dropout, assuming 40% cumulative attrition by week 8, enroll with margin: $142 / 0.6 \approx 237$ users per arm at week 0, about 474 total enrolled.

Trade-offs and pitfalls

Measuring only prototype-attributed activity overstates impact if it's cannibalizing an existing logging path rather than creating new behavior, the total-activity guardrail above exists specifically to catch that. Running the study too short mistakes a novelty spike for durable change. And withholding a wellness feature from a randomized holdout group for 12 weeks raises a real fairness question in some contexts, a senior answer should name that trade-off explicitly (even if the resolution is "acceptable because participation is opt-in for a beta") rather than assume it away.

Direct answer

This isn't a single rule, it's a judgment call driven by stakes, time pressure, and whether the struggle is actually productive. My default is a graduated ladder: ask an orienting question first, then narrow the search space with a hint, and only hand over the answer if that hasn't worked or the situation doesn't allow more time.

Decision criteria

• Stakes and time pressure. A production incident, a hard external deadline, or anything safety or compliance critical pushes toward giving the answer sooner. A practice task or routine work with slack in the schedule can absorb more struggle.
• Productive vs. unproductive struggle. Productive struggle looks like forming a hypothesis, trying something, narrowing the possibilities, and making incremental progress, even slowly. Unproductive struggle looks like repeating the same failed attempt, or restating the same confusion without new information. The first is worth protecting, the second isn't.
• Type of gap. If the person is missing a concept entirely, guiding questions can circle for a long time without landing. If they have the concept but haven't applied it here, a nudge is usually enough.
• Trust and frustration level. Visible frustration that's starting to tip into disengagement is a signal to step in, even on a low-stakes task, because the cost of pushing further is now higher than the learning value.

Worked example

A mentee was stuck for a while on why a piece of work was producing an unexpected result. First move: an orienting question ("What did you expect to happen here, and where does the actual behavior diverge from that?"). They could describe the divergence but not explain it, so the second move was a narrowing hint pointing at the specific area to look at, without naming the cause. They investigated that area and found it themselves. If that hint hadn't landed, the next step would have been to explain the underlying cause directly, then ask them to restate it in their own words and apply it once more on a related case, so the session still ends with them exercising the skill rather than just receiving an answer.

Trade-offs and pitfalls

Always rescuing produces a mentee who never builds independent judgment and starts routing every decision through you. Always withholding produces frustration, slower delivery, and eventually disengagement, especially under real time pressure. A common junior mistake is judging "stuck" purely by elapsed time rather than by whether new information is being generated. A more senior habit is calibrating a default line per person (some people need more room, others need more scaffolding early on) and deliberately moving that line as the person gains experience, so the same person gets less hand-holding a year in than they did in week one.