Licious interview experiences from SDE-1 and backend loops

The Licious interview process for SDE freshers runs an online assessment (2-3 coding problems, and on some drives a long paper with gamified logic puzzles and MCQs), a DSA round with project discussion, a second technical round on LLD or system design built around orders and logistics, and then managerial and HR rounds. The reports below stress writing medium DSA solutions in Java that compile, designing real classes and interfaces in LLD and machine coding rounds, and explaining your own project work to the hiring manager.

Licious placement process includes: 1. Online Assessment (60-90 minutes, sometimes much longer with gamified sections) - coding plus MCQs, 2. Technical Interview Round 1 (45 minutes) - DSA-focused, 3. Technical Interview Round 2 (45 minutes) - LLD / system design and project detailed discussion, 4. Managerial Round (30-45 minutes) - Behavioral discussion, 5. HR Round (30 minutes) - Compensation discussion and background verification. Total duration: 2-3 weeks from application to offer.

Round-wise process

Real interview experiences

Licious hires mostly off-campus and lateral rather than through mass campus drives, so the public write-ups are individual accounts from LeetCode, Medium and Glassdoor rather than college placement posts. Two things recur strongly across them: Java is often mandated in the coding rounds and your code has to actually compile, and there is a low-level design round that catches candidates who only prepped DSA.

Experience 1: SDE-1 Java developer, Bangalore, 2023 (rejected)

Source: LeetCode Discuss, June 2023

Candidate profile: backend developer with a little over 1 year of experience, 2022 batch from a tier-1 college. Three interview rounds.

• Technical screen 1: 2 medium DSA questions. Code had to be written in Java and had to compile.
• Technical screen 2: 2 low-level design problems (1 easy, 1 medium) plus CS fundamentals, again in Java with compiling code.
• Hiring manager round: 2 LLD problems and 1 HLD problem. The first LLD needed production-ready Java code; for the second LLD and the HLD only the approach was discussed.
• Outcome: rejected.

Takeaways

• What stands out: design shows up in two of the three rounds, and even a 1-year SDE-1 candidate got an HLD question
• How to practice: timed Java mediums in an editor that compiles; one easy and one medium LLD written as real classes; one HLD outline you can talk through

Experience 2: SDE-1, 2024 (selected)

Source: Medium, Sept 2024

Candidate profile: experienced hire coming from BharatPe, shortlisted on resume.

• Online assessment (July 2024, 2.5 to 3 hours): a “gaming” section with reasoning, logic puzzles, quant and memorization tasks, then coding problems and technical MCQs.
• Technical discussion (1 hour): 2 medium coding questions, one on recursion and one on linked lists. The candidate walked through brute-force, better and optimal versions.
• Hiring manager + HR (1 hour, together): concurrency, locks and transaction handling from the BharatPe work; an easy recursion problem, optimized with DP and then down to a few variables, followed by unit tests for the edge cases. HR asked why Licious, preferred work environment, other offers, flexibility on location and package, and notice period.
• Outcome: background verification email the same day, offer letter three days later after salary negotiation.

Takeaways

• What stands out: the OA is long and only partly coding, so budget time for the puzzle sections
• How to practice: one long mixed mock; explain each coding answer from brute force up; be ready to write unit tests on the spot

Experience 3: SDE-2, 2025

Source: LeetCode Discuss, June 2025

Candidate profile: contacted the recruiter directly on LinkedIn; the recruiter asked for current compensation before scheduling the test.

• Online test (about 1 hour): 15 Java and Spring MCQs in 10 minutes with no going back; 2 easy coding questions in 20 minutes, Java only; then several sections of phone-style puzzle games, some timed at 2 minutes.
• Machine coding (1 hour): implement two APIs for an inventory management system from a problem in a Google Doc, handling edge cases. The panel wanted clean, modular code with design patterns and OOP, run in your own IDE.
• System design (HLD): a coupon management system. After a component overview, most of the time went on the DB schema: coupons limited to categories, products or product sets, a minimum cart value, or specific users, and how the coupon tables handle one-to-one and one-to-many relationships.
• Outcome: not stated in the post.

Experience 4: Technical round, Oct 2024 (DSA + Avro/MQTT + SQL)

Source: Medium, Nov 2024

• Route: HR called about an open position; the first technical (DSA) round was scheduled about a week later.
• Opening (45-minute round): current projects, then Apache Avro (serialization and schema evolution), inter-service communication, and why MQTT suits certain use cases.
• DSA: two questions were planned and a third was added because time was left; two medium, one easy. The candidate solved all three.
• OOP: principles and how they are applied.
• MySQL: an easy query at the end. The candidate explained the approach but was unsure of the syntax after more than two years away from hands-on SQL.
• Takeaway: brush up SQL syntax, not only concepts, before panels that mix domain protocols with DSA.

How the bar moves with level

• SDE-1: DSA at medium level, LLD, CS fundamentals, project depth.
• SDE-2: Java/Spring knowledge is assumed and tested directly; expect design and ownership questions rather than “explain a sorting algorithm”.
• SDE-3: reported rounds move to high-level design - one account describes being asked to design a message broker along the lines of Kafka.

What the pattern suggests

• Practice in Java, in an editor that compiles, if Java is your declared language. Multiple accounts specify this explicitly, and pseudocode does not pass.
• Prepare LLD as seriously as DSA. It is a full round at SDE-1, not a bonus question.
• Know your own architecture cold. The hiring manager round is largely your projects, examined properly.
• Domain knowledge about cold-chain logistics or delivery SLAs is not what published accounts report being tested on - useful context for the culture-fit conversation, but do not prep it in place of design and fundamentals.

