Anyone can point at a chart that went up. The entire growth interview is about the sentence after that: how do you know it went up because of you?

Every question below is a version of that. Which is why growth loops feel harder than the job description suggests — the tactics are googleable, and the thing being tested is whether you'll claim a win you can't defend. Interviewers in this field have all been burned by a number that turned out to be seasonality, a tracking change, or a launch that shipped the same week.

1
Question under every answer: how do you know it was you
2
Ways a test lies: run too short, or the wrong metric
0
Credit for a win you can't explain

Choosing what to move

The opening round, usually a live scenario about a funnel you've never seen.

  1. Here's our funnel. Where would you look first?
  2. Activation is weak and acquisition is expensive. Which do you fix?
  3. What makes a good growth hypothesis, and what makes a bad one?
  4. How many experiments should a team have running, and what actually limits it?

Saying it out loud: question 2 is a prioritisation question and the answer that scores does arithmetic out loud rather than picking a philosophy: "I'd rather fix activation first in most cases, because acquisition spend flows through it — a ten percent activation gain makes every future dollar of acquisition worth more, and it compounds. But it depends on volume: if only two hundred people a month reach activation, I can't learn anything there quickly, and I'd have to buy traffic first just to get a readable signal." The second half is the part that shows you've actually run tests rather than read about them.

Question 3 has a specific answer worth having ready. A bad hypothesis is a change — "make the button green". A good one contains a belief that can be wrong: because we think people abandon here for this reason, if we do X then Y will move. If a hypothesis can't lose, it wasn't one.

Designing a test that can be wrong

The methods round. Where a lot of otherwise strong candidates get found out.

  1. Walk me through designing an A/B test for a signup flow.
  2. How do you decide sample size and how long to run it?
  3. What would make you stop a test early?
  4. How do you test something only two hundred users a month ever see?

Saying it out loud: question 7 is the integrity question of the whole loop. The honest answer names the asymmetry: "I'd stop early for a bug or something actively harming users, and I'd have said before launching what would count. I wouldn't stop early because it's winning — peeking at a test and stopping on a good day is how you ship things that do nothing, and I've seen a 'significant' result evaporate when it ran the full two weeks. So I'd rather fix the run length in advance and hold myself to it."

Question 8 is the realistic one, because most companies don't have the traffic for clean testing. Interviewers want to hear that you know when not to A/B test at all — and would reach for a before-and-after with a holdout, a painted-door test, or five user interviews, rather than running an underpowered test and pretending the result means something.

The thread through both sections: every strong answer above included a way the candidate could be proven wrong. A hypothesis that can lose. A stopping rule set in advance. A sample size that admits when it's too small. That is the entire signal growth interviewers are hunting for — not because rigour is virtuous, but because a growth manager who can't be wrong will spend a year shipping things that did nothing and reporting them as wins.

Reading a result

The section with the most wrong answers that sound right.

  1. The variant won by three percent. Do you ship it?
  2. The test is significant, but the metric you actually care about didn't move. Now what?
  3. What's a novelty effect, and how do you tell it from a real gain?
  4. Two tests both won. You shipped both and got nothing. What happened?

Saying it out loud: question 9 is a trap for people who treat significance as a green light: "It depends on the confidence interval and what the change costs to maintain. Three percent with an interval that crosses zero isn't a win, it's a maybe. And even if it's real, three percent on a step that only two percent of users reach is not worth permanent complexity in the signup flow. So I'd ask what it costs us to keep before I ask whether it won."

Question 12 is the best question in the list because it has a real answer: the two tests interacted, or both moved a shared metric that was already saturated, or the aggregate was never additive to begin with. Candidates who have only run tests in isolation don't have this experience, and the ones who have will say it immediately.

When you can't test

Senior weighting. Most of the important decisions in this job are untestable.

  1. The change is too big to A/B test. How do you de-risk it?
  2. How do you measure something with a long feedback loop, like retention?
  3. Brand and word of mouth aren't testable. Do they matter to you?
  4. Leadership wants the result before the test has finished. What do you say?

Saying it out loud: question 15 is a values question and the defensive answer hurts you. Say what you actually believe: "They matter, and I can't run a clean test on them, so I'd be honest about which of my decisions are evidence-based and which are judgement. What I'd avoid is dressing up the judgement calls in numbers to make them look like the others — that's how teams lose trust in the numbers that are real."

Question 16 rewards a concrete alternative rather than a lecture on statistics. Interviewers want to hear you'd offer what is known so far, with the honest error bars, and a date — not a refusal, and not a number you'd have to retract.

What you do with a loss

The last round, and quietly the one that decides the level.

  1. Most experiments fail. What do you actually do with the ones that do?
  2. Tell me about an experiment you were certain about that lost.
  3. How do you keep a team from getting demoralised by a losing streak?
  4. What's the most useful thing you learned from a channel that stopped working?
What sounds inexperienced

The loss as a footnote

“It didn't win, so we moved on to the next test in the backlog.”

Efficient, and it throws away the only thing the test produced. It also tells the interviewer your backlog is a list of tactics rather than a set of beliefs — because if it were beliefs, a loss would have changed one.

What sounds senior

The loss as information

“It lost, which told us the friction wasn't where we thought — people weren't dropping out because the form was long, they were dropping out before they believed it was worth filling in. That killed three other tests in the backlog built on the same assumption, and pointed the next quarter at the page before the form.”

One losing test that invalidates three planned ones is worth more than a small win, and saying so out loud is the clearest seniority signal available in this interview.

Saying it out loud: question 18 needs a real example where you were confident and wrong, and it needs the confidence to be visible before the result. An answer where you were mildly curious and it didn't work isn't the question. Interviewers are calibrating how you hold beliefs, and the useful version ends with what you now check earlier because of it.

The two roles that sit next to this one

Growth overlaps with marketing and with product marketing, and companies use the titles loosely. It's worth knowing which one you're actually interviewing for, because the same answer can read as rigorous in one room and as slow in another.

If the role is really about channels, budget and a number for the quarter, the neighbouring list is Marketing Manager Interview Questions. If it's about positioning, launches and the story, it's Product Marketing Manager Interview Questions. Asking which one it is, early in the loop, is a good question rather than an awkward one.

One more practical thing: nearly every growth loop has a moment where someone asks you to pull the number yourself. Being able to talk through a query out loud, while someone watches, is its own skill: how to talk through a SQL query live.

Practical target: take question 18 and tell it out loud in ninety seconds, with the confidence stated before the result. If the story is more comfortable to tell than it was to live through, it's probably the wrong story — pick the one that still slightly stings, because that's the one with a real change at the end of it.