Sahi Mobile Engineer Interview: Questions, Experience & Prep (2026)

Sahi currently has 3 open Mobile Engineer roles as of July 2026 (source: knok jobradar). The company builds consumer-facing mobile products, and from what candidates report, the interview process is hands-on: expect to be tested on real coding, architecture decisions, and how you have handled production problems.

The wider market for Mobile Engineers across India showed 79 open positions on the same date. Bangalore leads with 21 roles, followed by Delhi and Pune with 3 each, and Mumbai with 2. This context matters: Sahi is hiring in a competitive space, so interviewers will probe both technical depth and your ability to move fast.

Typically, the process runs through a recruiter or HR screen, one or more technical rounds covering coding and system design, and a final conversation with a senior engineer or engineering manager. Candidates report the full loop takes about two to three weeks.

These questions come up frequently in Mobile Engineer interviews at companies like Sahi, based on candidate reports and the nature of consumer product apps:

1. Walk me through a challenging bug you debugged in a mobile app in production. What tools and approach did you use?
2. How do you handle crashes caused by memory pressure or background process termination on Android or iOS?
3. Describe your approach to building a UI that feels smooth on mid-range Android devices.
4. How have you structured navigation and state management in a large app with many screens?
5. Tell me about a time you reduced app startup time or cut APK or IPA size significantly.
6. How do you design for offline-first behaviour in a transactional or financial app?
7. Describe a time you refactored legacy mobile code without introducing regressions.
8. How do you choose between native and cross-platform (Flutter, React Native) for a given product requirement?
9. What is your approach to writing testable mobile code, and which layers do you prioritise testing?
10. Tell me about a feature you owned end-to-end, from design review to release on the app store.
11. How do you evaluate new platform APIs (Android or iOS) and decide when to adopt them?
12. Describe a time you worked closely with a product manager or designer under a tight deadline.

Use the STAR format (Situation, Task, Action, Result) for every behavioural question. Here are three examples tailored to common Sahi-style prompts.

---

Q: Tell me about a time you improved mobile app performance.

*Situation:* Our payments app was showing janky scroll on the home feed on entry-level Android devices and user complaints were rising in reviews.

*Task:* I was asked to identify the root cause and fix it without a full rewrite of the screen.

*Action:* I profiled the app using Android Studio's GPU rendering tool and found we were doing JSON parsing on the main thread inside RecyclerView's bind method. I moved the parsing to a background coroutine, introduced proper view recycling for custom drawables, and replaced one heavyweight image-loading library with a lighter alternative.

*Result:* Frame drops on the affected devices reduced noticeably according to our internal monitoring. The product team reported fewer one-star reviews mentioning slowness in the following release cycle.

---

Q: Describe a time you refactored legacy code without breaking production.

*Situation:* We had a monolithic Activity that handled login, OTP verification, and KYC all in one file with shared mutable state across steps.

*Task:* My task was to break it into separate, testable components as part of a compliance effort.

*Action:* I introduced a step-based navigation pattern using a shared ViewModel, wrote unit tests for each step before touching the existing logic, and then migrated one step at a time behind a feature flag. QA signed off on each step in isolation before the flag was flipped in production.

*Result:* We shipped the refactor with zero production incidents. Test coverage on the auth flow went from near zero to a level that caught two edge-case bugs before the next release.

---

Q: Tell me about a time you collaborated with a designer under a tight deadline.

*Situation:* We had a hard deadline for a loan repayment screen tied to a regulatory requirement. The final design came in late, and the timeline was already compressed.

*Task:* I had to align quickly with the designer, flag what was achievable by the deadline, and deliver a solid experience without cutting accessibility corners.

*Action:* I set up a short sync with the designer to walk through each component and flagged two animations that were risky to implement in time. We agreed to simplify those for v1 and I documented the full design as a backlog item. I also added content description attributes for screen readers proactively.

*Result:* We shipped on time, passed internal QA, and the designer appreciated the early flag rather than a last-minute surprise. The accessibility additions went in at no extra cost to the sprint.

