Swiggy Phone Screen Interview: What It Tests and How to Pass

The Swiggy phone screen is two separate filters most candidates blur into one. The first is an async online assessment: no interviewer, no conversation, just a timer and a code editor staring at you like a disappointed parent. The second is a live technical call with a senior engineer who wants to watch you think. Both gates have to fall before you move on.

Two Gates, Not One

When engineers say "Swiggy phone screen," they usually mean one of two things. Picking the wrong one means prepping for the wrong test.

The recruiter call (15-30 minutes) is not a technical filter. Background check, role alignment, compensation range. Swiggy recruiters use it to confirm basic fit before spending engineering time on you. No DSA here. You're not getting grilled on binary trees over Google Meet.

The online assessment (OA) is the real gate. It runs on HackerRank or HackerEarth, takes 90-120 minutes, and has 2-3 coding problems. For most SDE-1 pipelines, the OA is the phone screen equivalent. For experienced hires and some SDE-2 tracks, there's also a live technical call before the full onsite loop.

Know which gate you're walking up to before you sit down to prep.

What the Swiggy OA Actually Looks Like

The OA is async. You get a link, a window to complete it (usually 24-72 hours), and a countdown once you start. It is, in the classic tradition of online assessments, just you and your terminal and all your bad habits about skipping edge cases.

Component	Details
Duration	90-120 minutes
Problems	2-3 DSA problems
Difficulty	Medium (LeetCode equivalent)
Platform	HackerRank or HackerEarth
Extras	SQL queries (backend roles), MCQs, debugging tasks

Your score is based on correctness, efficiency, and code readability. Partial credit exists in some configurations, but a solution that passes all test cases with clean code is the target. A working brute force beats elegant pseudocode you didn't finish. Always.

For backend-focused roles, SQL questions occasionally appear alongside the DSA problems. These are not warmups. Expect multi-table JOINs, window functions, or aggregation queries on realistic schemas. Backend engineers who skimmed the SQL review are the ones who exit the OA confused at themselves.

What Swiggy Is Actually Evaluating

From candidate reports and Swiggy's own engineering blog, evaluators care about three things.

First: does your solution work? Many candidates submit partial solutions verified only against the sample test cases. Swiggy's hidden test suite will find empty inputs, single-element arrays, and overflow scenarios you didn't think about. The test suite is not sentimental. Test those yourself before hitting submit.

Second: does it work within reasonable time complexity? Two O(n²) brute forces might pass on small inputs, or they might not. Assume they won't on larger constraints. Write the efficient version when you can see it.

Third: is the code readable? This one catches people off guard. Variable names, clear logic flow, brief comments on non-obvious steps. The same interviewers often run your live rounds later. They already have an impression from your OA code. Make that impression correct.

Which DSA Patterns Actually Come Up

These patterns appear most often across reported Swiggy OA problems.

Arrays and hash maps. Frequency counting, two-sum variants, sliding window for substring problems. If you're slow here, you'll run out of time on anything harder. This is the floor, not the ceiling.

Trees. Binary tree problems: Lowest Common Ancestor, root-to-leaf sum paths, BST operations. Catalan number questions (counting structurally unique BSTs) have appeared in some rounds, so don't completely ignore the theoretical side.

Graphs. BFS-based shortest path and connectivity. Swiggy builds routing and logistics systems, so graph problems map directly to the domain. They're not asking you about graphs as an academic exercise. They actually solve these things on production hardware at scale.

Dynamic programming. Edit Distance, Maximum Length of Pair Chain, Longest Valid Parentheses. Medium-difficulty problems with clear recurrence structures.

Strings. Longest palindromic substring, valid parentheses, string manipulation variants. Usually one per OA.

Linked lists. Intersection of two lists, cycle detection. Less common than trees, but present.

For backend roles, one SQL problem tends to be straightforward (GROUP BY, aggregation) while a second is more involved (window functions, nested queries).

Swiggy designs its OA around problems that echo real engineering work: routing, scheduling, aggregation, search. Knowing this helps you prioritize what to cover and skip what you don't need.

The Live Screen Is a Different Game

If you're applying at SDE-2 or coming in with several years of experience, there's often a live technical call before the full onsite loop. One or two DSA problems, 60-70 minutes, a senior engineer on the other end.

