Design an A/B test system for homepage headlines without deployments

Tests decoupling experiment configuration from deploys via a headless CMS and feature flagging. A strong answer covers variation containers, server-side bucketing, conversion tracking, and marketer-controlled copy swaps.
What's really being asked
This question tests your ability to architect a zero-deploy experimentation pipeline. The interviewer wants to see that you understand separation of concerns between content management, experiment configuration, and application code. Specifically, they are looking for server-side variation selection to avoid layout shift or flash of unstyled content, and a clean event tracking loop that attributes conversions to the correct variant without requiring a new build or release cycle.
The full answer
First, a headless CMS such as Contentful stores the headline copy outside the codebase, often using a variation container content type that nests two or more entries under a single reference field. Second, an experimentation platform like Optimizely manages the experiment rules, audience segments, and traffic allocation, exposing a datafile that the application consumes. Third, a server-side proxy or middleware fetches the CMS entry, uses the Optimizely SDK to bucket the user deterministically based on a stable user identifier, and resolves the variation container to the specific headline variant before the response reaches the client. Fourth, the frontend renders the resolved headline directly from the server payload, eliminating any client-side swapping. Fifth, conversion events such as sign-up button clicks are tracked via an event SDK call or a webhook that attributes the action back to the experiment and variation identifiers.
The mistakes people make
A red flag is suggesting that engineers hardcode both headlines behind a feature flag and redeploy to toggle them; this misses the marketer self-service requirement. Another red flag is describing a client-side-only approach where JavaScript swaps the headline after the page loads; this causes cumulative layout shift, flicker, and unreliable attribution. Proposing to store experiment state in a simple database table without an experimentation SDK is also weak because it forces you to rebuild bucketing, audience targeting, and statistical analysis from scratch.
What usually comes next
The interviewer may ask how you handle caching when content changes mid-experiment, how you ensure consistent bucketing across sessions and devices, or how you prevent SEO issues when headlines vary by user. They might also dig into how you would roll out the winning variant to 100 percent traffic without a deploy, or how you would handle multiple concurrent experiments on the same page without interaction effects.
A concrete example
Imagine a React application served by a Node proxy. The proxy requests the homepage hero section from Contentful and receives a variation container with two nested entries: headline A says "Start Your Free Trial" and headline B says "Get Started in Seconds." The proxy passes the user's cookie ID into the Optimizely SDK, which returns variant B. The proxy then replaces the variation container with the resolved entry in the JSON response before sending it to the React app. When the user clicks sign up, the frontend calls Optimizely's track method with the event key "signup_completed," attributing the conversion to variant B. The marketing team updates the copy or traffic split in Optimizely and Contentful without ever opening a pull request.
Interview question
What is the main reason a headless CMS is used to store headline variants in a zero-deploy A/B testing system?
- a.It handles statistical analysis and traffic allocation for experiments
- b.It performs server-side user bucketing to prevent layout shift
- c.It tracks conversion events and attributes them to specific variants
- d.It lets marketers update headline copy without requiring a code deploymentCorrect
Why? this is the answer
The headless CMS separates content from application code so marketers can update headlines without engineering deploying new builds. While server-side bucketing prevents layout shift, that is performed by the experimentation SDK in the server middleware, not the CMS.
Just read this? Test yourself on what you have been reading.
Read the original → contentful.com
- #experimentation
- #cms
- #ab-testing
- #architecture
- #feature-flags
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on experimentation — each one lists the topics its interview covers.
See open roles