For technical questions: start with first-principles understanding, then walk through your real experience. Interviewers want to see that you know 'why', not just 'what'. If asked about memory management, briefly explain the concept, then describe a time you applied it under real constraints.

For system design questions: think out loud. State your assumptions first: platform, expected user scale, connectivity conditions. Products serving Indian users often run on variable networks, so factor that into your design. Cover data flow, local storage strategy, and how you handle failure gracefully on the client side.

For debugging questions: follow a structured narrative: how you noticed the issue, what you ruled out first, the tool or log that gave you the key signal, the fix, and how you verified the regression did not return. Vague answers like 'I just found the bug' are a common rejection signal.

For behavioural questions: keep Situation and Task brief (two to three sentences each) so you have time for Action and Result, which are the parts interviewers actually weigh. If you do not have a precise number for your result, describe a concrete, observable impact instead.

Based on what candidates at similar product companies typically report, Sahi Mobile Engineer interviewers look for a few things beyond raw API knowledge.

Ownership mindset. They want to hear that you have owned a feature or module, not just executed tickets. Use phrases like 'I decided', 'I proposed', 'I flagged the risk' rather than 'my team did'.

Depth on your platform. Know Android or iOS well enough to discuss lifecycle, threading model, memory behaviour, and common pitfalls. Cross-platform candidates (Flutter, React Native) should still show awareness of what happens at the native layer.

Product thinking. Mobile engineers at consumer apps often sit close to PMs and designers. Showing that you consider user impact, not just technical correctness, sets you apart from candidates who only talk about code.

Clean, readable code. If there is a coding round, write code you would actually commit to a shared repo. Handle the edge case, name your variables clearly, and add a comment only where the logic is genuinely non-obvious. Rushed or hacky code in a live session is a common reason candidates get rejected.

Communication under ambiguity. Think out loud. Interviewers are also checking whether they would enjoy working through a hard problem with you.

Week 1: Strengthen your fundamentals.
Revise the core concepts for your primary platform: Activity or Fragment lifecycle (Android) or UIViewController lifecycle (iOS), threading and async patterns, memory management, and how the OS handles background states. Practise explaining these concepts out loud, not just reading about them.

Week 2: Build and review.
Pick one medium-complexity feature you have built before and prepare to explain every decision you made: architecture choice, data layer, UI layer, testing. Also work through two or three coding exercises on mobile-specific problems such as pagination, debounce input handling, or local cache invalidation.

Week 3: System design and behavioural prep.
Practise one mobile system design problem per day. Good topics include offline-first sync for financial transactions, push notification handling, and a home feed with real-time updates. For behavioural prep, write out five STAR stories covering ownership, conflict resolution, performance work, and cross-functional collaboration. Practise saying each one in under three minutes.

Before the interview.
Research Sahi's product directly: download the app if it is publicly available, note the UX patterns used, and think about what the mobile engineering challenges might be. Candidates who reference specific product observations in interviews are typically remembered by interviewers.

1. Saying 'we' for everything. Interviewers need to understand your individual contribution. Use 'I' when describing your decisions and actions, even if the project was a team effort.

1. Skipping the 'why' on technical choices. Saying 'I used MVVM' without explaining why you chose it over other options tells the interviewer very little. Always connect technical decisions to real constraints or trade-offs.

1. Ignoring offline and low-connectivity scenarios. For apps serving users across India on variable networks, not having a clear point of view on this is a red flag. Prepare a concise answer on how you approach it.

1. Over-engineering system design answers. A microservices answer for a mobile client design question misses the point. Stay focused on the client-side architecture: data flow, state management, and local persistence.

1. Giving vague results in STAR answers. 'The user experience improved' is weak. 'Frame drops on low-end devices reduced noticeably and crash reports fell in the following release' is concrete and credible.

1. Not asking any questions. Candidates who ask nothing come across as uninterested. Prepare two or three genuine questions about the tech stack, how the team handles production incidents, or what the product roadmap looks like for mobile.