Dataford
Interview QuestionsInterview GuidesExperiencesCoaching
New
Pricing
Get started
Dataford
Popular roles
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Browse
Browse All RolesEvery role hub, from analyst to MLBrowse All CompaniesCompany-specific interview loopsAll Interview GuidesThe full guide library
Top questions by role
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Top questions by skill
SQLPythonStatisticsMachine LearningA/B TestingSystem DesignGenerative AIProduct SenseMetricsBehavioral
Browse all questions →Try a mock interview
Experiences
Practice
Mock InterviewsTimed interview simulations with feedbackCoaching1:1 coaching with people at your target companiesSuccess PathYour 6-week structured planModulesCurated lessons by topicWebinarsTalks from ex-Big Tech data leadsPlaygroundA free-form scratch editor
Learn
BlogInterview strategy and career adviceTech Job Market ReportHiring trends across data and AI rolesFor UniversitiesDataford for career centersAbout DatafordWho we are and how we build
Pricing
Build my plan

Guardrails for Checkout Experiment

MediumA/B Testing & Experimentation00:00
Practice interviewer
In session
5 left
00:00

Your question is Guardrails for Checkout Experiment. Take a moment with it on the right.

Talk me through your thinking if you like. When you're confident, submit your answer and I'll grade it like a real screen (7/10 or better passes).

You need to log in / sign up to chat or submit.

Problem

Context

ShopNow is testing a redesigned checkout page intended to reduce friction and increase completed purchases. Because checkout is a critical path, the team wants an experiment design that explicitly protects overall system performance while still measuring business impact.

Hypothesis Seed

The new checkout removes one form step and prefetches payment options earlier in the flow. Product expects this to improve purchase conversion, but engineering is concerned that extra client-side requests could increase page latency, backend load, and payment failures.

Constraints

  • Eligible traffic: 600,000 checkout sessions per day
  • Maximum experiment duration: 14 days
  • Allocation can be ramped, but final steady-state split should not exceed 50/50
  • Baseline checkout completion rate: 48%
  • The smallest business-relevant lift is 1.5% relative in checkout completion
  • A false positive is expensive because a bad launch can degrade revenue and site reliability during peak traffic
  • A false negative is acceptable if it avoids shipping a risky experience

Deliverables

  1. Define the experiment hypothesis, the primary success metric, and 2-4 system-performance guardrails that would prevent shipping a harmful variant.
  2. Calculate the required sample size for the primary metric using an explicit MDE, and estimate whether the test can finish within the 14-day limit.
  3. Choose the unit of randomization, allocation plan, and duration; explain how your design avoids contamination and captures weekly traffic patterns.
  4. Pre-register the analysis plan: statistical test, peeking policy, treatment of guardrails, and how you will handle any mismatch between unit of randomization and unit of analysis.
  5. State a clear ship / don’t-ship / iterate rule that respects both the primary metric and guardrails, and identify key pitfalls that could invalidate the result.