Design a streak-saver mechanism
modeling stateful engagement with behavioral nuance.
timezone-aware streak state, capped saver inventory with replenish rules, and A/B testing forgiveness against retention plus guardrails.
What's really being asked
This evaluates state modeling for a recurring time-based feature, timezone correctness, and the maturity to test a motivation policy against retention rather than a vanity metric.
The full answer
State: per user store current_streak, longest_streak, last_active_date evaluated in the user's local timezone, and saver_balance. A day counts when a qualifying action occurs; the streak increments if the last active day was yesterday, resets if a gap appears unless a saver covers it. Rules: cap saver inventory, define how savers are earned or replenished, decide whether a saver auto-applies on a miss or must be claimed, and bound how many consecutive days a saver can bridge. Testing: treat forgiveness generosity as the variable; randomize users across policies and measure D7 and D30 retention as primary, with guardrails on daily active days per user and on streak inflation so you do not win retention by making streaks meaningless.
The mistakes people make
Storing dates in UTC and breaking streaks for users near midnight in their timezone. Unlimited free savers, which removes the loss that drives the behavior. Optimizing for average streak length, a metric easily gamed by generosity. No guardrails, so a policy boosts a vanity number while hurting real retention.
What usually comes next
How do you prevent travel and timezone changes from unfairly breaking streaks? How do you avoid savers becoming a pay-to-win mechanic? How long to run the test given retention is the metric?
A concrete example
A user with current_streak 12 and saver_balance 1 misses Tuesday in their local timezone. The system consumes one saver, keeps the streak at 12, and notifies them. In the experiment, one arm grants one saver per week, another grants three; both are evaluated on D30 retention with a guardrail that median real active days does not drop.
Interview question
Why is 'average streak length' a poor primary metric for choosing a streak-saver forgiveness policy?
- a.It is impossible to A/B test a streak feature
- b.A more generous policy inflates streak length while potentially cheapening motivation and not improving real retentionCorrect
- c.Average streak length is not affected by the saver policy
- d.Streak length cannot be measured accurately across timezones
Why? this is the answer
Generosity trivially inflates streak length without proving better retention, so it is gameable; retention with guardrails is the honest objective. The policy clearly does affect streak length.
Just read this? Test yourself on what you have been reading.
- #engagement
- #gamification
- #retention
- #ab-testing
- #state-modeling
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
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. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles