Blinkit SDE-2 Backend Interview Experience — Hired in 10 Days

I recently interviewed for the SDE-2 Backend role at Blinkit and got hired. End to end — first recruiter call to offer letter — took about 10 days. Three technical/cultural rounds, an HR call the same day as the final round, and the offer letter landed the same day as well.

This post is a walkthrough of what each round looked like, where I did well, where I struggled, and what I would do differently. If you're preparing for Blinkit or any mid-level backend role, hopefully this helps.

Timeline

Stage	What happened
First call	Recruiter outreach / screening
Round 1	Resume + DSA
Round 2	Resume + System Design
Round 3	Cultural fit + compensation discussion
Same day	HR call + offer letter

Outcome: Hired as SDE-2 Backend Engineer.

Round 1 — Resume Deep Dive + DSA

The interviewer started with my resume. I answered in the STAR pattern (Situation, Task, Action, Result) for the projects and impact points they dug into. That part went smoothly — if you own your resume stories, this is free ground.

Then we jumped to DSA.

Problem: Subarrays whose sum is divisible by K

Given an array of integers and an integer k, find the number of subarrays whose sum is divisible by k.

I clarified constraints first (array size, value ranges, constraints on k) before jumping into solutions. Always do this — it signals that you care about correctness under scale, not just the happy path.

Approaches I discussed

I walked through all three approaches before coding the optimal one:

Naive brute force — O(n²)
Generate every subarray, compute its sum, check sum % k == 0.
Prefix sum brute force — still O(n²)
Build a prefix sum array so range sums are O(1), but you still check every (i, j) pair. Better constants, same complexity class.
Optimized — prefix sum + hashmap — O(n)
The key insight: if two prefix sums have the same remainder modulo k, the subarray between them is divisible by k.
```
prefixSum % k == r  and  earlierPrefixSum % k == r
⇒ (prefixSum - earlierPrefixSum) % k == 0
```
Maintain a frequency map of remainders seen so far. For each new remainder r, add map[r] to the answer, then increment map[r]. Don't forget remainder 0 (and negative remainders if your language's modulo can go negative).

I coded the optimized solution. That part was solid.

Follow-up: Print those subarrays

After counting, the interviewer asked me to print / return the actual subarrays whose sum is divisible by k.

My approach: instead of only storing frequencies of remainders, also store indices (e.g. another hashmap from remainder → list of indices where that remainder appeared). Then for each matching remainder pair, reconstruct the subarray using the index range.

I explained the approach clearly but couldn't fully code the follow-up in time. Still honest about that in the debrief with myself — knowing the idea and shipping the code under pressure are different skills.

Verdict: Passed for Round 2.

Round 2 — Resume + System Design

Resume again, dug a little deeper this time — ownership, tradeoffs, scale numbers. Then the main problem:

Design: Distributed Logging Service

Requirements I had to design for:

High throughput log ingestion
Durable storage
Users can pre-define custom filters on stored logs
Query / filter logs using those custom filters

What I designed

I went with Cassandra as the primary store for high write throughput and horizontal scale — a natural fit for append-heavy log traffic.

Where I struggled was the custom filter requirement. Cassandra is excellent for known access patterns; free-form, user-defined filters on arbitrary log fields is not its sweet spot.

Approaches I proposed mid-interview

While thinking through the filter problem, I offered a couple of hybrid ideas:

Cassandra as write path + cron → MySQL for query/filter path
Ingest logs into Cassandra at high throughput. A background job periodically moves / projects data into MySQL so users can run flexible filter queries.
MySQL as source of truth + cron preparing Cassandra for known access patterns
Flip it: MySQL holds the queryable data, and Cassandra is precomputed for the high-throughput / specific access patterns we already know about custom filters.

Both show tradeoff thinking (write path vs read path, OLTP vs wide-column), but neither is the clean industry answer for this problem.

The right direction

The interviewer steered toward the expected solution: use OpenSearch / Elasticsearch (or a similar search/analytics store) for the filter and query layer.

That fits the product requirement much better:

