How would you instrument events and query a 3-invite aha moment?

WHAT THIS TESTS: This tests your ability to bridge product analytics instrumentation with backend data architecture for stateful, time-windowed cohorts. The interviewer cares whether you understand the difference between event-level telemetry and derived user state, and whether you can design a system that tracks multi-session behavior without collapsing the time dimension.

A GOOD ANSWER COVERS: First, taxonomy design: propose a Teammate Invited event using a consistent naming convention like Noun plus Past-Tense Verb from the user's perspective, following Amplitude's recommended standard. Attach event properties such as recipient_id, invite_channel, and a server-generated timestamp. Also track a User Signed Up event to establish t-zero for the seven-day window. Second, explain why a user property like total_invites is insufficient: user properties are traits that persist until overwritten, so they cannot naturally enforce a rolling or fixed seven-day expiration, and they conflate lifetime behavior with first-week behavior. Third, backend processing: describe a pipeline that ingests raw events and computes per-user aggregates inside a bounded window. In batch, this is a SQL query grouping by user_id and counting Teammate Invited events where event_time is between signup_time and signup_time plus 168 hours. In streaming, use keyed state in Flink or ksqlDB with a seven-day event-time window that emits when the count reaches three. Fourth, materialization: store the result in a cohort table or feature flag store so PMs can query it without scanning raw events. Mention that the pipeline must handle late-arriving events and backfills.

COMMON WRONG ANSWERS: A red flag is proposing only a frontend analytics call like analytics.track without server-side validation, which misses invites sent via API or mobile. Another red flag is storing the count in a user property updated on every invite; this makes the metric irreversible and includes invites from week two onward. A third red flag is ignoring identity resolution, such as anonymous users who sign up after starting the invite flow, which would break the user session linkage.

LIKELY FOLLOW-UPS: The interviewer might ask how you would handle invites that are sent but not accepted, whether the aha moment should count unique invitees or total invites, how to backfill this cohort for historical users, or how to reduce query latency from minutes to seconds for a dashboard. They might also ask how to A/B test onboarding changes against this cohort definition without waiting seven days for results.

ONE CONCRETE EXAMPLE: Imagine a user signs up at Monday 09:00 UTC. They invite one teammate at 10:00, another at Wednesday 14:00, and a third at Friday 08:00. Your event stream captures three Teammate Invited events. A nightly Airflow job runs SQL that selects user_id from events where event_name equals Teammate Invited and event_time is less than or equal to signup_time plus interval 168 hours, groups by user_id, and keeps only those having count greater than or equal to three. That user_id lands in the aha_moment_cohort table with achieved_at set to Friday 08:00. If the same user invites a fourth teammate on day ten, the cohort membership does not change because the query window is fixed.