Agoda Product Manager Interview Guide

The process felt like 5 rounds spread across roughly two weeks, and every round tested a slightly different version of “Can this person think like an Agoda PM?”

The first conversation was pretty relaxed. It was mostly background, motivation, and why Agoda. I went in expecting a standard recruiter screen, but even there they pushed a little harder than I expected on why travel, why marketplaces, and why Agoda specifically. Saying “I like travel” was obviously not enough. I had to talk about marketplace dynamics, supply-demand matching, pricing, conversion, and experimentation. That was my first signal that they wanted PMs who were quite commercially and analytically minded.

The next round was where I started feeling good. It was a product sense / product improvement case. I got something along the lines of: imagine a part of the booking experience is underperforming — how would you improve it? I structured it around the user journey, segmented users, identified friction points, picked one problem, and then talked through solutions and metrics. This was familiar territory for me. I felt pretty confident because the interviewer wasn't looking for some magical feature idea. They kept asking, “Why that segment?”, “Why is that the biggest problem?”, “How would you know?” It felt like they cared more about the reasoning chain than the final feature.

Then came the round where I started sweating: analytics and diagnosis.

The interviewer essentially gave me a scenario like: “Booking conversion dropped. What do you do?”

My initial instinct was to jump into hypotheses — pricing, payment failures, inventory, competitor activity. The interviewer stopped me and said something like, “Before hypotheses, how do you know the metric is actually broken?”

That was a very Agoda-type moment for me.

So I had to rewind: validate tracking, check whether the definition changed, look at country/device/platform splits, compare new vs returning users, traffic-source mix, funnel stages, booking windows, hotel types, and so on. Every time I found a possible explanation, they went one level deeper.

I remember thinking, Okay, they are not going to let me hand-wave anything here.

There was also a quantitative part. Nothing crazy like investment banking math, but enough percentages, conversion rates, funnels, and trade-offs that you couldn't hide behind PM vocabulary. I made one calculation mistake, caught it, corrected myself, and moved on. That was probably the point where my heart rate was highest.

Another round was much more execution-oriented. It was about prioritization and trade-offs. I was given competing opportunities and had to decide what the team should build. The surprise was that simply using RICE or saying “impact versus effort” wasn't particularly impressive. They kept challenging the assumptions underneath the score.

For example, if I said Feature A had higher impact, the response was basically: “Why?”

Then: “How many users?”

Then: “What makes you believe behavior will change?”

Then: “What if engineering says this takes six months?”

Then: “What if the revenue opportunity is concentrated in only one market?”

It became much more like an actual product discussion than a textbook prioritization exercise.

The final conversations were more around leadership and behavioral situations — disagreements with engineering, influencing without authority, failed launches, stakeholder conflict, making decisions with incomplete information. I actually found these harder than I expected because they drilled into details. If I said, “I aligned stakeholders,” they'd ask exactly who disagreed, what they wanted, what I said, what data I showed, and what happened afterward.

There was nowhere to hide behind phrases like “cross-functional collaboration.”

The biggest surprise across the entire process was probably how analytical the PM bar felt. I expected product sense and strategy to dominate. Instead, I came away feeling that Agoda really wanted someone who could move comfortably between user problems, business outcomes, metrics, experiments, and very detailed funnel analysis.

Where did I feel strongest? Product structuring and breaking ambiguous problems into smaller pieces. Once I could put a framework around the problem, I usually felt in control.

Where did I sweat? Definitely when the interviewer pushed into numbers and second-order effects. Agoda has a marketplace with hotels, travelers, prices, promotions, geography, seasonality, and tons of experimentation. So almost every “good idea” creates another question: what happens to margin, supplier behavior, cancellation rate, repeat rate, or another customer segment?

The overall feeling walking out wasn't, “Wow, I crushed five interviews.”

It was more like:

“I think I survived four of them, and I'm still replaying one metric question in my head.”

That was probably the most realistic part of the experience.

Questions asked: Recruiter / first screen

The questions were pretty standard at first:

“Walk me through your background.” “Why Agoda?” “Why do you want to work in travel?” “Why leave your current company?” “What kind of product do you want to work on?” “Tell me about one product you owned end to end.”

But then they asked:

