agoda Data Engineer Interview: Questions, Experience & Prep (2026)

Agoda is one of Asia-Pacific's largest online travel platforms, processing enormous volumes of search, pricing, and booking data every day. Their data engineering team builds and maintains the pipelines, warehouses, and real-time systems that power hotel pricing algorithms, personalisation, fraud detection, and business intelligence across the platform.

As of the July 2026 knok jobradar snapshot, agoda has 299 open Data Engineer roles, making it one of the most active hirers in this space right now. The broader Indian market shows 542 Data Engineer openings tracked across major cities, with Bangalore leading at 92 roles and Delhi at 66.

Salary bands for Data Engineers in India (knok jobradar data):

Candidates report the interview process typically spans multiple rounds covering SQL and coding, data modeling, system design, and a behavioural round. Agoda places strong emphasis on distributed systems knowledge, SQL fluency, and experience operating data pipelines at real scale.

These are the topics candidates most commonly report being tested on in agoda Data Engineer interviews:

1. Walk us through the most complex data pipeline you have built end-to-end. What scale did it handle and what were the key design decisions?
2. How would you design a real-time event streaming pipeline to track hotel search and booking events and feed a recommendation engine?
3. Write a SQL query to find the top 3 destinations by total booking revenue for a given time period.
4. Explain the difference between a star schema and a snowflake schema. When would you choose one over the other on a travel platform?
5. How do you handle late-arriving data in a streaming pipeline? Give a concrete example from your experience.
6. What strategies do you use to ensure data quality at scale? How do you monitor for data drift or pipeline anomalies?
7. Describe a time you optimised a slow-running query or pipeline. Walk us through your approach and the outcome.
8. How would you approach partitioning a large booking fact table to support both analytical and operational query patterns?
9. What is your hands-on experience with Spark, Flink, or Kafka? Describe a production use case in detail.
10. How do you handle schema evolution in a data lake or warehouse without breaking downstream consumers?
11. Describe a situation where a data or pipeline issue reached production. How did you identify it, fix it, and prevent recurrence?
12. How would you design a data model to track a user's full journey through a hotel search and booking funnel?

Q: Walk us through the most complex data pipeline you have built.

*Situation:* At my previous company, we had a nightly batch process that aggregated transaction data from several source systems into a reporting warehouse. As the business grew, the jobs began missing their SLA windows and the data team was spending hours each morning debugging failures.

*Task:* I was asked to redesign the ingestion and transformation layer to handle the growing load and reduce end-to-end latency so analysts had fresh data before the start of their day.

*Action:* I audited each stage and found that full table scans on large fact tables were the core bottleneck. I introduced incremental loading using event-time watermarks, re-partitioned the main fact tables by event date, moved heavy aggregations into a dedicated Spark transformation layer, and added row-count and null-rate checks at each stage with alerting.

*Result:* End-to-end latency dropped significantly and the team stopped seeing SLA misses. The quality checks caught two upstream schema changes before they could reach the warehouse, saving the team from silent data corruption.

---

Q: Describe a time you handled late-arriving data in a streaming pipeline.

*Situation:* On a user activity tracking pipeline, we were computing session-level aggregates in near real-time. We noticed that mobile app events sometimes arrived with a significant delay due to offline usage, causing session counts to be understated in our live dashboards.

*Task:* I needed to update the pipeline to correctly account for late events without re-processing the entire history or destabilising dashboards that business teams relied on.

*Action:* I implemented a watermark-based approach that allowed events arriving within a defined grace window after event time to be folded into the correct session aggregate. For events arriving beyond that window, I built a lightweight reconciliation job that corrected the affected aggregates in the warehouse on a scheduled basis. I also added monitoring to track the late-arrival rate over time so we could tune the window.

*Result:* Session counts became consistent between real-time and batch views. Stakeholders reported higher trust in the dashboards, and the reconciliation job handled the long tail of late arrivals cleanly without manual intervention.

---

Q: Describe a production data incident you handled.

*Situation:* A schema change in an upstream source system was not communicated to the data team. A column our pipeline used for currency conversion was silently renamed, causing downstream revenue reports to show zero for a portion of transactions.

*Task:* I was on call when the anomaly was flagged by the business team. I needed to identify the root cause quickly, restore correct data, and put safeguards in place to prevent the same type of failure.

*Action:* I traced the issue back to the schema change using query logs and confirmed the downstream impact scope. I applied a hotfix to the transformation job, re-processed the affected partitions, and sent stakeholders a clear impact summary. I then integrated automated schema-drift detection using a schema registry and added contract tests that run on every ingestion job.

*Result:* The data was corrected within a few hours of the initial flag. The schema registry and contract tests have since caught two more upstream changes before they caused any downstream impact, removing a whole category of silent data failures.

STAR for technical and behavioural questions. Even for coding or system design questions, anchor your answer in a real situation. Describe the scale, the constraint, and the tradeoff you made. Agoda interviewers are not looking for textbook definitions. They want to see how you reason under real constraints.

For SQL questions. Think out loud. Start by restating what the query needs to return, identify the tables and joins needed, write the core SELECT and GROUP BY logic, then layer in window functions or CTEs if the problem needs them. Candidates report agoda SQL rounds test both correctness and readability, so structure complex queries with CTEs rather than deeply nested subqueries.

For system design questions. Use a layered approach: understand scale and access patterns first, then propose a storage layer, a processing layer, and a serving layer. Be explicit about tradeoffs (batch vs. streaming, normalised vs. denormalised, cost vs. latency). Travel platforms have strong seasonality, so mention how your design handles sudden spikes in search and booking traffic.

For behavioural questions. Use the STAR format (Situation, Task, Action, Result) and keep the Result concrete. If you cannot quote a specific metric, describe the direction of the outcome clearly ('the team stopped missing SLAs', 'analysts had fresh data before standup', 'the incident category was eliminated').

Agoda's data engineering team operates at significant scale on travel data. Based on what candidates typically report, interviewers are looking for these qualities:

Scale awareness. Can you reason about data volumes, partitioning strategies, and pipeline performance? Have you operated systems under real load, or only designed them theoretically? Be ready to describe the scale of systems you have personally built and run.

SQL fluency. Agoda's business runs on data, and SQL is a core skill at every level. Candidates report SQL rounds are non-trivial, covering window functions, CTEs, and query optimisation. Practice writing clean, well-structured SQL under time pressure.

Systems thinking. Do you understand how your pipeline fits into the broader architecture? Interviewers probe whether you think about schema evolution, downstream consumers, monitoring, and failure modes, not just the happy path.

Ownership mindset. Travel platforms operate across time zones with on-call expectations. Interviewers look for engineers who have taken end-to-end ownership of data pipelines, including incidents and root-cause analysis, not just those who build and hand off.

Clear communication. Can you explain a complex design decision to a non-technical stakeholder? The behavioural rounds typically include questions that probe for this. Keep your explanations structured and free of unnecessary jargon.

Week 1: SQL and coding foundations

Review window functions (RANK, DENSE_RANK, LAG, LEAD), CTEs, GROUP BY with HAVING, and query optimisation basics. Practice writing queries on travel-domain datasets involving bookings, searches, and user sessions. Focus on correctness first, then clean up for readability using CTEs.

Week 2: Data modeling and warehousing

Revise star schema vs. snowflake schema, slowly changing dimensions, and fact table design. Think through how you would model a hotel booking platform: what are the key dimensions (hotel, user, date, location), what is the grain of the fact table, how do you handle cancellations and modifications?

Week 3: Distributed systems and pipeline design

Review Apache Spark (DataFrames, partitioning, caching), streaming concepts (watermarks, windowing, exactly-once semantics), and Kafka fundamentals. Be ready to walk through a real pipeline you built, covering the design decisions, failure modes, and how you monitored it in production.

Week 4: Behavioural prep and system design practice

Prepare at least 5 STAR stories covering: a complex pipeline you built, a production incident you resolved, a time you improved data quality, a disagreement with a stakeholder you navigated, and a time you had to learn something quickly. For system design, practice designing a pipeline for a travel platform scenario end-to-end.

Knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR for you, so your applications keep moving while you focus on preparation.

1. Jumping to code before understanding the problem. In SQL or design rounds, candidates who start writing immediately often go down the wrong path. Spend a moment restating the problem and confirming your understanding before writing a single line.

1. Using generic examples. Saying 'I built a pipeline' without mentioning scale, technology choices, or tradeoffs sounds thin. Even if your experience is at an early-stage company, anchor your answer in specifics: what did the pipeline do, what broke, what tradeoff did you make?

1. Ignoring failure modes in system design. Agoda's systems need to be resilient. If you describe a design without mentioning monitoring, alerting, or how you handle partial failures, interviewers will probe harder on exactly those points.

1. Treating SQL as an afterthought. Candidates who are strong in Spark or Python sometimes underestimate the SQL round. Practice writing clean, well-structured SQL with CTEs under time pressure. Agoda interviewers care about readability, not just correctness.

1. Vague behavioural answers. 'I collaborated with the team' tells an interviewer nothing. Use the STAR structure, name the specific action you took, and describe a concrete result. Even 'the team stopped missing SLAs' is better than 'things improved'.

1. Not asking clarifying questions in system design. For open-ended design questions, asking about scale, consistency requirements, and latency expectations before diving in signals seniority and good engineering instincts. Interviewers notice when candidates skip this step.