How Blinkit fresher interviews usually run, campus and off-campus. We synthesized Zomato x Blinkit campus reports into round tables and prep takeaways - modified DSA and orders/logistics design decide more outcomes than trivia. Patterns shift by year and role, so treat this as a prep map, not a script.
Blinkit placement process includes: 1. Online Assessment (OA) (90 minutes) - 2-3 medium coding problems, 2. Technical Interview Round 1 (45 minutes) - Data structures and algorithms, 3. Technical Interview Round 2 (45 minutes) - System design and detailed technical discussion, 4. Managerial Round (45 minutes) - Behavioral and technical discussion, 5. HR Round (30 minutes) - Final discussion. Total duration: 2-3 weeks from application to offer.
Eligibility (from student reports): 7.0+ CGPA in 10th, 12th, and graduation.
Fresher package ballpark (from student reports): SDE: ₹18-25 LPA. Confirm on your offer letter.
Round-wise process
Round
Duration
What they test
Online Assessment
90 min
2-3 coding problems
Technical Round 1
45-60 min
DSA + project discussion
Technical Round 2
45-60 min
System design (orders / logistics)
Managerial (some drives)
~45 min
Mixed behavioural + technical
HR / culture fit
20-30 min
Motivation, relocation, weaknesses
Real interview experiences
Documented on-campus drive: Zomato x Blinkit, SDE-I (2024)
Blinkit hires on campus jointly with Zomato, and this write-up is the most useful fresher-facing account available because the candidate recorded the funnel at every stage.
Online assessment (90 minutes, HackerRank)
20 MCQs on core CS subjects - OS, computer networks, DSA, OOPs, DBMS - plus 3 coding problems.
18 candidates advanced out of 220.
Round 1 - technical interview
Project discussion, then a wide sweep: machine learning concepts (RAG pipelines, neural networks, Word2Vec), DevOps (Docker, Kubernetes, Redis), system design (load balancing, consistent hashing), and networking (DNS, TCP vs UDP).
One DSA problem: Maximal Square.
The candidate credited using diagrams and sketches to explain answers.
8 candidates advanced.
Round 2 - advanced technical interview
Implementing backend logic in Golang using its concurrency features.
A system design task: design a rate limiter, with the interviewer pushing on practical implementation and edge cases.
3 candidates advanced.
Round 3 - HR
Motivation for joining, and weaknesses. All three finalists received offers.
Worth noting: this candidate’s profile was projects-heavy (60+ GitHub repositories, a personal DSA log), and Round 1 ranged far outside DSA - ML, DevOps, and networking all came up because they were on the resume.
Documented experienced/referral track: SDE-1 Backend - rejected at system design
A candidate with about six months of internship experience interviewed via employee referral. Three rounds, each eliminatory:
Technical Round 1 (60 minutes) - cleared
Five modified algorithmic problems. The first was house robber with circular and weighted constraints across three follow-ups; the second was a narrative-framed question that required topological sorting plus graph colouring.
Also asked why they would pick a given database, and about monitoring tooling (Grafana).
Technical Round 2 (system design) - the elimination
Asked to design a tracking system for a single user. The interviewer was looking for a file-system-based solution, not a database; the candidate lost significant time working through SQL, NoSQL, and in-memory options.
Also: debugging Python code, a prefix-string counting problem using tries (where the interviewer indicated a better solution existed), and questions on indexing and sharding, which the candidate estimated they answered 60-70% correctly.
Outcome: rejected, with the gap identified as trade-off reasoning in system design rather than raw problem-solving. Their own stated lessons were to think beyond the tools you already reach for, to understand what the problem actually requires before choosing a solution, and to keep communication clear throughout.
Takeaway: Blinkit’s coding rounds lean on modified standard problems - expect house-robber and grid-DP style questions with constraints bolted on rather than clean LeetCode restatements. Core CS subjects (OS and networking especially) are tested in the OA and again in interviews. And the round that most often ends candidacies is system design, where naming a familiar database is worse than reasoning out loud about what the requirements actually demand.
Top-K frequent elements. Usually expects heap / bucket sort
Shortest path in a grid. Usually expects BFS
Merge overlapping delivery slots. Usually expects interval merge
Discussion on inventory sync and 10-minute delivery SLA, bottlenecks, failure modes, simple APIs
Detailed project discussion, architecture, hardest bug, what you would change
HR / behavioural
Why this product?
Working with unclear requirements
On-call or weekend comfort
Relocation
Practical tips for Blinkit
Clear the screening round first. Timed practice beats last-minute topic hopping.
For domain questions, explain inventory sync in plain language, inputs, outputs, what breaks at scale.
OOPs and SQL still open a lot of Blinkit panels. Do not skip fundamentals.
HR answers should be concrete. One story with a result beats five slogans.
If you do not know something, say so and outline how you would find out.
HR interview
After technical rounds, Blinkit usually closes with a short HR / hiring-manager conversation: motivation, location, notice period, and a couple of behavioural stories. Prepare those answers on the dedicated page rather than cramming them into this hub.
Sample answers for high-frequency questions
Use these as frames, not scripts - interviewers probe follow-ups.
Q. How do you find the top K frequent elements in an array? A. Count occurrences in a hash map first, then pick the K largest counts. With a min-heap of size K you push each (element, count) pair and pop whenever the heap exceeds K, giving O(n log K) time and O(n) space, which is the answer most interviewers expect. Bucket sort does better: create an array of lists indexed by frequency from 1 to n, drop each element into the bucket matching its count, and walk the buckets from the highest index down until you have collected K elements, which is O(n) time. Mention the heap first, then offer the bucket variant as the optimisation.
Q. How do you find the shortest path in a grid with obstacles? A. Use breadth-first search, not DFS, because BFS explores in order of increasing distance so the first time it reaches the target that distance is minimal. Push the start cell into a queue with distance 0, and on each pop expand the four neighbouring cells that are inside the grid, not blocked, and not yet visited, marking them visited at enqueue time so a cell is never queued twice. Complexity is O(rows times columns) in both time and space. If cells have different traversal costs, BFS no longer suffices and you switch to Dijkstra with a priority queue, or 0-1 BFS with a deque when costs are only 0 or 1.
Q. How would you design inventory sync across multiple dark stores? A. Make each dark store the authoritative owner of its own stock counts, and treat the customer-facing catalogue as a cached, eventually consistent view fed by an event stream of stock deltas. Every pick, receipt and cycle count publishes an event keyed by store and SKU so ordering per key is preserved, and consumers apply deltas rather than absolute values to avoid a stale snapshot overwriting a newer one. Reserve stock at checkout with a short-lived hold rather than decrementing at payment, so two customers cannot both buy the last unit, and release holds on timeout. Reconcile periodically against physical counts because shrinkage and mis-picks guarantee drift.
Q. How would you route an order to the nearest available dark store? A. Nearest by straight-line distance is only the first filter. Index stores by geohash or an S2 cell so a lookup narrows candidates to a small set in milliseconds, then rank those candidates on a composite score: does the store actually hold every SKU in the cart, what is its current picking queue depth, how many riders are free, and what is the road-network travel time rather than the crow-flies distance. Prefer a single store that can fulfil the whole basket over splitting an order across two, since a split doubles the delivery cost and risks breaching the SLA. Fall back to the next-best store when the chosen one rejects the assignment.
Q. What failure modes would you plan for in a 10-minute delivery SLA system? A. The common ones are stock that reads available but is physically missing, a dark store going offline mid-order, rider supply collapsing during a demand spike or rain, and a payment confirmation that times out after the order was actually created. Handle them with explicit degradation rather than errors: mark a store temporarily unavailable and re-route, hold rather than decrement inventory, make order creation idempotent on a client-supplied key so a retried payment does not double-order, and surface a realistic revised ETA instead of silently missing the promise. Track SLA breaches at the 95th and 99th percentile, because the average hides exactly the tail the customer notices.
Tips from successful candidates
Assessment tips
Confirm the current Blinkit pattern from the drive mail before practising old papers
Finish one problem or section fully before starting the next
Revise the fundamentals listed in the round table on this page
Interview tips
Narrate trade-offs; expect “why” after every answer
Only list projects you can defend under follow-ups
Prepare 3-4 STAR stories for behavioural prompts
HR tips
Know why Blinkit, not just why the industry
Be clear on location / notice period / higher studies
These links are research inputs we used to map round structure and recurring questions - not copied page mirrors. We reorganized reports into process tables, outcome notes, and prep takeaways for Blinkit.
Round-wise notes on this page are curated from public candidate reports, then reorganized with prep takeaways and outcome context. Cross-check the current drive mail for timings. For OA practice, see Blinkit placement papers.
