How to master a case interview at Adapty

Every role at Adapty includes a live case interview, whether you're applying to lead a product team, write backend code or run recruiting. It's the stage candidates tend to worry about most, and it's also the one where we learn the most about how someone actually works, so it seemed worth explaining properly.

I'm convinced that any business is 99% execution (the hard, often monotonous kind) and 1% ideas, timing and luck. That's why the question underneath all of our interviews is whether you can take a broad problem and actually get it done. Your CV and the HR interview tell us what you've done before, and the case shows us how you think when the problem is new and the information is incomplete. So far it's my favorite part of our hiring process, partly because it's the fairest one: everyone applying for a role gets the same problem, and every interviewer looks at it the same way.

This post covers how we think about the case and what we look for. It isn't a copy of the prep guide you'll get before your interview (that one goes deeper on your specific role), but it should take most of the guesswork out of the format.

Why we use a live case instead of a take-home

At Adapty we believe the case tests one of the most fundamental things we look for in anyone we hire, which is our value Think Big, Think Deep. In practice that means making sense of a messy situation, breaking it into parts, getting to the root of it with logic and numbers, and still aiming high rather than settling for a 10% improvement. Plenty of skills can be picked up on the job, but this one is much harder to teach, so we'd rather see it up front.

That might sound old fashioned coming from a company that uses AI for almost everything (our engineers build with coding agents every day, and most of the rest of the team isn't far behind). But that's exactly why we care. AI is great at producing an answer once someone has framed the problem well, and the framing is the hard part: working out what's really going on, which question matters, and what you'd do first. A take home in 2026 mostly tests how well you prompt, and we'd end up reading a polished document without learning much about the person who sent it.

So instead we give you a broad problem and watch you work through it live. The prompt is deliberately short on data, it doesn't require any insider knowledge, and everyone applying for the same role gets exactly the same wording. There is still homework, just not the kind AI can do for you. Along with your invite you'll get a prep guide with context on Adapty and our market, how the session runs and what we expect, and we'll send it again the day before and ask you to confirm you've read it. People who did their homework are usually easy to spot within the first few minutes, and so are the ones who didn't.

What we mean by "how you think"

Every role goes through the same stages: a screening, an HR interview about your experience, the case, a hard-skills interview with someone other than your case interviewer, and a final bar raiser interview with a person from outside the hiring team, who looks closely at what you've actually achieved. The other stages are about your past, so the case doesn't include any "tell me about a time when" questions. It's you and one problem.

When we say we're looking at how you think, we mean a handful of fairly concrete things: the questions you ask and what you do with the answers, how deep you go before you stop digging, and how comfortable you are with numbers (yes, we think that last one is mega important). We also look for common sense, and for the ability to zoom out to the big picture when you're getting lost in the details.

Focus matters just as much. Most real problems have one or two things that actually matter and a dozen that don't, and a big part of the job is picking the right ones and staying on the question you were asked. A strong case ends with a clear decision about what to do first, while a weak one ends with a long list of everything that could be done (more on that below, because it's the most common way people fail).

A good solution isn't a specific answer so much as a roadmap: what the real problem is, what you'd do first, and how you'd know it worked. There's no right answer to guess, and quite often it's a problem we haven't fully solved ourselves.

How the session works

Your interviewer, usually the hiring manager and sometimes with a colleague, will start by introducing themselves and walking you through how the stage works. It's a short recap of what's already in your prep guide, and they'll answer any questions you have before the case begins, so if anything about the format is unclear, that's the moment to ask. After that we'll ask you to introduce yourself in about two minutes (worth preparing, because it's easy to ramble).

Then you'll get the prompt, two or three sentences that the interviewer reads out and pastes into the chat so you can keep looking at it. From there the case takes anywhere from 10 to 50 minutes depending on the role, and it's your conversation to run. Feel free to think out loud, take a pause when you need one, or start over if you realize you've gone the wrong way (which counts in your favor, by the way). As a rough guide, spend about a fifth of the time on questions and another fifth on structure, give the biggest chunk to numbers and depth, and keep a couple of minutes at the end for a short pitch of your answer.

Bring pen and paper, it makes things way easier for you. You can use Google or AI to look things up, but not to do the thinking for you, and if you use them, tell us and share your screen so the interviewer can see your prompts. Data and engineering cases work a bit differently, which we'll get to below.

One rule is strict: if you come unprepared, we'll end the case after 10-15 minutes, and that also ends the process. If you haven't had time to prepare, just tell us beforehand and we'll happily move it.

It's your case, so drive it

This is the part people underestimate the most. You won't get any information you don't ask for. The interviewer will answer every question truthfully and with real numbers, but they won't structure the problem for you, suggest the next step or point you at the interesting data, and most of the time they'll stay quiet until you ask something. If you ask them for help, the answer you're most likely to hear is "work with the data you have."

