Meta RPM Interview — WhatsApp Contact Discovery in India

It tests whether you can take an open product prompt, in this case improving WhatsApp contact and group discovery for first-time smartphone users in India, and reason like a product manager rather than a feature list. The interviewer is checking that you pick one prioritized user segment and hold it, define a success metric from scratch with a real denominator and a guardrail, name tradeoffs out loud and kill an option with a reason, and ground the design in the India constraints that actually bind, such as sparse address books, low-end Android, data cost, connectivity, and regional language. Recited framework names do not score; structured reasoning the interviewer can follow does.

Start by restating the user and the goal before any solution, then list a few candidate user segments and pick one with an explicit reason, for example a first-time smartphone owner in a Tier 3 town with an almost empty address book. State the job that person is trying to do, define what success looks like as a metric you build from scratch with a denominator and a guardrail, then propose two or three ideas and choose between them by naming the tradeoff and killing the weaker option. Close by saying what you would measure and how you would test it. Keep narrating so the interviewer can follow your logic in real time.

The frequent failures are jumping straight to a feature before naming the user and the goal, giving vague or overlapping segments so follow-ups collapse, and picking a success metric like total messages or DAU that rises even when the new user is still lost. Others recite a framework name without adapting it to WhatsApp or India, focus on features instead of the user problem and the business outcome, ramble without structure, or answer as if for a US power user and never mention a low-end phone, a data pack, or a regional language. Each of these maps to a real no-hire pattern from Meta interview reports.

It behaves like a real Meta RPM loop interviewer in the ways that matter: it interrupts when your answer drifts, asks one sharp question at a time, probes at least once before moving on, and never tells you whether an answer was good. The differences are that it is available on demand, it stays strictly in the product sense domain for the full session, and it produces a written transcript-backed scorecard afterwards that names the exact moment your segmentation or metric broke. It will not coach you during the round or hint at an outcome, exactly like the real loop.

Your transcript is evaluated against the specific signals this round cares about: whether you anchored on one prioritized segment, whether your success metric had a denominator and a guardrail, whether you named and resolved a tradeoff, whether you used the binding India constraints, and whether your reasoning was structured enough to follow. Each dimension is scored independently from the transcript text only, so delivery style, accent, and filler words do not count. The scorecard quotes the actual moments that earned or lost points so the feedback is concrete rather than a single number.

Use the thinking time to restate who the user is in one sentence and what goal you are optimizing, then sketch two or three candidate segments so you can pick one out loud with a reason. Do not start listing features. Have one sentence ready on why the cold-start screen is empty for this person, since the whole problem hinges on the sparse address book. Decide early what success would even mean for them, because the interviewer will ask you to define the metric from scratch and will push hard if it has no denominator or guardrail.

Expect the interviewer to push that surfacing suggested contacts leaks the contact graph and will not survive WhatsApp's privacy posture or Indian regulatory scrutiny on cross-Meta data sharing. Do not abandon your goal under that pressure. Acknowledge the constraint, then rework the proposal so discovery happens through channels the user already controls, such as group invite links, mutual-group context, or opt-in flows, rather than inferred social-graph suggestions. The interviewer is testing constraint recalibration: whether you can keep the user goal while respecting a hard limit, not whether you can defend the original idea stubbornly.

A strong answer names one user, for example a first-time smartphone owner in a Tier 3 town with three contacts saved, states the job they are hiring WhatsApp for, and never drifts from that person. It defines success as a clear metric with a denominator and a guardrail, for instance the share of new users who reach a first meaningful conversation within seven days, guarded against spammy group adds. It proposes a couple of ideas, picks one by naming what it sacrifices, and reasons explicitly about low-end Android, data cost, connectivity, and regional language as binding constraints, not afterthoughts.

No. The round rewards defining metrics from first principles, not reciting WhatsApp's real dashboards. The interviewer explicitly expects you to build a success metric from scratch rather than choose from a list, so inventing a well-reasoned metric with a denominator and a guardrail scores better than naming a real internal metric you cannot justify. What you do need is a working mental model of how contact discovery functions, that it runs on the phone address book and phone-number identity, because the entire problem comes from that address book being nearly empty for a first-time user.

India is the binding context, not flavor. The target user is often on a low-end Android phone with limited storage, paying for a metered data pack, on intermittent connectivity, and more responsive to regional-language content than English by roughly two to one in Tier 2 and Tier 3. Group invite links and click-to-WhatsApp entry points are the main non-address-book discovery channels for these users. A generic answer that assumes reliable data, a mid-range phone, and English UI will get interrupted. Treat language, device, data cost, and connectivity as first-class design variables that shape which discovery mechanism is even viable.

When the round closes you receive a transcript-backed scorecard rather than a verbal verdict. It breaks down how you performed on segment discipline, metric authorship, tradeoff reasoning, India-constraint grounding, and structured communication, and it quotes the specific moments where your answer strengthened or weakened. There is no live feedback during the session and the interviewer never hints at an outcome, mirroring the real Meta loop where recruiters often give no reason. The point of the scorecard is to show you exactly where the segmentation or metric broke so you can fix it before the real round.