agoda Data Scientist Interview: Questions & Prep (2026)

Agoda and data science

Agoda is one of the largest travel booking platforms in Asia, operating within the Booking Holdings group. Data science sits at the core of the business: hotel pricing, search ranking, personalised recommendations, fraud detection, and large-scale A/B experimentation across millions of daily users. With 299 Data Scientist roles currently open at Agoda on knok's radar, the company is actively hiring across all experience levels.

Candidates report a process that typically spans multiple rounds: a recruiter call, a technical screen covering statistics and SQL, a take-home or live case study, and a final round with senior team members. Treat this as a likely shape, not a guaranteed sequence. Confirm the exact structure with your recruiter.

Salary bands for Data Scientists in India (knok jobradar data, July 2026)

These are market-wide bands. Agoda is widely cited on Glassdoor as paying at or above market for product-facing data science roles.

Agoda interviewers focus heavily on experimentation, product thinking, and the ability to translate data findings into business decisions. These are the questions candidates report most often.

1. Walk me through an A/B test you designed from scratch. How did you choose the success metric and estimate the required sample size?

1. Agoda runs thousands of concurrent experiments. How do you control false discovery rate when multiple tests are live at the same time?

1. Design a personalised hotel recommendation system for a first-time user who has no booking history on the platform.

1. You have a large bookings table. Write SQL to identify users who booked more than once in a single calendar month. How would you optimise the query for scale?

1. A pricing model you deployed is showing unexpectedly low conversion rates. How do you debug it end to end?

1. How would you detect and handle data leakage in a model that predicts booking cancellations?

1. Explain the difference between precision and recall. In a fraud detection context, which one matters more and why?

1. How would you measure the long-term impact of a recommendation feature when short-term metrics look flat or neutral?

1. A product manager disagrees with what your model recommends. How do you handle that conversation?

1. How do you decide when a model is ready to ship versus when it needs more iteration?

1. Tell me about a time you found a data insight that contradicted a widely-held business assumption.

1. How would you build a real-time system to flag potentially fraudulent hotel reviews?

Use the STAR format for every behavioural question: Situation, Task, Action, Result. Each answer should run under three minutes when spoken aloud. The Result must be concrete: a metric shifted, a decision changed, or a risk avoided.

Q: Tell me about an A/B test you designed where the results surprised you.

*Situation:* At my previous company, the product team was convinced that adding a price-drop alert banner to the homepage would lift bookings. The hypothesis felt solid based on user interviews.

*Task:* I was asked to design and analyse the experiment before any full rollout.

*Action:* I defined 'completed booking within the session' as the primary metric, estimated the runtime needed to reach sufficient statistical power, and segmented users by device type because mobile and desktop behaviour differed sharply in our historical data. I also added a page-load-time guardrail metric so we could catch any performance regression.

*Result:* The feature lifted bookings on desktop but reduced them on mobile. The alert banner pushed the main call-to-action below the fold on smaller screens. We shipped a device-specific version instead of a blanket rollout, preserving the desktop gain without hurting mobile users.

---

Q: Describe a time you had to explain a model failure to a non-technical stakeholder.

*Situation:* A demand-forecasting model I owned started significantly underpredicting hotel availability requirements over a peak holiday period, which led to inventory shortfalls.

*Task:* I had to communicate what went wrong to the head of supply, who had no data background, and propose a fix quickly.

*Action:* I avoided jargon entirely. I showed a simple chart comparing predicted versus actual demand, then explained in plain language that the model had never seen this particular combination of travel restrictions lifting and pent-up demand arriving at the same time. I came to the meeting with a short-term manual override plan and a longer-term retraining proposal.

*Result:* The supply head approved both the short-term fix and the retraining budget. We also put a data drift detection check in place so future anomalies would surface faster.

---

Q: Tell me about a time you found an insight that changed a business decision.

*Situation:* Our growth team believed that giving a discount coupon on a user's first visit would increase repeat bookings. The assumption had never been tested rigorously.

*Task:* I was asked to validate it using historical data before the coupon programme was scaled up.

*Action:* I built a cohort analysis comparing first-visit coupon recipients against a matched control group over a multi-month window. I controlled for acquisition channel and booking value to avoid confounding the results.

*Result:* Coupon users had a lower second-booking rate than the control group. We were attracting price-sensitive one-time visitors rather than genuinely loyal customers. The growth team paused the programme and redirected budget toward retention features instead.