What you will hear are questions that push you to connect your work back to the goal, like "How will you use this?", "How does this get us to the goal?", "Why isn't your answer generic?" or simply "Rank them." It's worth practicing your answers to those before the interview, because they come up a lot.

I care about this more than almost anything else in the case. The hardest people for me to work with are the ones who need everything spoon-fed, and the best ones pick things up fast, ask the right question and run with the answer, which makes everything feel about 10,000x faster. The case is basically a short sample of which kind of person you are.

The steps are the same for every role

It doesn't matter which role you interview for, the structure is identical for everyone. What changes is the kind of problem you get:

• Product and leadership: a company-level goal with a hard number and a deadline.
• Analytics and ML: a product or model problem where accuracy is only part of the story. What matters is the decision someone makes differently because of the model, and what happens when it's wrong.
• People and recruitment: a real, often unfinished problem from our own people system, and at some point the interviewer may play someone you'd be working with. "Run discovery, align stakeholders, roll out a framework" describes every project ever, so we're looking for the specific mechanism you'd put in place and why it would survive a manager who doesn't want it.
• Data: hands-on work with real data, using whatever tools you like (AI and SQL included) with your screen shared.
• Engineering: system design, a production problem to diagnose, or building something live with an AI agent, where we watch how you direct it and whether you check what it gives you.
• Sales and go-to-market: a go-to-market problem.
• etc.

Five steps from a broad problem to a plan

Your prep guide asks you to move through five steps. We think it's the shortest way from an ambiguous problem to a plan without getting lost, and it's also pretty close to how we try to work day to day.

1. Ask clarifying questions

Start by finding out what the problem actually is: the context, the numbers that define it, what success looks like and by when, and what constraints you're working with. Skip this and you'll build a beautiful structure around the wrong problem.

The quality of your questions matters much more than how many you ask. The more specific the question, the more specific (and useful) the answer, while broad questions get broad answers that leave you with nothing to work with, and that's usually how people end up with a generic plan. Here's what the difference looks like in practice:

• Instead of "Tell me about the users," ask "What share of new subscribers comes from paid ads versus organic?"
• Instead of "How's the business doing?", ask "How has revenue from new subscribers moved over the last six months?"
• Instead of "What's been tried?", ask "Has anyone tested a bigger budget, and what did the extra users cost?"
• Instead of "Are there any constraints?", ask "How many engineers can work on this next quarter?"
• Instead of "What's the churn?", ask "What share of annual subscribers renew after the first year?"

A good test is whether the answers actually change your plan. If you ask six questions and then draw the framework you'd have drawn anyway, the questions were decorative, and that's very visible from the other side of the table. My favorite thing to hear at this stage is some version of "given that, I'm dropping this branch, because…"

You can also push back on the goal itself. Someone who weighs a target and comes back with an argument is far more useful than someone who silently accepts whatever number they're given, as long as a plan still follows.

2. Build a structure

Break the problem into parts you can check one at a time, without overlaps. That might be a set of hypotheses, a metric broken down into its factors, or a funnel where you look for the leak, and most of the time it ends up being a mix. If you break down a metric, the formula should describe this particular business rather than one from a textbook.

After reading the prep guide almost everyone draws a tree, so the tree on its own isn't what we're looking for. What we're looking for is why you chose to go into one branch first. Say the whole structure out loud, ask whether anything's missing, and then dive in.

3. Go deep on the numbers

Say what you want to calculate and what decision it will drive, explain your logic before asking for any numbers, and then ask for data one item at a time rather than as a list of eight. Once you've calculated something, say what it means, because the interviewer isn't waiting for a figure so much as for the decision that follows from it.

If some data doesn't exist, make an explicit assumption and say how much it matters. And try not to stop at the symptom: "this metric fell" is a complaint rather than a finding, and the root cause is usually one more "why" away.

4. Pick solutions and plan the execution

Brainstorm first, then pick. For every idea that survives, we want to hear the expected impact, how you'd test it cheaply, who does it and by when, and the one metric that tells you it worked. Execution counts for more than the ideas themselves here, because ideas are cheap and what matters is whether you can get one off the page.

Think about adoption too, since a process or feature that exists but nobody uses is worse than having none at all. And if your idea involves a model, have a view on what happens when the model is wrong.

5. Close with a short pitch

Finish with a pitch of two minutes at most, with the core of it in three or four sentences: the real constraint, your first move, the result you expect and when, the metric you'll watch, and what you deliberately left out. Ideally it's something the interviewer could repeat to a colleague without looking at their notes.

Covering a lot of ground and then failing to compress it counts as a weak result. Two things with a clear "everything else can wait, because…" will beat a list of fifteen initiatives every time.

The score is a verdict, not an average

We record every session, so your questions stay on the record word for word and in the order you asked them, and that recording is the main evidence we use afterwards. Each step gets its own score, and so does the case as a whole. Doubt counts as a no, and the overall score isn't an average: questions, structure and the close carry more weight than the rest, because if those are weak, everything in between is built on the wrong problem and even a brilliant calculation won't save it.

