"What is your favorite product and why?"

This warmup is a product-taste test, not an enthusiasm contest. The failure mode is gushing about a product you use. The bar is: can you reason like someone who shipped it? One framing from 2026 interviewer research captures it cleanly: padders name the product, builders name the decision.

What changed in 2026

Feasibility is no longer the constraint. LLMs, agents, and no-code tooling mean almost anything can be built now. So when an interviewer asks this question in 2026, they are not checking whether you can describe usability (any decent product is baseline usable). They are checking two things:

• Viability: does this product solve a problem people genuinely pay to have solved, and why do the unit economics hold?
• Lovability: does it nail the real job and earn its place by knowing what to leave out?

That shift also explains why top companies at Google, Meta, and Stripe increasingly fold this question into a product-sense or improve round rather than treating it as a standalone warmup. Your answer is setup for “how would you improve it?” Plant the seed.

The structure: four moves

Each move earns its place. Skipping one is what separates a user review from a product analysis.

1. Name the user and the real job. Not “everyone” as the user, and not the surface task as the job. Splitwise’s user is a group of friends. The job is not “track expenses,” it is “preserve the friendship by removing money awkwardness.” That distinction is the whole answer in miniature. It signals you understand jobs to be done rather than feature catalogues.

2. Name the non-obvious decision (especially what they chose NOT to build). This is the highest-signal move. Builders observe constraints and deliberate restraint; fans list features. Splitwise deliberately does not move money. Staying a ledger keeps it simple and trusted. A payments pivot would add friction, regulatory liability, and a support surface the team did not want. Naming that constraint shows you understand product strategy, not just product appreciation. “What they chose not to build” is the one observation that almost no candidate makes and almost every interviewer notices.

3. Name one honest weakness with a specific failure mode. Not “the onboarding could be better.” Name the exact moment it breaks: the nudge-to-settle loop surfaces too early for groups with long-running tabs, which makes the app feel accusatory rather than neutral. A vague improvement signals you have not used it hard enough to find where it actually fails.

4. Propose one testable fix tied to a metric. The fix should be narrow enough to A/B test and tied to an outcome you can measure: test a user-controlled settle cadence (weekly, monthly, or on-demand) against the current default nudge, measuring whether it reduces the “settled outside the app” behavior that costs Splitwise visibility into group health. This is also your setup for the follow-up question; plant it deliberately.

One final check before you choose a product: can you name who pays and why the unit economics hold? If you cannot answer those two questions, pick a different product. Viability awareness is now part of the bar; loving a product without being able to explain how it survives as a business is a signal interviewers clock immediately.

A second worked example: an AI-native product

In 2026, picking an AI-native product is a first-class option. It opens a dimension that consumer app answers cannot match: model-level tradeoffs.

Picking something like Perplexity, Cursor, or Granola lets you demonstrate understanding of hallucination risk, trust design, confidence thresholds, cost-per-query, and when NOT to invoke the model. None of that comes through with a consumer app answer.

“Perplexity. The user is someone doing research who distrusts a single confident answer. The job is not ‘search the web,’ it is ‘calibrate how much to trust this result.’ The non-obvious decision is to show per-claim citations rather than a single synthesized answer, which accepts a more complex UI in exchange for letting users verify the model’s confidence themselves. The weakness is citation density: on factual, time-sensitive queries the citation panel is overwhelming and slows task completion. I would test progressive disclosure of sources (collapsed by default, expanded on hover) against the current always-visible panel, measuring re-query rate and task completion time.”

That answer shows you understand the latency-vs-trust tradeoff the team made. A consumer app answer cannot demonstrate any of that.

What to avoid

Picking a direct competitor. Do not name TikTok if you are interviewing at Meta/Instagram. It reads as a flex, not insight.

Picking a product with no viability story. If you cannot say who pays and why the unit economics hold, choose a different product. Love is not enough.

Picking the company’s own product. This sometimes works if you have genuine, specific criticism and a testable fix. It almost always reads as flattery, and interviewers see through it immediately.

User-review mode. Listing features you enjoy is a review. It contains no user segment, no job, no deliberate constraint, no weakness, and no business model awareness.

What it signals

How you talk about a product you admire predicts how you will reason about the one you would build for them. The strongest answers show viability awareness (who pays, why it works as a business) and lovability judgment (it earns love by nailing the real job and knowing what to leave out). The answer is the setup for the follow-up. Anticipate “how would you improve it?” and make sure your weakness and fix are already in the room.

For deeper context on why viability and lovability are the bar in 2026, see feasibility is free and lovable, not just usable.