STAR for behavioural questions. Situation, Task, Action, Result. Keep the spoken version under three minutes. The Result must include something tangible: a metric, a decision reversed, or a cost avoided. Avoid endings like 'the team was happy' or 'it went well.'

Product-metric framework for measurement questions. When asked 'how would you measure X': name the goal first, define one primary metric directly tied to that goal, list two guardrail metrics (things you must not break), and name one counter-metric (something that could rise for the wrong reasons, like clicks driven by user confusion rather than genuine interest).

Hypothesis-first for debugging questions. When asked why a model is misbehaving, structure your answer as: check data quality first, then feature drift, then label quality, then model assumptions. Agoda interviewers specifically want to see that you do not jump straight to retraining as the default fix.

Trade-off framing for design questions. For any system or model design question, explicitly name the trade-offs: precision vs. recall, latency vs. accuracy, interpretability vs. performance. State which side you would lean toward for this specific use case and explain why, rather than saying both sides matter equally.

Business-first communication rule. Any time a question touches on stakeholders or decisions, lead with the business impact before the technical detail. Agoda data scientists partner closely with product and commercial teams, and this skill is tested directly in the interview.

Experimentation depth. Agoda's culture is built on rigorous testing. Saying 'I ran an A/B test and got significance' is not enough. Interviewers want to hear about power calculations, runtime estimation, handling novelty effects, guardrail metrics, and what you do when results are inconclusive or contradictory.

SQL fluency without hand-holding. Expect to write queries live or in a take-home. Candidates report questions involving window functions, self-joins, and aggregations on large tables. Correctness and readable logic matter more than raw speed.

Product sense. You will be asked to evaluate features, prioritise metrics, and reason about user behaviour in a travel context. Think through how a user actually chooses between two hotels before your interview. Interviewers notice when candidates anchor design answers to realistic travel scenarios.

Clear communication under pressure. Because data scientists at Agoda work directly with commercial and product teams, interviewers test whether you can explain a complex result in plain language. Practise adding 'in other words...' after every technical statement.

Intellectual honesty. If you do not know something, say so clearly and show how you would find the answer. Agoda teams value scientists who flag uncertainty rather than bluff through a knowledge gap.

Week 1: Statistics and SQL

Revise hypothesis testing, confidence intervals, p-values, and the logic behind power calculations. Do not memorise formulas. Practise explaining each concept as if you were talking to a product manager. Then practise writing SQL with window functions every day, using a public dataset such as a hotel reviews or bookings dataset from Kaggle.

Week 2: Machine learning and product thinking

Refresh gradient boosting, collaborative filtering (directly relevant for recommendations), and basic time-series concepts. For each model type, prepare a one-paragraph answer to: 'when would you use this and what are its failure modes.' Separately, think through travel product problems: search ranking, price sensitivity, review authenticity, and how Agoda might approach each.

Week 3: Mock interviews and communication

Do at least three full mock STAR interviews out loud, not just in writing. Record yourself if possible. Ask a friend to play a product manager and practise translating your answers for them. Work through every question listed in this guide and build a structured response for each one.

On the day

For every question, pause and say 'let me think about this for a moment' before you start. Ask one clarifying question for any design problem before you begin solving it. Candidates who think before speaking are consistently rated higher than those who rush in.

While you prepare, knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR for you, so you can focus your energy on interview readiness rather than manually tracking every new Agoda opening.

Skipping the clarifying question. For design and debugging problems, jumping straight to a solution without asking about constraints signals poor judgement. Always ask at least one clarifying question before you start solving.

Treating A/B test questions as simple. 'I ran a test and waited for significance' is not enough. Agoda interviewers expect you to address power, runtime estimation, guardrail metrics, and what you do when results are not clean or are statistically inconclusive.

Using accuracy as the only model metric. In any imbalanced-class setting such as fraud detection or cancellation prediction, accuracy is misleading. Always name a more appropriate metric and explain the reasoning clearly.

Ignoring business context in technical answers. A technically correct answer that ignores the commercial cost of being wrong will score lower than a slightly simpler answer that shows awareness of real-world stakes.

Overcomplicating the SQL. Candidates report that interviewers penalise unnecessarily complex queries. Write the simplest correct query first and only optimise if the interviewer asks you to.

Having no questions at the end. Agoda interviewers notice when a candidate is disengaged. Prepare two or three questions about the team's experimentation tooling, current data infrastructure challenges, or the hardest unsolved problem the team is working on right now.