Download App
It was past midnight, I was lying in bed refreshing my inbox for no reason I could justify to myself, and there it was. Subject line: "Welcome to Swiggy." I read it twice before it registered, then a third time to make sure I hadn't misread "SDE-1, Android" as something else. That's the end of the story. Let me back up, because the part in between the application and that email is the part nobody's Swiggy interview experience post actually walked me through when I went looking for one.
Five weeks earlier I'd applied cold through Swiggy's careers page — one off-campus application among maybe thirty I'd sent out that month to product companies, most of which had gone nowhere. My college isn't the kind that gets on-campus drives from names like Swiggy, so off-campus interview experience was basically my only route in: apply, wait, mostly get ghosted, repeat. I'd genuinely stopped expecting replies by the time the OA link showed up at 11:47 pm one night, sandwiched between a food delivery promo email and a placement WhatsApp group forward. I almost scrolled past it without opening it.
Preparing for a Swiggy Android developer interview when nobody tells you what to expect
Here's the thing that frustrated me most in the run-up: most "Swiggy interview experience" threads I found before mine were either backend-flavored or so vague they were useless — "asked DSA questions, cleared it, got the offer," with zero specifics on whether the Android round leans Java or Kotlin, whether they touch Jetpack Compose, whether it's lifecycle trivia or actual system-design-lite. So I split my month of prep roughly down the middle, which in hindsight was still not enough weight on the Android side — more on that later. DSA prep was the usual grind: arrays, sliding window, graphs, a fair amount of dynamic programming, redone on paper first because typing straight into an IDE was making me lazy about actually reasoning through edge cases. Android prep was scattered — activity and fragment lifecycle, RecyclerView internals, coroutines and structured concurrency, a light pass over Jetpack libraries I'd used in my own side projects but never had to explain out loud to a stranger evaluating me.
Round 1: the Swiggy OA and what the coding questions actually looked like
The OA itself had two problems, and neither was Android-specific, which threw me a little given how much time I'd spent worrying about being asked to explain ViewModel scoping under a countdown timer. First one was a sliding-window string problem — longest substring with at most k distinct characters, the kind of pattern you've solved a dozen times on LeetCode under a different skin. Solved it clean in under twenty minutes. Second was a graph reachability problem wearing a "delivery zone coverage" costume, cute theming for an online assessment at a food delivery company. My first submission timed out on two test cases because I was running a fresh BFS from every single node instead of just reversing the graph once and doing one pass. Fixed it with under two minutes left on the clock. My hands were not steady typing that final submit.
Then came the part that's honestly harder than the OA itself: the silence after. Four days of checking email every couple hours, refreshing the careers portal for no logical reason, telling myself the radio silence meant nothing while absolutely reading it as a rejection in progress. When the recruiter call finally came, both technical rounds got scheduled for the same evening, thirty minutes apart — which I've since learned is fairly typical of how fast the Swiggy interview process moves compared to the multi-week gaps I'd braced for from bigger, more bureaucratic names.
Round 2: the DSA interview round
This round was pure data structures and algorithms, no Android in sight yet. The interviewer opened with reversing a linked list in groups of k — a classic, but classics get you when you're nervous. I drew the wrong number of nodes on my scratch paper on the first attempt and thoroughly confused myself about which pointer was supposed to point where. My interviewer just waited. Didn't hint, didn't fill the silence with a reassuring "take your time" — which somehow felt worse than if he had said something. I ended up talking through the confusion out loud, re-drew the diagram properly, and landed on a working solution in about twelve minutes. He then added a follow-up: handle the edge case where the final group has fewer than k nodes remaining, which I hadn't fully accounted for in my first pass and had to patch live.
We moved to a cycle-detection question after that — find not just whether a cycle exists but where it starts, Floyd's algorithm territory. I got the "does a cycle exist" part fast from memorized pattern-matching, but deriving why the meeting point works, and how to then find the cycle's start, took real thinking on the spot rather than recall. That distinction, I think, is what the round was actually testing.
Round 3: the Swiggy Android technical interview questions
This is the part every generic "SDE-1 interview experience" post skips, because most of them aren't written by Android candidates. The round opened with an Activity and Fragment lifecycle walkthrough, expected, low-stakes warmup. Then it went somewhere I wasn't ready for: "how would you handle a memory leak caused by a Handler holding an implicit reference to an Activity." I knew this, somewhere in my head — static inner class plus a WeakReference, or better yet, lean on lifecycle-aware components instead of fighting the framework manually — and still blanked for a solid ten seconds before I said "give me a second, thinking out loud here" and worked backward to the answer piece by piece instead of freezing entirely.
From there we covered why notifyDataSetChanged() is a lazy anti-pattern compared to using DiffUtil with a RecyclerView, and a coroutines question about structured concurrency — specifically, what happens to child coroutines when their parent scope gets cancelled, and why that matters for avoiding leaked background work in an Android app. Not one question I'd specifically drilled for in isolation; all of it required actually understanding the why behind patterns I'd used without always questioning them.
The Swiggy hiring manager round
Another week of the email-checking ritual, and then the HM round. My wifi cut out mid-sentence while I was answering a question about disagreeing with a teammate on a technical decision — forty seconds of dead call, a scramble to reconnect, and having to restart my answer slightly awkwardly from a point that wasn't quite where I'd left off. The hiring manager just said "no worries, continue whenever you're ready," and something about that small bit of patience took all the pressure out of the rest of the conversation.
The round itself wasn't the grilling I'd braced for — one question about handling ambiguous requirements from a PM, one about how I'd approach diagnosing and fixing slow app cold-start times, and then, honestly, mostly just a conversation about things I'd built. I'd mentioned a side project — a small habit-tracker app with local notifications and a Room database — and he spent a genuine ten minutes just asking about the design decisions behind it, not testing me, just curious. It felt less like an evaluation by the end and more like two people talking shop.
Six days of silence, then the offer
The email landed close to midnight again, oddly enough — I'd just closed my laptop after a late DSA revision session, opened my phone one last time out of habit, and there it was. No call first, no heads-up. Just there, sitting quietly in my inbox like it had been waiting for me to check.
What I'd change about my Swiggy interview prep
If I'm honest about it: I spent roughly eighty percent of my prep time on pure DSA and crammed all the Android-specific material into the final week, which is backwards for a role that's literally titled Android SDE-1. If you're prepping for a similar Swiggy Android developer interview, I'd weight lifecycle, memory management, RecyclerView internals, and coroutines equally against the DSA grind from week one, not as an afterthought squeezed in later. The blanking-out moments also cost me far less than I feared going in — saying the quiet part out loud ("thinking out loud here") bought more goodwill in both technical rounds than staying silent while I scrambled ever would have. And some of the mock interview practice and resume feedback I ran through on devsunite.com/resources before any of this started is honestly what got my off-campus application taken seriously in the first place — worth a look if you're at the start of your own grind and staring down the same silence I was staring down five weeks before that OA link showed up.