Architect a configurable, goal-based onboarding flow

WHAT THIS TESTS This checks whether you can design for change. The naive solution hardcodes a branch per goal in the client; the strong solution treats the flow as data the backend serves and the product team configures. The interviewer wants the server-driven UI pattern and a clear configuration story.

A GOOD ANSWER COVERS First, capture the goal: a selection screen writes the user's chosen goal to their profile. The backend owns flow logic. Store flow definitions in a configurable source, a database or CMS, keyed by goal. A flow definition is an ordered list of steps; each step references a component type, its content, and the call-to-action. When onboarding starts, the client requests the flow for the user's goal and the backend returns the appropriate definition. The client is a generic renderer: it holds a registry mapping component types to actual UI widgets and walks the returned steps, rendering each from its data without knowing about specific goals. This is server-driven UI. Because the flow lives in configuration, the product team can reorder steps, change copy, or swap CTAs through an admin tool with no app release, and you can target different flows or run experiments by varying the definition returned. Validate definitions against a schema so a bad config cannot crash the client, and version them for safe rollout.

COMMON WRONG ANSWERS Hardcoding if goal equals X show these screens in the client, so every change needs an engineer and a deploy. Putting flow logic in the frontend rather than the backend. Returning fully rendered HTML instead of a structured definition, losing native rendering and validation. Skipping schema validation, so a malformed config breaks onboarding.

LIKELY FOLLOW-UPS How do you prevent a bad config from crashing the app? Schema validation, sane fallbacks, and versioning. How do you A/B test flows? Return different definitions by experiment assignment. How do you handle a new component type the old client does not know? Graceful fallback and client capability checks.

ONE CONCRETE EXAMPLE A user picks the goal lose weight. The client requests the onboarding flow and the backend returns a definition: a goal-confirmation step, a meal-preferences step, and a CTA to log the first meal, each as typed components with content. The client renders them from its component registry. Later the product team, seeing drop-off, reorders the steps and changes the CTA copy in the admin tool, and new users immediately get the updated flow with no release.