The tone is deliberately collaborative. Swiggy tech leads describe it as a conversation. They want to know your reasoning, not just your result. Why did you choose that data structure? What's the time complexity? Are there edge cases you haven't handled?

This is the round where going silent is the fastest way to lose. A candidate who arrives at a good solution in complete silence is harder to evaluate than one who narrates a wrong turn before correcting it. Silence is not a strategy. It is, for all practical purposes, just giving the interviewer nothing to write down about you.

The live screen also sometimes includes a brief project discussion. Have one or two concrete examples ready: a technical decision you owned, a performance problem you diagnosed, a system you designed. Thirty seconds of context, then let them drive with follow-up questions. Don't monologue.

The Bar Shifts at SDE-2

For SDE-1 candidates (fresh graduates and engineers with up to two years of experience), the OA is the primary filter. The bar is solid fundamentals on medium-difficulty DSA. No system design, no low-level design at this stage. Get your trees, graphs, and DP clean.

For SDE-2 candidates (three to six years of experience), the OA format is similar but the live screen has higher expectations. Interviewers expect you to propose optimizations without being prompted, discuss trade-offs between approaches, and connect your solution to production-grade thinking.

The SDE-2 path also moves faster toward LLD and system design later in the loop. Those come after the phone screen, but interviewers at the live technical stage will probe for whether you think beyond the immediate problem.

A Prep Strategy That Actually Works

Four weeks is enough for most candidates. Two weeks if you're already practicing regularly.

Week one. Core patterns: arrays, hash maps, two pointers, sliding window, binary search, basic trees. Two or three problems per pattern. Time yourself. Stop reading solutions before you genuinely attempt the problem. The dopamine hit of immediately checking the answer is not the same thing as learning.

Week two. Graphs (BFS, DFS, cycle detection) and dynamic programming (1D DP, 2D grid DP, interval DP). These take longer to internalize. One pattern per day, and DP gets more days than you think it needs. That is not a suggestion.

Week three. Mix patterns. Do 45-minute timed sessions without topic tags. The OA does not announce what pattern it wants. Identification is the actual skill being tested, not just execution.

Week four. SQL if your role is backend-focused. Edge case review across every pattern. At least two full simulated OA sessions under real time pressure.

For the live screen, practice explaining your approach out loud before writing a single line of code. The clarification step and reasoning narration are not formalities. They're scored. SpaceComplexity runs voice-based DSA mock interviews with rubric-based feedback, which directly simulates Swiggy's live screen format. A few reps there are worth more than grinding twenty silent problems.

For a deeper look at what the backend engineering bar looks like at companies like Swiggy, see the DSA for backend engineers guide.

Mistakes That Get You Filtered Out

Submitting without testing. The OA has hidden test cases. Candidates who only verify against the sample inputs get caught by edge cases every time. Before submitting: empty input, single element, maximum constraint. This takes two minutes. There is no good excuse for skipping it.

Going silent in the live screen. If you don't know the optimal approach immediately, say so. Describe the brute force, explain its cost, then ask yourself out loud what information you're not using. Silence is the most common reason qualified candidates fail live rounds. There's a detailed breakdown in the technical interview communication guide.

Ignoring SQL. Backend candidates often over-index on DSA and walk into the SQL section underprepared. A missed SQL problem on the OA can cost you the round. The SQL section is not going to warn you it's coming.

Not reading the constraints. Swiggy's OA problems are designed with constraints that hint at the expected complexity class. An input size up to 10^6 tells you O(n log n) or better. Solve for the constraint, not just the happy path.

More on the OA format is in the online assessment coding interview guide. For the full Swiggy loop after you clear the phone screen, the complete Swiggy interview guide covers every round end to end.

Before You Go

Two distinct stages: recruiter call (no technical bar) and OA (the real filter).
OA: 90-120 minutes, 2-3 medium DSA problems on HackerRank or HackerEarth. SQL added for backend roles.
Common patterns: arrays and hash maps, trees (LCA), graphs (BFS), DP (Edit Distance, Pair Chain), strings.
Scoring weights correctness, then efficiency, then readability. Hidden test cases probe edge cases.
SDE-2 adds a live 60-70 minute call where communication of reasoning is explicitly evaluated.
Test edge cases before submitting. Going silent in the live round is the most common preventable failure.