“How does Agoda actually make money?” “Who are Agoda’s most important customers?” “What makes an OTA marketplace difficult to build?” “How would Agoda be different from Booking.com or Airbnb from a product perspective?”

That caught me slightly off guard because I thought the commercial questions would come later.

Product sense case

One prompt was roughly:

“You are the PM for Agoda’s hotel booking funnel. Customer satisfaction is fine, but repeat booking is not improving. What would you do?”

I started with segmentation.

They immediately asked:

“Which users would you segment first?” “Would you start with new users or existing users?” “What behavior tells you someone is likely to become a repeat customer?” “Why would repeat booking matter more than conversion?” “What if repeat users generate lower margins because they are more price-sensitive?”

Then I proposed a few ideas around saved preferences, better rebooking, loyalty, personalized recommendations, and price confidence.

The interviewer kept asking:

“Which one would you build first?” “What user problem does that solve?” “What is your hypothesis?” “What metric moves?” “What guardrail metric could get worse?” “How long would you run the experiment?”

That last part came up constantly: hypothesis → metric → experiment → trade-off.

Conversion-drop diagnosis case

This was probably the most technical PM case.

The prompt was basically:

“Hotel booking conversion dropped by 8% last week. How would you investigate?”

My initial mistake was jumping into causes.

They wanted me to start with:

Is the metric actually broken? Where did the drop occur? Who was affected? When did it start? What changed?

Then the follow-ups became very specific:

“What dashboard would you open first?” “What dimensions would you slice by?” “What if Android is down but iOS is stable?” “What if only Southeast Asia is affected?” “What if traffic increased 25% at the same time?” “What if conversion dropped but total bookings increased?” “What if checkout conversion is stable but search-to-property-page conversion dropped?” “What if only new users are affected?” “What if the drop started immediately after a release?”

Then they asked something like:

“Suppose paid traffic doubled and paid users convert at 2%, while organic users convert at 5%. Could overall conversion drop even if nothing in the product changed?”

So I had to explain mix shift.

That was one of the moments where I realized they cared a lot about whether you understand what sits underneath an aggregate metric.

Funnel math

There were several small calculations rather than one massive math test.

Something like:

1,000,000 users visit. 40% perform a hotel search. 25% visit a property page. 20% start checkout. 50% complete payment.

Then:

“How many bookings do we get?”

And then:

“If you could improve one funnel stage by 10% relative improvement, where would you focus?”

The trick wasn't really the arithmetic. They wanted me to ask whether improving that stage was realistic and whether different stages had different engineering costs.

Another one was:

“Conversion improves from 4% to 4.2%. Is that a 0.2% improvement?”

They wanted percentage point versus percentage improvement.

So:

4% → 4.2% = 0.2 percentage points, but roughly a 5% relative improvement.

Small thing, but they cared.

Experimentation questions

They asked quite a bit about A/B testing.

One prompt:

“You launch a new hotel ranking algorithm. Conversion increases 3%, but average booking value decreases 5%. Do you launch?”

My answer started with “it depends,” which was correct but useless until I explained what it depended on.

They pushed:

“What is the primary objective?” “Revenue or bookings?” “What if margin increases?” “What if cancellation rate goes up?” “What if the result is only positive for mobile?” “How would you know whether the effect is statistically significant?” “Would you run the test by user, session, hotel, or geography?”

Another question was:

“Your experiment is positive for new users and negative for returning users. What do you do?”

That led into segmentation, heterogeneous treatment effects, and whether we could ship different experiences to different cohorts.

Marketplace case

One of the more interesting cases was supply-side.

It was something like:

“Agoda wants more hotels to offer free cancellation. How would you approach this?”

That was much harder than a normal consumer-product case because there are two sides.

I had to think through:

Traveler side

Free cancellation may improve conversion. It may improve trust. It may encourage earlier booking. But it may increase cancellations.

Hotel side

Hotels may see more bookings. But they may face inventory uncertainty. Some hotels may need compensation or different pricing.

They asked:

“Why would a hotel agree?” “Would you subsidize it?” “How would you prove incremental value?” “What happens to cancellation rate?” “What happens to room availability?” “What happens during peak season?” “Would every hotel benefit equally?”

That was one of the strongest signals that marketplace thinking mattered.

Prioritization case

The interviewer gave me something close to four opportunities:

A. Improve search filters Impact: many users, moderate conversion upside.

B. Launch a loyalty feature Impact: fewer users initially, potentially strong retention.

C. Improve payment reliability in one large market Impact: narrow geography, obvious booking impact.

D. Build an AI trip-planning feature High strategic visibility, uncertain immediate revenue.

Then:

“You have one squad. What do you build?”

I started trying to score them.

The interviewer said something like:

“Forget the framework. Tell me what you actually choose.”

That was memorable.

Then they challenged everything:

“Why is payment reliability more important?” “What if AI is the CEO’s priority?” “What if engineering says payment takes two quarters?” “What if loyalty could increase LTV by 15%?” “What information would change your decision?”

They were much more interested in decision quality than whether I knew RICE.

Search and ranking question

I also got a more technical product question:

“How would you decide which hotels appear first when a user searches Bangkok?”

I didn't need to design the machine-learning model, but I had to understand the product inputs.

I mentioned:

price, location, quality/review score, historical conversion, availability, user preferences, cancellation policy, property popularity, predicted likelihood to book.

Then they asked:

“Would you rank the hotel most likely to be booked first?”

And that opens a much deeper discussion because optimizing only conversion could create bad outcomes.

Maybe the highest-converting properties:

have lower margin, provide worse customer experiences, get excessive exposure, reduce marketplace diversity.

So we ended up discussing ranking as a multi-objective optimization problem.

That was probably the most “technical PM” discussion.

Behavioral questions

These weren't generic STAR questions. They drilled hard.

Examples:

“Tell me about a product decision you got wrong.” “Tell me about a time engineering disagreed with you.” “Tell me about a time data contradicted your intuition.” “Tell me about a product you killed.” “Tell me about a stakeholder you couldn't convince.” “Tell me about the most unpopular decision you've made.” “Tell me about a launch that failed.”

The follow-ups were the difficult part:

“What exactly did engineering disagree with?”

“What did you say?”

“What evidence did you have?”

“Who made the final decision?”

“What happened three months later?”

If your story was vague, they could tell immediately.

Product strategy question

I remember something along the lines of:

“If you became the PM for Agoda in India tomorrow, what would you investigate first?”

I talked about:

domestic versus international travel, mobile behavior, payment preferences, price sensitivity, alternative accommodation, competition, repeat behavior, supply depth.

Then they challenged:

“Why India?”

“Why would Agoda win?”

“Would you optimize for customer acquisition or repeat?”

“Would you compete on price?”

“What would you not build?”

That last question — what would you not build? — appeared more than once.

The weird take-home

The take-home was the part I overthought the most.

The instruction was approximately:

“Pick a meaningful customer problem in online travel. Explain the problem, identify the target user, propose a solution, define success metrics, and describe how you would validate it.”

They deliberately left it broad.

I think the guidance was around 5–7 slides, but there wasn't a huge amount of formatting instruction.

What surprised me was that they didn't really care whether the deck looked beautiful.

In the presentation, most of the discussion was about assumptions.

I had a slide saying roughly:

Problem: travelers hesitate to book because they aren't confident they're getting a good price.

I proposed a price-confidence feature.

Almost immediately:

“How do you know this is actually a problem?”

Then:

“How many users experience it?”

Then:

“Why would this increase bookings rather than simply encourage users to wait?”

That question completely changed the conversation.

They also asked:

“What would your MVP be?” “What would you explicitly exclude from V1?” “What data would you need?” “What happens if the feature reduces urgency?” “Could this hurt hotel partners?” “How would competitors respond?”

I think I had prepared maybe 20 minutes of presentation.

The actual presentation took closer to 7–8 minutes because they started interrupting with questions almost immediately.

One question I still remember

Near the end, one interviewer asked:

“Imagine you launch a feature. Users love it, engagement rises, NPS rises, but Agoda makes less money. Is that a successful product?”

There wasn't really a correct yes/no answer.

They wanted to hear whether I could reconcile:

customer value + business value + marketplace health.

And that probably summarizes the whole interview process.

The questions weren't especially exotic individually.

What made them difficult was that almost every answer triggered:

“Why?”

Then:

“How do you know?”

Then:

“What metric?”

Then:

“What could go wrong?”

And once you survived those four, they usually changed one assumption and made you solve the problem again.