Skip to content
tezvyn:

Describe how you'd implement an A/B test for a landing page headline

Source: optimizely.comEasyHow cards are made

Describe how you'd implement an A/B test for a landing page headline
Summary

Experiment integrity beyond DOM swaps.

Key points

Mention deterministic bucketing, anti-flicker rendering, tracking with variant IDs, and sample-size planning.

Watch out for

Swapping headlines client-side after paint biases data and hurts UX.

What's really being asked

This question assesses whether you treat experimentation as a full-stack data integrity problem rather than a front-end cosmetic task. Interviewers at the senior level want to see that you understand randomization, attribution, performance, and statistical validity, even when the prompt only asks about an H1 tag.

The full answer

First, deterministic bucketing. You need a rule that assigns a user to variant A or B consistently across sessions, usually by hashing a user ID or cookie and splitting by percentage. Second, anti-flicker rendering. The headline should be rendered server-side or the page should be hidden until the variant is applied, because swapping text after paint creates layout shift and invalid exposure data. Third, event instrumentation. You must fire an exposure event when the user sees the variant and a separate conversion event when they sign up, with both payloads containing the experiment name and variant ID so analysts can join them. Fourth, success metrics and sample size. You should define the primary metric up front and calculate how many visitors or conversions you need to reach statistical significance before the test begins. Fifth, SEO and performance guardrails. Search engine crawlers should typically receive the control version, and the experiment should not regress Core Web Vitals.

The mistakes people make

Relying on a client-side script that waits for the DOM to load and then swaps the headline text. This causes a visible flash of original content, biases the data because users may convert before the swap completes, and breaks attribution if the analytics event fires too early. Another red flag is suggesting that users get a new variant on every refresh, which destroys session consistency and makes conversion tracking meaningless. Declaring a winner after a few hours or a handful of sign-ups without mentioning p-values, confidence intervals, or minimum detectable effect also signals weak analytical rigor.

What usually comes next

How would you handle this if the headline change needed to be indexed by search engines? What if the sign-up happens on a different subdomain or in a mobile app days later? How do you prevent stakeholders from peeking at early results and stopping the test as soon as one variant temporarily leads? These probe whether you understand cross-platform attribution, SEO implications, and experiment governance.

A concrete example

Imagine a React landing page served by Next.js. The experiment assignment happens at the edge or during server-side rendering so the HTML arrives with the correct H1 already in place. The client fires an exposure event to Segment or Amplitude once per session. The sign-up button triggers a conversion event carrying the experiment key and variant name. The team agrees to run until at least one thousand conversions per variant or two full business weeks, whichever comes last, and uses a chi-squared test or a sequential testing engine to evaluate results.

Interview question

You need to deploy a headline A/B test on a landing page. Which setup best balances statistical validity, attribution accuracy, and user experience?

  • a.Hash a user ID or cookie to lock the user into one variant across sessions, render the headline server-side or before paint, and include the variant ID in exposure and conversion events.Correct
  • b.Randomly assign a variant with a client-side script that runs after the DOM loads, swapping the headline text on each visit.
  • c.Run the test until one variant reaches 100 sign-ups and declare it the winner based on the higher raw count.
  • d.Serve the headline via server-side rendering but re-bucket the user on every page refresh to increase the sample size.
Why?

Deterministic bucketing and server-side rendering prevent flicker and ensure consistent attribution, while tagged events let analysts join exposures to conversions. Option B is wrong because client-side swaps after paint create layout shift and users may convert before the variant is applied, biasing results.

Just read this? Test yourself on what you have been reading.

Read the original → optimizely.com

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.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on ab-testing — each one lists the topics its interview covers.

See open roles