Sources: Medium - Licious SDE-1 interview experience (selected) · LeetCode - Licious SDE1 Bangalore · LeetCode - Licious SDE2 hiring 2025 · Medium - Licious SDE-3, Feb 2024 · Medium - Licious DSA/Avro interview, Oct 2024 · Glassdoor - Licious interviews

Questions that come up often

Coding / technical

1. Top-K frequent elements. Usually expects heap / bucket sort
2. Shortest path in a grid. Usually expects BFS
3. Merge overlapping delivery slots. Usually expects interval merge
4. Discussion on cold chain inventory and order SLA, bottlenecks, failure modes, simple APIs
5. Detailed project discussion, architecture, hardest bug, what you would change
6. SDE-2: order/slot design, idempotent payments, inventory reservation, incident ownership
7. SDE-2: rate limiting / sliding window style coding with production complexity talk

HR / behavioral

1. Why this product?
2. Working with unclear requirements
3. On-call or weekend comfort
4. Relocation
5. (SDE-2) Notice period, current vs expected CTC, on-call ownership

Practical tips for Licious

• Clear the screening round first. Timed practice beats last-minute topic hopping.
• For domain questions, explain cold chain inventory in plain language, inputs, outputs, what breaks at scale.
• OOPs and SQL still open a lot of Licious panels. Do not skip fundamentals.
• HR answers should be concrete. One story with a result beats five slogans.
• SDE-2 candidates: prioritize one end-to-end design (orders + inventory + SLA) and two production incident stories - do not only grind Easy/Medium lists.

HR interview

After technical rounds, Licious usually closes with a short HR / hiring-manager conversation: motivation, location, notice period, and a couple of behavioral stories.

Sample answers for high-frequency questions

Q. How does HashMap work internally in Java?
A. A HashMap holds an array of buckets. put computes the key’s hashCode, applies a spreading function that XORs the high bits into the low bits, and masks the result with capacity - 1 to pick a bucket index - which is why capacity is always a power of two. Collisions chain in a linked list, and since Java 8 a bucket converts to a red-black tree once it holds eight entries in a table of at least 64, cutting worst-case lookup from O(n) to O(log n). When size exceeds capacity times the 0.75 load factor, the table doubles and entries are rehashed. Keys must implement hashCode and equals consistently and should be immutable, since mutating a key after insertion makes its entry unreachable. HashMap is not thread-safe - use ConcurrentHashMap.

Q. What is Inversion of Control and dependency injection in Spring Boot?
A. Inversion of Control means the framework, not your code, creates and wires objects: the ApplicationContext scans for stereotype annotations such as @Component, @Service, @Repository, and @Controller, instantiates those beans, and injects their dependencies. Constructor injection is preferred over field injection because it makes dependencies explicit, permits final fields, and works without reflection in tests. The default bean scope is singleton - one instance per application context - with prototype, request, and session also available. @Configuration classes with @Bean methods cover third-party types you cannot annotate, and @ConditionalOnMissingBean is how Boot’s auto-configuration backs off once you define your own bean.

Q. How would you design a coupon management system?
A. Model Coupon (code, type, value, min_order_value, valid_from, valid_to, per_user_limit, global_limit, status) separately from CouponRedemption (coupon_id, user_id, order_id, redeemed_at), so the rule definition stays decoupled from usage history. Validation runs as an ordered chain of rules - active window, applicable products, minimum cart value, user eligibility, remaining global and per-user limits - a natural fit for Strategy or Chain of Responsibility so new coupon types need no edits to existing code. The hard part is preventing over-redemption under concurrency: put a unique constraint on (coupon_id, user_id, order_id) and decrement the global counter atomically with a conditional UPDATE or a Redis DECR, never a read-then-write. Cache active coupon definitions, since reads vastly outnumber writes, and keep redemptions immutable for reconciliation.

Q. How do you reserve inventory for perishable stock without overselling?
A. Never decrement only at checkout - reserve at cart-confirm time by inserting a reservation row with a TTL, and treat available stock as on-hand minus active reservations. The decrement must be atomic and conditional: an UPDATE setting quantity = quantity - n guarded by a WHERE clause requiring quantity to be at least n, checking the affected row count rather than reading first, so two concurrent orders cannot both succeed. Perishables additionally need batch-level tracking with expiry dates and FEFO allocation - first-expiring-first-out - so the batch nearest expiry ships first and write-off is minimized. Expire abandoned reservations with a sweeper job that returns stock, and key the whole flow on an idempotent order id so client retries cannot double-reserve.

Q. Which design pattern would you choose in a machine coding round, and why?
A. Pick the pattern by what varies. Strategy when one algorithm must be swappable - flat, percentage, and buy-one-get-one discount rules behind a common interface - so a new rule is a new class instead of another branch in an if-chain. Factory when object creation depends on a runtime type, keeping construction out of business logic. Observer when one state change must notify several independent listeners, such as an order-status change triggering notification, invoicing, and analytics. Builder when an object carries many optional fields. The failure mode graders penalize is applying a pattern with no variation to absorb, so name the axis of change you are designing for and keep everything else plain.

Tips from successful candidates

Sources

Round-wise notes on this page are curated from public candidate reports (Medium, LeetCode Discuss, Glassdoor), then reorganized with prep takeaways and outcome context. Cross-check level (SDE-1 vs SDE-2) and whether OA is required for your route. Citation inputs appear inline in the experience blocks above. For OA practice, see Licious placement papers.

Similar companies

Blinkit · Meesho · Google · Amazon · Microsoft · TCS