Zomato iOS Engineer Interview: Questions, Experience & Prep (2026)

Zomato is one of India's most recognised consumer tech brands, running food delivery, quick commerce (Blinkit), and dining discovery products for millions of users. The iOS team builds features that must work reliably in real-world conditions: live rider location on a map, order status updates that arrive in seconds, and smooth performance across a wide range of iPhones and patchy networks.

As of July 2026, Zomato has 9 open iOS Engineer positions. Across India, the knok jobradar shows 70 iOS Engineer openings in total, with Delhi accounting for 21, Bangalore for 6, Mumbai for 3, and Chennai for 2.

Candidates report the interview process typically runs across three to five rounds. You can expect a coding screen focused on data structures and algorithms, one to two iOS technical rounds covering Swift, UIKit or SwiftUI, memory management, and concurrency, and a final hiring manager conversation. Senior candidates typically also face a system design round. Zomato has not published an official process, so treat these details as commonly reported patterns rather than guarantees.

These questions come up repeatedly in Zomato iOS interviews, based on what candidates have shared publicly:

1. How does Automatic Reference Counting work in Swift? Walk us through a retain cycle you encountered and how you resolved it.
2. What are the trade-offs between UIKit and SwiftUI? Which would you choose for a real-time order-tracking screen and why?
3. How would you design an offline-first experience for a food-ordering app where the user loses connectivity while placing an order?
4. Zomato shows a live rider location on a map. How would you implement battery-efficient and data-efficient location updates on iOS?
5. How have you improved app launch time or scroll performance in a production app? What tools and metrics did you use?
6. When do you use GCD, OperationQueue, or Swift concurrency (async/await, actors)? Give a concrete example from your own work.
7. How would you architect a 'live order status' feature that combines push notifications with WebSocket or periodic polling?
8. Walk us through your approach to unit testing and UI testing on iOS. How do you test code that depends on network responses?
9. How do you handle breaking API changes from the backend without forcing all users to update the app immediately?
10. How would you reduce battery drain and data usage in a screen that needs frequent delivery status refreshes?
11. Tell us about a time you shipped a feature under a tight deadline. What trade-offs did you accept and how did you decide?
12. How would you debug a crash that only reproduces on specific device models and affects a small subset of users?

Use STAR (Situation, Task, Action, Result) for both behavioural and product scenario questions. Here are three examples tailored to Zomato iOS interviews.

---

Q: Tell us about a time you debugged a serious memory problem in your iOS app.

*Situation:* Our food-ordering app began crashing for users who browsed the menu for an extended session. Crash reports pointed to memory pressure but the stack traces were not specific enough to find the root cause.

*Task:* I needed to identify and fix the problem without delaying a release that was only a few days away.

*Action:* I profiled the app using Instruments' Allocations and Leaks tools. I found a retain cycle between a view controller and a closure passed to a custom image-caching layer. The closure captured 'self' strongly, and the view controller also held a strong reference to the cache object. I added 'weak self' inside the closure and wrote a unit test asserting that the view controller deallocated after dismissal.

*Result:* Memory growth during menu browsing stopped. The crash rate dropped sharply in the next release, and the unit test was added to our CI pipeline to prevent the same bug class from returning.

---

Q: How have you improved scroll performance in a production iOS app?

*Situation:* A restaurant menu screen with images and dynamic cell heights was dropping frames on older iPhones. Users were reporting the app felt sluggish.

*Task:* Get the menu list scrolling smoothly without removing any features.

*Action:* I used Instruments' Core Animation profiler and found that off-screen rendering caused by corner radius and layer shadows on every cell was the main bottleneck. I replaced the CALayer shadows with pre-rendered shadow images, moved cell height calculations off the main thread into a sizing cache, and added image prefetching so cells loaded before they entered the visible area. Images for off-screen cells were cancelled as soon as those cells left the viewport.

*Result:* Frame drops went from frequent to rare across the device range we tested. The screen passed our internal performance review before the release.

---

Q: Describe a time you had to make trade-offs to ship a feature on time.

*Situation:* Our team was building a new checkout flow with a hard launch date tied to a marketing campaign the business had already committed to publicly.

*Task:* The full feature scope could not be built and tested safely in the time remaining.

*Action:* I listed every planned piece of the feature and divided them into 'must work at launch' and 'can ship in the next sprint'. After aligning with the product manager, we deferred animated transitions and a save-for-later option. I wrote a short technical note documenting the deferred work so it would not get lost. I also added a feature flag so we could disable the new checkout flow remotely if a critical issue appeared after launch.

