Agoda Interview Experience — IC5 Backend Lead — Selected

Company: Agoda
Role: Lead Software Engineer (IC5 — Backend Lead)
Interview period: September–October 2026
Final result: Selected

I recently completed Agoda's interview process for the IC5 Backend Lead role. The process covered coding, platform engineering and code review, system design, and culture and impact.

Sharing my experience to help other candidates prepare. The questions below are based on what I remember from my interviews and may not represent every candidate's experience.

Round 1: Coding Interview (HackerRank)

Date: September 14, 2026
Duration: 60 minutes

Question 1: Sort an array containing only 1 and 2

Given an array containing only 1 and 2, sort it in place without using any extra space.

My approach: I implemented a working solution in my language of choice.

Follow-up: Sort an array containing 1, 2, and 3

Extend the solution to handle an array containing 1, 2, and 3, again sorting it in place without using any extra space.

My approach: I implemented a working solution, although my initial logic was more elaborate than necessary.

Key takeaway: Be prepared for follow-up questions that extend the original problem. Pay attention to the in-place and constant-extra-space constraints, and explain the time and space complexity of your solution.

Round 2: Platform Interview (HackerRank)

Date: September 21, 2026
Duration: 60 minutes

This round had two distinct parts.

Part 1: Improve an existing High-Level Design (HLD)

I was given an existing HLD for flight search and flight booking, along with functional and non-functional requirements.

The task was to review and improve the existing design rather than design a new system from scratch.

The discussion covered three areas:

• System Design & Analysis: Identify architectural weaknesses and improve scalability, performance, reliability, and correctness against the given requirements.
• Connectivity Management: Review API contracts, communication between components, external integrations, and failure handling.
• Quality Assurance: Explain how to test the design, validate non-functional requirements, and establish production readiness.

Part 2: Python code review

I was given a Python code snippet and asked to identify major design and implementation flaws rather than focus on syntax errors or ordinary bugs.

Example 1: Hard-coded flight suppliers

Supplier-specific logic was hard-coded into flight search.

Improvement: Use the Strategy pattern to isolate supplier-specific implementations and make the system extensible when new suppliers are added.

Example 2: Incorrect HTTP method usage

POST was being used for both booking creation and booking-status retrieval.

Improvement:

• POST /bookings — create a booking.
• GET /bookings/{bookingId} — retrieve booking status.

Key takeaway: Focus on separation of responsibilities, extensibility, design patterns, REST API semantics, and practical engineering trade-offs.

Round 3: Architecture & System Design

Date: October 8, 2026
Duration: 60 minutes

Question: Design a flight-search API aggregating results from 20–200 external suppliers

The system needed to fetch flight options from multiple third-party suppliers.

Requirements and challenges:

• Each supplier supported one route query at a time, using source, destination, travel date, passengers, and cabin class.
• Suppliers had different SLAs and supported different protocols, including JSON, SOAP/XML, and Protobuf.
• Multiple suppliers could return the same flight, requiring deduplication and selection of the cheapest fare.
• Some suppliers responded quickly, while others could take several minutes.
• The UI needed to display results quickly without waiting for every supplier.
• Supplier data was assumed to remain valid for one hour.

My proposed architecture

1. API Gateway: Authentication, authorization, and rate limiting.
2. Backend orchestration service: Coordinate supplier calls, aggregate responses, and deduplicate results.
3. Supplier connector layer: Handle supplier-specific protocols, payload transformations, timeouts, retries, and SLAs.
4. Cache: Store supplier responses or aggregated search results to reduce repeated supplier calls.
5. Streaming: Use Server-Sent Events (SSE) to deliver results incrementally, followed by a final aggregated response.

For deduplication, I proposed a canonical flight identity derived from attributes such as flight number, departure and arrival times, and other relevant flight details.

For monitoring, I suggested tracking backend CPU and memory utilization, backend P99 latency, and supplier-specific P99 latency.

Follow-up questions

1. Streaming and deduplication

If intermediate results are streamed before deduplication is complete, users may see duplicate flights. How can the system return results quickly while avoiding this poor user experience?

2. Latency and SLAs

How should customer-facing latency targets be defined when third-party suppliers have different response times?

3. Backend pod failure

If the pod serving an SSE connection goes down, can another pod resume the stream? How should reconnection and recovery work?

4. Slow suppliers

If 1–2% of suppliers take several minutes to respond, how can the system return fast results while retaining their late responses?

5. Connector-service failure

What happens to in-flight supplier calls and streams if the connector service goes down?

6. Cache failure and recovery

How should the system behave if the cache is unavailable for several minutes and then recovers?

7. Cache technology

Which caching technology should be selected, and why?

Key takeaway: The hardest part was reasoning about failures and recovery across multiple services, rather than drawing the initial architecture. Important considerations included client-facing response deadlines versus supplier-processing lifetimes, stream recovery after pod failures, retaining late supplier responses, and handling cache failures.

Round 4: Culture & Impact

Date: October 14, 2026
Duration: 60 minutes

This round was largely scenario-driven, focusing on practical engineering leadership rather than textbook behavioral questions.

Question 1: Recurring production bugs

If multiple bugs have been appearing over a period of time, how would you investigate and resolve them? How would you identify the root cause and prevent recurrence?

Question 2: Urgent bug with limited technical bandwidth

If a critical bug needs to be addressed soon but the team doesn't have enough technical bandwidth, how would you communicate the situation to your Engineering Manager and Product team?

Question 3: Mentoring and promotions

How do you identify whether a junior engineer is ready for promotion? How would you help them grow and bring out their best?

Question 4: Agile/Scrum improvement

What shortcomings or design flaws have you observed in the current Agile/Scrum workflow? What changes would you introduce to improve it?

Question 5: Cross-team integration testing

How would you organize integration testing involving multiple teams when the deadline is tight? What process would you introduce to coordinate dependencies, identify blockers early, and ensure end-to-end quality?

Key takeaway: Prepare for scenario-based questions covering prioritization, root-cause analysis, stakeholder communication, people development, process improvement, and cross-team collaboration.

A useful way to structure answers is to explain the problem, business and customer impact, available options, trade-offs, execution plan, and expected outcome.

These are the questions I could recall after the interview; there may have been additional questions that I don't remember.

Compensation Details