We're still tuning the process ourselves, so if something in your case feels off, say it. Be Direct is one of our values, and it works in both directions.

Case example

Let's say you're interviewing for a marketing role. Your case could look something like the one below (it's made up, because we never publish the cases we actually use).

A meditation app spends $200k a month on ads, and the spend pays back in about nine months. The founder wants to double the budget next quarter to double growth. What do you do?

Questions. A weak start sounds like "Great, let's split the extra budget between two new channels and order more creatives." A strong one starts by asking what "pays back in nine months" actually means (is that the average across all spend, or the last dollar?), where the money goes today, whether anyone has tried spending more, how much cash there is, and what exactly "double growth" means.

Let's say the answers are that nine months is the average across all spend, almost everything goes to one ad network, the team tried spending 50% more for two weeks last month, there's $2M in the bank, the goal is twice as many new subscribers, and the team is a growth lead, a designer and an analyst. A strong candidate uses that straight away: "Nine months is an average, and when you scale spend the extra dollars usually buy more expensive users than the average ones. Given that we already tested +50%, I'm parking new channels for now and starting with what that test cost us."

Structure. A weak structure is the textbook tree (traffic, conversion, pricing, retention) with no reason to start anywhere in particular. A strong one starts from how this business actually works: new subscribers from ads equal spend divided by the cost of the next subscriber. That gives three branches, which are what the extra dollar actually buys, whether the cash lasts until it pays back, and which other levers could bring in subscribers without more spend. The first branch goes first, because it decides whether doubling is worth doing at all.

Numbers. One question at a time. Today $200k buys 4,000 subscribers, so $50 each. A subscriber brings in about $50 net over the first nine months, $58 over twelve and $75 over two years. In the +50% test, the extra money bought subscribers at about $80 each.

A weak candidate stops at "the test was more expensive." A strong one says what that means: at $80, the next subscriber doesn't pay back even in two years, and the second half of the doubling will cost more still. Doubling spend would get somewhere around +50% subscribers rather than +100%, and put $600k of the $2M into users who never pay back.

Solutions. A weak answer is a list of ten ideas: new channels, a discount, an email campaign, a new onboarding. A strong one is two moves. The first is to raise spend in steps of about 20% and stop at the point where the next subscriber still pays back within twelve months, which means costing under $58. If the first step comes in at around $57 per subscriber, that's roughly 700 extra subscribers. The growth lead owns it, and the real limit is creatives rather than money, since one designer can keep up with +20% but not with double.

The second move is to get the rest of the growth from the paywall by testing the offer and plan structure to lift install-to-paid conversion, which makes every ad dollar cheaper. The designer and the analyst own that one, with an early read on conversion and revenue per install in three to four weeks. New ad networks and new markets are parked until the core channel is tuned. And since the hardest part will be convincing the founder, a strong candidate opens with one number, $80 against $50, rather than a lecture on unit economics.

Close. "Doubling spend won't double growth. The extra dollar already costs $80 per subscriber against a $50 average, and at that price it doesn't pay back within two years. I'd raise spend in steps and stop where the next subscriber pays back within twelve months, and get the rest from paywall conversion. If the paywall test lifts conversion by 20%, that's roughly +40% subscribers this quarter with payback intact, instead of +50% and a hole in the bank. I've parked new channels and markets until the core channel is tuned."

That takes less than a minute to say, and it pushes back on the goal while still bringing a plan with a number attached.

Almost nobody fails on knowledge

In our experience, almost nobody fails because they don't know something. People tend to fail on the same handful of things, over and over:

• They don't prepare and read the interview process.
• They wait to be led, sitting in long silences and hoping the interviewer will suggest the next step.
• They ask questions and then don't use the answers, sometimes to the point where not a single number from the conversation makes it into the final answer.
• They list ideas instead of structuring the problem, and ten unconnected ideas aren't a plan.
• They lean on book knowledge: textbook frameworks, no intuition, nothing specific to the business in front of them.
• They answer a different question from the one they were asked.
• They run out of time, usually after a long self-intro and so many questions that the first structure shows up halfway through and there's nothing left for the close.
• They defend a number they made up, and nobody (including the candidate) knows where it came from.
• etc.

The strongest candidates tend to do the same few things early on. They restate the problem in their own words to make sure they got it, ask why the goal exists before asking about the metric, estimate the order of magnitude themselves before asking for data, and say out loud what they're dropping and why. They can even challenge the interviewer and the problem.

The prep guide is all you need

Read your prep guide properly, confirm that you did, and answer its self-test questions out loud. None of them will be asked word for word, but if you can talk through each one for five minutes, you're ready. For most people, that's enough.

If you want to go one step further, spend an hour with the product: create a test project, build a paywall and make a sandbox purchase. It's optional, but it's the fastest way to get a feel for what we actually do.

And if you're not in the process yet, take a look at our open roles.

Vitaly DavydovFounder and CEO at Adapty