ixigo Software Engineer Interview: Questions, Experience & Prep (2026)

ixigo is one of India's leading travel-tech companies, known for train, flight, and bus booking at scale. As of July 2026, ixigo has 14 open Software Engineer roles, and the broader market shows 5,395 Software Engineer openings across India tracked by knok jobradar.

The engineering team at ixigo builds real-time inventory systems, fare prediction models, large-scale data pipelines, and mobile-first products serving hundreds of millions of users. Interviews typically span data structures and algorithms, system design, and a strong emphasis on practical problem-solving tied to the travel domain.

Candidates report a process of 3-5 rounds, typically including an online coding assessment, one or two technical rounds, a system design round for mid-level and above candidates, and a hiring manager or HR discussion. The process is known to be grounded, with interviewers favoring candidates who reason clearly about trade-offs over those who recite textbook answers.

These are the questions candidates most commonly report encountering at ixigo Software Engineer interviews:

1. Design a train seat availability system that handles millions of concurrent queries during Tatkal booking windows.
2. How would you build a real-time fare-alert system that notifies users when a flight price drops below their chosen threshold?
3. Explain a time you improved the performance of a slow API or database query. What was the root cause and how did you fix it?
4. Write a function to find the shortest path between two stations given a graph of routes, covering BFS, Dijkstra, or dynamic programming variants.
5. How do you handle failures in a distributed payment flow? Walk through your approach to idempotency and retry logic.
6. Design a notification service for ixigo that delivers personalized push, SMS, and email alerts without duplicates.
7. What is eventual consistency? When would you accept it over strong consistency in a booking system?
8. Serialize and deserialize a binary tree (or N-ary tree variant), a common test of recursion and data structure fluency.
9. How would you approach A/B testing a new checkout flow without impacting the core booking funnel?
10. Walk us through how you would debug a spike in error rates on a payment gateway integration.
11. Design a caching layer for train schedules and PNR status that stays consistent with IRCTC data updates.
12. Describe a situation where you disagreed with a technical decision made by your team. How did you handle it?

Q: Tell us about a time you improved the performance of a slow system.

*Situation:* At my previous company, our hotel search API was timing out for many requests during peak hours, causing a visible drop in bookings.

*Task:* I was asked to investigate and bring the latency down to an acceptable level.

*Action:* I profiled the API and found that each request was making N+1 database calls to fetch room inventory. I introduced a batch-fetch layer and added Redis caching for inventory that changed infrequently, like room types and amenities. I also moved two heavy aggregation queries to a read replica.

*Result:* Latency dropped sharply and timeout errors were nearly eliminated. The team adopted the caching pattern for two other APIs in the same sprint.

---

Q: Describe a time you had to deliver something under a tight deadline.

*Situation:* Our team was asked to ship a refund-status tracking feature two weeks before a major travel season, as customer complaints about refund visibility were rising.

*Task:* I was the lead engineer on the backend service and had to coordinate with three other teams.

*Action:* I broke the feature into independent deliverables so each team could work in parallel. I set up daily syncs, used feature flags to ship incrementally to internal users first, and wrote a fallback that showed a generic status if an upstream call failed.

*Result:* We shipped on time. The fallback proved useful in the first week when the payment provider had an outage, so users still saw a helpful message instead of a blank screen.

---

Q: Tell me about a technical disagreement you had with a teammate.

*Situation:* A senior colleague wanted to rewrite our notification service in a language the team had minimal experience with, citing performance benefits.

*Task:* I had concerns about delivery risk and the learning curve during a critical product phase.

*Action:* Instead of objecting outright, I drafted a short comparison document covering estimated ramp-up time, risk to ongoing deliverables, and an alternative of profiling and optimizing the existing service first. I shared it before the team meeting so everyone could read it in advance.

*Result:* The team agreed to optimize the existing service first. We found the bottleneck was in the queue consumer logic, fixed it, and the rewrite was deprioritized. My colleague appreciated the structured approach rather than a hallway debate.

For coding questions: Think out loud before writing any code. State the brute-force approach first, estimate time and space complexity, then improve from there. ixigo interviewers typically care about your reasoning process as much as the final solution.

For system design questions: Use a structured flow. Clarify requirements and scale, define the API contract, sketch high-level components, then deep-dive into the area the interviewer cares most about, usually storage, caching, or fault tolerance. Tie your choices to the travel domain, for example, why eventual consistency may be acceptable for search results but not for payment confirmation.

For behavioral questions: Use the STAR format (Situation, Task, Action, Result). Keep the Situation brief, spend most of your time on Action (what you specifically did, not 'we'), and always close with a concrete Result. If you cannot recall a precise figure, describe the impact qualitatively.

For trade-off questions: Candidates who score well at ixigo typically present two or three options, state the trade-offs clearly, and then recommend one with a reason. Avoid presenting a single answer as if it is the only correct one.

Product curiosity about travel tech. Interviewers at ixigo commonly look for candidates who understand the unique constraints of Indian travel: IRCTC API limitations, high concurrency during Tatkal windows, price sensitivity, and users on low-bandwidth mobile connections. Showing that you have thought about these specifics signals genuine interest in the domain.

Practical engineering judgment. ixigo operates at scale with real constraints. Interviewers want to see that you can reason about what is 'good enough' for a given problem rather than over-engineering every solution. Being able to say 'in this case I would accept eventual consistency because...' is valued over a theoretically perfect answer.

Clear communication. Because many ixigo systems span multiple teams and third-party integrations (IRCTC, airlines, payment gateways), interviewers pay close attention to how clearly you explain technical decisions and how you handle ambiguity.

Ownership mindset. Candidates who describe problems using 'I noticed, I investigated, I fixed' rather than 'the team did X' tend to receive stronger feedback. ixigo values engineers who take end-to-end responsibility for what they build.

Week 1: Core data structures and algorithms
Focus on graphs (BFS, DFS, shortest path), trees, heaps, and sliding-window problems. These topics come up frequently in travel-route and search-related questions at ixigo.

Week 2: System design for scale
Study caching strategies (Redis, TTL design), message queues (Kafka or RabbitMQ patterns), and idempotent API design. Practice designing a booking or notification system end-to-end.

Week 3: Domain knowledge and behavioral prep
Read about how large-scale booking platforms handle inventory, concurrency, and third-party API failures. Prepare 5-6 STAR stories covering performance wins, cross-team collaboration, and technical disagreements.

Week 4: Mock interviews and gap-filling
Do at least two timed mock interviews. Review feedback and revisit any weak areas, particularly distributed systems concepts if you are targeting mid or senior roles.

Jumping into code without clarifying the problem. A common pattern in ixigo interviews is that candidates start coding before fully understanding the constraints. Take 2-3 minutes to confirm inputs, edge cases, and scale before writing a single line.

Generic system design answers. Describing a standard three-tier web app without connecting it to travel-specific constraints, like IRCTC rate limits or Tatkal surge traffic, signals that you have not done your homework on the domain.

Using 'we' throughout behavioral answers. If every answer starts with 'our team did,' the interviewer cannot assess your individual contribution. Be specific about what you personally decided, built, or changed.

Ignoring failure modes. In travel booking, how a system behaves when a payment gateway goes down matters as much as the happy path. Candidates who only design the success case miss a major evaluation criterion at ixigo.

Not asking any questions at the end. Strong candidates typically ask at least one thoughtful question about the team, the technical challenges, or the product direction. It signals genuine interest and leaves a positive impression.