How do you determine if a user is 'new' for a setup guide?
This tests whether you separate account age from user state for onboarding. Good answers compare created_at (brittle) with a persistent flag (idempotent) and consider milestones. A red flag is using a timestamp as a permanent new proxy without managing reruns.
What's really being asked
This question evaluates whether you can separate the concept of account age from user readiness and product state. Interviewers want to see that you understand onboarding is an ongoing system rather than a one-time event, and that new is a product definition that can change based on roles, milestones, or feature adoption rather than a fixed timestamp.
The full answer
A strong response walks through at least three methods in order of robustness. First, using a created_at timestamp. It is easy to query and requires no extra state, but it is brittle. If you backfill users, restore data, or need to re-show the guide after a redesign, the timestamp does not change and the logic breaks. Second, using a dedicated has_seen_setup_guide boolean or a versioned flag. This is idempotent and precise because it records the interaction itself, but it introduces a write path and storage cost. You must also decide when to flip it: on render, on dismiss, or on completion. Third, milestone or activation-based gating. Instead of asking when the user was created, ask whether they have performed a key action that makes the guide irrelevant. This aligns with the principle that onboarding should guide users to repeatable value and can support segmented flows for different roles. A senior candidate also mentions combining these, such as using a timestamp for the initial query and a flag for persistence, or wrapping the logic behind a feature flag for experimentation.
The mistakes people make
The biggest red flag is insisting that created_at is sufficient without discussing what happens on data migrations, reruns, or guide updates. Another weak pattern is proposing local storage or a cookie as the source of truth for a logged-in experience, which fails across devices and incognito sessions. A third mistake is treating onboarding as a single checklist to complete rather than an evolving system that spans multiple sessions.
What usually comes next
The interviewer may ask how you would handle showing an updated guide to existing users, how you would support A/B testing the guide placement, or how you would prevent the guide from flashing on screen before your client-side check resolves. They might also ask how you would personalize the guide for different user roles or use cases.
A concrete example
Suppose you ship a setup guide that prompts users to invite a teammate. If you gate it on created_at within 24 hours, a user who signs up at 11 PM and returns at 9 AM the next day might never see it. If you use a has_seen_setup_guide flag set to false by default, you can show it across sessions until they dismiss or complete it. Better yet, you only show it while the user has zero invites sent, turning the guide into a milestone-driven prompt that disappears naturally once they have achieved that early win.
Interview question
Which approach is most robust for deciding whether to display a setup guide to a returning user?
- a.Storing a dedicated has_seen_setup_guide flag in the user's server-side recordCorrect
- b.Showing the guide only until the user completes a one-time onboarding checklist
- c.Tracking whether the guide was dismissed using browser local storage
- d.Checking if the account created_at timestamp falls within a recent window
Why? this is the answer
A server-side flag records the actual interaction and remains accurate across data migrations, device changes, and guide redesigns. Relying on created_at is brittle because that fixed timestamp cannot be reset when you need to rerun onboarding or backfill users.
Just read this? Test yourself on what you have been reading.
Read the original → appcues.com
- #growth
- #onboarding
- #experimentation
- #product-engineering
- #state-management
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on growth — each one lists the topics its interview covers.
See open roles