*Result:* We shipped on time. The campaign ran without incident. The deferred features were completed in the next sprint and the feature flag has since been removed.

For Swift and iOS technical questions, lead with the concept in plain terms, then give a concrete example from your own code, then address trade-offs or edge cases. Interviewers at Zomato want evidence that you have used the concept in real production work, not just read about it before the interview.

For system design questions, follow a consistent structure: clarify requirements and scale, map out the data flow, choose your networking approach (REST, WebSocket, or polling), address offline and error states, then discuss performance and testability. For Zomato-style prompts like 'design the live order tracking screen', walk through how the iOS app receives updates, how it refreshes the map efficiently, and how it behaves when the network is poor or drops entirely.

For behavioural questions, use STAR. Keep Situation and Task to two or three sentences each. Spend most of your time on Action, and say 'I' rather than always 'we', so the interviewer can see your specific contribution. Make Result concrete: a metric, a concrete outcome, or a decision that stuck.

For product sense questions (common at Zomato), anchor your answer in the user. Identify who the user is, what friction they face, and how your suggestion removes it. Interviewers frequently ask 'how would you improve the order tracking screen' or 'what would you add to Blinkit', so think through your answers to these before the day.

Zomato iOS interviewers typically look for a few qualities beyond knowing Swift syntax.

Product empathy. Zomato is a consumer product used under real pressure: a user waiting for food late at night, a delivery partner handling multiple orders at once. Candidates who think about how a feature affects these people stand out. Using the app regularly before your interview genuinely helps.

Depth, not just surface knowledge. Saying 'use weak self to break retain cycles' is a starting point. Interviewers will follow up with 'why does ARC work this way' and 'how did you actually find the leak'. Know the mechanism, not just the fix.

Performance instinct. Zomato's app runs on a wide range of devices and network conditions. Candidates who have profiled apps with Instruments, measured frame rates, and thought seriously about battery impact are preferred over those who only theorise about performance.

Structured communication. Can you ask a clarifying question before jumping into a system design? Can you explain a complex concept without jargon? Interviewers specifically note whether you think out loud clearly, especially in design rounds.

Ownership. Talk about what you specifically did. Candidates who say 'I investigated', 'I decided', and 'I fixed' come across as more credible than those who credit the team for everything without identifying their own contribution.

Swift and iOS fundamentals (start here)

Review ARC and memory management in depth. Understand value types versus reference types, protocol-oriented design, and Swift concurrency (async/await, actors, Task groups). Practice explaining these concepts out loud, because the interview will ask you to.

UIKit and SwiftUI

Build or revisit a small project that uses both frameworks. Focus on table views and collection views with dynamic content, custom layouts, and efficient image loading. Review how to keep the main thread clear for rendering.

Mobile system design

Practice designing features similar to Zomato's own product. Think through a live location tracking screen, an order status feed, and a cart with offline support. For each, consider the networking layer, local caching, error and empty states, and battery usage.

Behavioural preparation

Write out three to five STAR stories from your past work. Cover a bug you tracked down, a feature you shipped under pressure, and a technical decision you owned. Practice saying them out loud until they feel natural.

Zomato product research

Use the Zomato and Blinkit apps for a few days before your interview. Form opinions on two or three features you would improve or redesign. Interviewers respond well to candidates who clearly know the product.

Coding practice

Practice data structures and algorithms in Swift. Focus on arrays, hash maps, linked lists, trees, and graph traversal. The initial coding screen tests these fundamentals.

1. Underestimating behavioural rounds. Zomato puts real weight on ownership and collaboration. Vague answers like 'the team handled it' hurt candidates even when their technical rounds go well.

2. Knowing the API without understanding it. Saying 'I use DispatchQueue.main.async to update the UI' is a starting point. Interviewers will ask why, and what happens if you skip it. Understand the thread model behind the call, not just the syntax.

3. Not using the Zomato app before the interview. Candidates who have no opinion on the product miss easy opportunities to show product thinking. Use the app. Form a view on what works and what could be better.

4. Skipping clarifying questions in design rounds. Starting a system design answer without defining scope, scale, and constraints signals that you jump to solutions before understanding the problem. This is a clear red flag.

5. Only handling the happy path. When writing code or designing a feature, covering only success cases and ignoring timeouts, errors, and edge cases makes interviewers worry about your production instincts.

6. Claiming to care about performance without having measured it. If you have never opened Instruments, spend a few hours profiling any iOS project before your interview. You will almost certainly be asked about specific profiling tools and what you found.