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

sminq is a healthcare technology company that helps patients book appointments and track real-time clinic queues across India. The product is mobile-first, which means the Mobile Engineer role sits at the core of what the company ships every sprint. With 4 open roles currently at sminq and 79 Mobile Engineer positions active across the market as of July 2026, the opportunity is real but the bar is specific: interviewers want engineers who connect mobile decisions to patient and clinic-staff workflows, not just engineers who know the theory.

Candidates typically move through an initial screening call, one or two technical rounds covering coding and system design, and a closing conversation with a senior engineer or leadership. Expect the technical rounds to focus on real-time features, offline reliability, and booking-flow architecture, all of which map directly to what sminq ships. Prepare to discuss your past projects in concrete terms and to show genuine curiosity about the product.

Based on what candidates report and the nature of sminq's product, these questions come up most often.

1. How would you build a real-time queue status feature that shows patients their current position in a clinic queue?
2. How do you handle offline or low-connectivity scenarios in a patient-facing mobile app?
3. Walk me through how you would optimize app startup time for a cold launch.
4. How do you manage push notifications for appointment reminders without draining the user's battery?
5. What is your approach to state management in a complex booking flow that spans multiple screens?
6. How would you design the architecture of a patient profile screen that pulls data from multiple API endpoints?
7. How do you implement deep linking so a notification tap lands the user directly on their appointment detail?
8. Walk me through how you would handle a race condition where two users try to book the last available slot at the same time.
9. How do you approach background data sync so clinic availability stays fresh without a manual pull-to-refresh?
10. What is your strategy for testing mobile features in a slow or intermittent network environment?
11. How would you integrate a payment gateway like Razorpay into an appointment booking flow?
12. How do you decide whether a feature should be built natively or handled via a WebView?

Q: How would you build a real-time queue status feature?

*Situation:* At my previous company we built a token-based queue display for a retail kiosk app. Users needed to see their position update live without hammering our servers.

*Task:* I was responsible for the mobile client side, including choosing the real-time communication approach and keeping battery usage acceptable.

*Action:* I evaluated polling, Server-Sent Events, and WebSockets. Because queue position only flows server-to-client, I chose SSE. On Android I managed the SSE connection inside a foreground service so it survived screen rotation. I added exponential backoff on reconnect and cached the last known position locally so users saw something immediately on reopen.

*Result:* Queue position updated within a couple of seconds of a server event. Battery impact was noticeably lower than a five-second poll loop, and user complaints about stale queue data dropped after the release.

---

Q: How do you handle offline or low-connectivity scenarios?

*Situation:* We shipped a field-agent app where users worked in areas with patchy coverage. Appointment data had to be accessible even without a connection.

*Task:* I needed to design an offline-first data layer without introducing sync conflicts that could corrupt booking records.

*Action:* I introduced a local Room database as the single source of truth. All reads went through the local DB; a background WorkManager job synced deltas with the server when connectivity returned. I used last-write-wins with server timestamps for conflict resolution and surfaced a small 'Syncing...' chip in the UI so users always knew the data freshness state.

*Result:* Core read flows worked fully offline. Sync failures retried automatically, and in several months of production we had zero data-loss reports from the field team.

---

Q: How would you integrate Razorpay into a booking flow?

*Situation:* A healthtech side project I worked on needed to collect a consultation fee at the time of booking.

*Task:* I had to integrate the Razorpay Android SDK in a way that handled payment failures gracefully and did not double-charge the user on a retry.

*Action:* I created the order on the backend first, stored the order ID, and only opened the Razorpay checkout after a successful order creation. On the payment callback I verified the signature server-side before marking the booking confirmed. For retries I reused the existing order ID rather than creating a new one, which prevented duplicate charges.

*Result:* We had zero duplicate-charge incidents across all test and production transactions. The backend-first approach also made it straightforward to add refund logic later without touching the mobile payment flow.

For system design questions (real-time queue, offline sync, booking architecture): use a 'requirements first, options next, tradeoffs last' pattern. State what constraints matter most in a healthcare context, such as data freshness, reliability, and graceful degradation. List two or three technical approaches briefly, then pick one and justify it in terms of the product's actual scale and user needs. Interviewers at product startups reward reasoning over rote answers.

For debugging and performance questions (startup time, battery drain, slow renders): describe a systematic process. Profile before you theorize. Name the specific tools you use, such as Android Studio Profiler, Xcode Instruments, Flipper, or Systrace. Then describe what you found and what you changed.

For past-experience questions: use STAR cleanly. Keep the Situation and Task brief so you spend most of your time on Action (the technical specifics) and Result (a concrete outcome, even a qualitative one counts).

For product-instinct questions (native vs. WebView, feature prioritisation): anchor your answer in user impact and engineering cost. Show that you think of patients and clinic staff as real users, not abstract API consumers.

Product empathy first. sminq's users are patients waiting to see a doctor and clinic staff juggling a full schedule. Interviewers want to see you connect technical decisions back to these users. Saying 'I chose SSE because patients should not stare at a stale queue number' lands better than a purely theoretical justification.

Ownership mindset. This is a startup. Candidates who say 'the backend team handles that' without showing they understand the full data flow tend not to progress. Show that you have worked across the API contract, understood the data model, and raised issues when something affected the mobile experience.

Reliability thinking. Healthcare apps have low tolerance for data errors. Interviewers look for candidates who proactively think about edge cases: what happens when the network drops mid-booking, or two users race on the same slot? Bring these up yourself rather than waiting to be prompted.

Clean, readable code. Candidates report that sminq typically includes a take-home or live coding exercise. Write code you would be comfortable explaining line by line. A working, readable solution beats an ambitious one that is half-finished.

Week 1: Core mobile fundamentals

Revise the lifecycle of Activities or ViewControllers, background execution limits on Android and iOS, and memory management. Practice one medium-difficulty data structures problem daily to warm up for the coding round.

Week 2: sminq-specific scenarios

Use the sminq app as a patient and explore the booking flow end to end. Notice the real-time elements and where the app might feel slow or uncertain. Build a small prototype such as a live-updating list or an offline-first note app so you have a concrete example ready when asked.

Week 3: System design and behavioural polish

Practice designing the queue status feature and the booking flow end to end, including the API contract and error states. Record yourself answering one behavioural question per day and check that your STAR answers stay concise and outcome-focused.

Day before the interview: Review your past projects for specific outcomes you can mention. Prepare two or three questions to ask the interviewer about the team's release cadence, tech stack choices, and how mobile and backend engineers collaborate day to day.

Skipping the product context. Candidates who treat sminq as a generic mobile role and give textbook answers without referencing healthcare or appointment workflows miss the point of most questions.

Over-engineering design questions. Proposing distributed caches and event queues for a feature that a single persistent connection and a local cache would solve tells interviewers you have not thought about the actual scale and team size.

Ignoring error states. Describing only the happy path (booking succeeds, payment goes through, notification arrives) and skipping failure handling is a common red flag in healthtech interviews where reliability is non-negotiable.

Weak results in STAR answers. Saying 'it worked out well' without any outcome makes your experience hard to evaluate. Even qualitative results ('user complaints dropped', 'the PM confirmed fewer support tickets') are better than nothing.

Not asking questions. Candidates report that interviewers at startups like sminq expect genuine curiosity about the product and the team. Arriving with no questions reads as low interest.