Describe the data model and backend logic for a daily login bonus.

WHAT THIS TESTS: The interviewer wants to see if you can translate a product concept into a minimal, correct data model and state machine. This is a beginner-level question, but it quickly reveals whether you think about idempotency, time, and user-specific context. The psychology of streaks is powerful; Duolingo saw a 60 percent surge in user commitment after introducing iOS streak widgets, and loss aversion means users feel the pain of breaking a streak roughly twice as much as the pleasure of starting one. Because of this emotional weight, backend accuracy matters deeply.

A GOOD ANSWER COVERS: First, the core table: a user_streaks table with user_id, last_login_at as UTC timestamp, current_streak as integer, and maybe longest_streak. Second, the grant logic must be idempotent: when the user logs in, compute the current UTC date and compare it to the stored last_login_utc date. If it is the same UTC day, do nothing. If it is exactly one day later, increment current_streak. If it is more than one day later, reset current_streak to one. Third, timezone handling: never trust the client clock for security, but accept a user_timezone string. The daily boundary for that user is midnight in their timezone, converted to UTC on the server. Alternatively, run a scheduled job at each user's local midnight. Fourth, leap years are a non-issue because UTC day boundaries and date math libraries handle February 29 automatically; you should not write custom leap-year logic. Fifth, mention a streak_freezes or grace_period table if the product allows it, because loss aversion is strong and a 60 percent commitment lift is fragile if a single server hiccup breaks a long streak.

COMMON WRONG ANSWERS: Storing timestamps in local time without timezone offsets. Using a naive 24-hour rolling window instead of calendar days, which breaks during daylight saving transitions and causes streaks to expire at weird times. Forgetting idempotency so that retrying a login request double-increments the streak. Writing custom leap-year detection instead of relying on standard date libraries. Ignoring the distinction between the user's local day and the server's UTC day, which leads to off-by-one errors for half the planet.

LIKELY FOLLOW-UPS: How would you handle streak freezes or grace periods after a missed day? How would you backfill streak data if you add this feature retroactively? How would you scale the daily check for millions of users without hitting a single database row per user at exactly midnight? What happens if the user travels and their timezone changes while a streak is active?

ONE CONCRETE EXAMPLE: Suppose a user in Tokyo with timezone Asia/Tokyo logs in at 11 PM JST on March 1. That is 2 PM UTC on March 1. The server records last_login_utc as 2024-03-01 14:00:00Z. They log in again at 1 AM JST on March 2, which is 4 PM UTC on March 1. Because both fall within the same UTC day, the streak should NOT increment yet. If they log in at 1 AM JST on March 3, that is 4 PM UTC on March 2. The server compares UTC dates March 2 versus March 1, sees a one-day gap, and increments the streak. Leap year 2024 means February 29 exists, but the date library simply maps 2024-02-29 to 2024-03-01 correctly with no custom code.

Source: Smashing Magazine