Full-text and structured queries on log fields
User-defined filters map naturally to query DSL
Scales for search-heavy workloads while a write-optimized store (or queue + bulk index pipeline) can still handle ingestion

In hindsight, a solid architecture looks roughly like:

Producers → Kafka / queue → Ingestion workers
                              ├─→ Cassandra / object store (raw durability, cheap retention)
                              └─→ OpenSearch / Elasticsearch (filterable, searchable)

Custom filters become saved queries (or filter templates) that run against OpenSearch at query time — no need to invent a second relational mirror just to support filtering.

How the round ended

Time ran out before I fully landed on OpenSearch myself. But roughly 90% of the interview was on point — requirements, high-throughput path, storage choices, and the thinking process on the DB tradeoffs were solid.

Verdict: Passed for Round 3. The panel valued structured thinking even when the final tech choice wasn't perfect.

Round 3 — Cultural Fit (+ Compensation)

This was a shorter round — about 15–20 minutes — with the hiring manager.

Typical questions:

Why do you want to join Blinkit?
Why are you leaving your current company?

Keep answers honest and specific. For me, the pitch was about scale (real-time inventory, logistics, consumer apps under heavy load), ownership at the SDE-2 level, and wanting to work on backend systems that move product metrics, not just tickets.

Compensation was also discussed in this round by the manager.

Verdict: Hired for SDE-2 Backend Engineer.

Same-day close

After the cultural fit round:

HR call the same day
Offer letter the same day

From first conversation to signed-path offer, the entire loop closed in about 10 days. Fast processes feel great when you've prepared — less time to overthink between rounds.

What I learned (and what I'd tell past-me)

1. Own your resume in STAR

Both Round 1 and Round 2 opened with resume. If you can't explain impact with numbers and tradeoffs, you burn early goodwill before the hard questions start.

2. Always clarify constraints on DSA

Constraints change which approach is "correct." Saying them out loud also buys you structure while you think.

3. Discuss multiple approaches before coding

I walked brute → better brute → optimal for the subarray problem. Interviewers like seeing that you can optimize deliberately, not luck into the answer.

4. Follow-ups are where levels separate

Counting subarrays is a classic. Materializing them is the real stress test — indices, memory, how you present the output. Practice the "now return the actual things" variant for every counting problem you do.

5. System design: match storage to access pattern

Cassandra for high write throughput was fine. The miss was not reaching for a search engine when the core product requirement was flexible, user-defined filters on logs. When requirements scream "arbitrary query / filter on semi-structured events," think OpenSearch, Elasticsearch, ClickHouse, or similar — not only wide-column or OLTP.

6. Thinking process still passes

I didn't nail the custom-filter design perfectly. I still advanced because I reasoned aloud, proposed alternatives, and owned tradeoffs. Perfect answers help; visible engineering judgment helps more under time pressure.

7. Cultural fit is not filler

Know why this company, why now, and why you're leaving without bad-mouthing anyone. Fifteen minutes can still decide the hire.

Quick prep checklist for Blinkit-style SDE-2 Backend

4–5 resume stories in STAR with metrics
Medium DSA: prefix sums, hashing, arrays, strings, graphs basics
Practice follow-ups: count → reconstruct / print
System design: high-throughput ingestion, queues, storage vs query layer split
Know when to pick Cassandra / DynamoDB vs Postgres vs OpenSearch / ES vs object storage
Clear narrative for "why this company" and "why leave"
Compensation band research before the manager round

Final thoughts

This loop was short, intense, and fair. Round 1 tested fundamentals and communication. Round 2 tested system design judgment under incomplete answers. Round 3 tested motivation and fit.

I didn't code every follow-up perfectly. I didn't name OpenSearch on the first try. I still got the offer — because I clarified, structured, iterated, and stayed honest about gaps.

If you're preparing for SDE-2 Backend roles: practice out loud, design for the query path as carefully as the write path, and treat every follow-up as part of the main problem.

Good luck — and if this helped, share it with someone who's mid-prep right now.