Interview experience
Nykaa interview experiences covering DSA/Coding Round, Low-Level Design (LLD) Round, Manager/HR Round. Round-wise notes, common questions, and what candidates report clears each stage.
Explore: Interview experience · HR interview questions · Overview · Placement papers · Preparation guide
Nykaa’s engineering interviews run a distinct 3-stage loop where a dedicated Low-Level Design round - not just DSA - is a seriously evaluated stage on its own.
Interview experience
Nykaa interview experiences covering DSA/Coding Round, Low-Level Design (LLD) Round, Manager/HR Round. Round-wise notes, common questions, and what candidates report clears each stage.
HR interview questions
Nykaa HR interview questions with sample answer frameworks - motivation, relocation, STAR stories, and culture-fit prompts.
| Round | Duration | What they test |
|---|---|---|
| Online Assessment (many drives) | 60-90 min | 2-3 timed medium DSA problems; sometimes SQL or aptitude |
| DSA/Coding Round | 45-60 min | 2 medium DSA problems, spoken complexity |
| Low-Level Design (LLD) Round | 45-60 min | DB schema design, OOP class design, design patterns |
| Manager/HR Round | 30-45 min | Project depth, work experience, culture fit, sometimes HLD |
These answers are compiled from public candidate reports and prep guides, not from an official Nykaa notice, and drives differ. Public Nykaa reports are thinner than for larger product companies, so the instruction screen of your own test is the final word.
| Question | Answer |
|---|---|
| How many questions and how long? | Short. A 2021 SDE-1 campus report describes 2 coding problems in 60 minutes; a 2020 campus report describes a 90-minute assignment with a 3Sum-style problem. |
| Does it have negative marking? | No public report mentions any. It is a coding test scored on working solutions. |
| Is there a sectional cutoff? | Not reported. Most reports describe coding problems only, with no separate sections. |
| How much is the cutoff? | Not published. Campus eligibility in reports is 7.0 CGPA with at most a one-year gap (2021) or 7.5 CGPA for CS, IT and ECE (older on-campus drives). |
| Which platform is it on? | Not reliably named in public reports; expect a HackerRank-style proctored test and go by your invite mail. |
| Is there an OA for experienced hires? | Often not. Recruiter-led SDE-2 loops in 2022-2024 reports go straight to a DSA interview, then LLD and HLD. |
| What follows the OA for freshers? | DSA interviews plus OS and DBMS questions: memory types, garbage collection, job schedulers, indexes, joins, foreign keys and atomic updates in a 2020 report. |
These topics come from Code360 and Glassdoor interview reports and Nykaa prep guides. They show the level and style, not a fixed list.
| Role | Reported questions and topics |
|---|---|
| SDE-1 (campus) | A 2-problem coding test; DSA such as 3Sum; OS and DBMS fundamentals; LLD basics; behavioural questions on handling a dispute with a colleague and extra workload. |
| SDE-2 backend | Two DSA problems on arrays, stacks and linked lists with best-case complexity expected (September 2024 Bengaluru report); Rotting Oranges; Java 8 and multithreading; a basic LLD problem; HLD such as a targeted-campaigns engine. |
| Frontend | Same DSA bar, with the LLD round swapped for component architecture and real-time UI state. |
| Data / business analyst | Few public reports. One listed task is finding the top five brands by sales from a dataset, so practise GROUP BY with ranking, plus duplicate and null checks. |
Asked across every role: why Nykaa, a project walk-through with your specific contribution, and a design trade-off you made under time pressure.
A 45-60 minute round with typically 2 medium-difficulty problems at LeetCode-medium level. Campus and off-campus drives often start with a HackerRank-style OA testing the same families under a stricter clock; treat the OA as round zero, not a formality.
Interviewers expect runnable code, stated time and space complexity, and edge cases spoken aloud. Partial credit is common when your second problem is clean even if the first stalls - but two incomplete solutions rarely clear competitive SDE-2 loops.
Common questions
The most distinctive stage - a genuine class-design and schema exercise, not just algorithmic coding. You’re expected to define clean OOP structure, REST-ish APIs, and apply the right design patterns for a functional system. Backend JDs sometimes add Java/Spring Boot depth; frontend loops swap in component architecture and real-time UI state instead of SQL schema.
Panels watch for inventory races (two users buying the last unit), idempotent payments, and whether you snapshot prices on order_items instead of joining live catalog prices. Naming patterns without class diagrams is a common rejection reason.
Common questions
Often blends a High-Level Design discussion (scoped closer to Nykaa’s own domain, like a targeted-campaigns engine) with project depth and culture-fit questions - there’s frequently no separate HR-only round.
Common questions
Round-by-round narratives are on the Nykaa interview experience page.
Sample answer frameworks are on the Nykaa HR interview questions page.
Campus SDE-1 hiring starts with a short coding test (about 60-90 minutes), then DSA interviews that also test OS, DBMS and OOP fundamentals, and a lighter LLD discussion. Eligibility filters such as 7.0-7.5 CGPA apply.
Experienced SDE-2 hiring usually skips the OA. Recruiter-led loops run a DSA round (two medium problems), a dedicated LLD round with schema and design patterns, and a manager round that often includes HLD. Most of the round detail on this page comes from SDE-2 reports, so freshers should treat the LLD and HLD material as stretch preparation and put DSA and CS fundamentals first.
Use two pointers, one at each end of the height array. The area is min(height[left], height[right]) multiplied by the distance between them, so record it and then move whichever pointer sits at the shorter line inward. Moving the taller line can never increase the area because the width always shrinks and the height stays capped by the shorter side, so it is safe to discard it. This runs in O(n) time and O(1) space, versus O(n^2) for checking every pair.
Iterate the words once and compute a canonical key for each: either the sorted characters of the word, or a 26-length count array of letter frequencies rendered as a string. Insert each word into a hash map keyed by that canonical form, then return the map’s values as the grouped lists. Sorting keys costs O(n * k log k) for n words of length k; the counting key drops that to O(n * k). Space is O(n * k) for the map.
A Factory (or Abstract Factory) creates the different MenuItem types so the ordering code never hardcodes concrete classes. The State pattern models the order lifecycle - PLACED, PREPARING, READY, DELIVERED, CANCELLED - so each state object controls which transitions are legal instead of a sprawling switch statement. Strategy handles interchangeable pricing or discount rules, and Observer notifies the kitchen display, inventory service, and customer notification service when an order changes state. Naming the pattern is not enough - Nykaa’s LLD round expects you to justify why that pattern beats the simpler alternative.
At minimum: users(user_id PK), products(product_id PK, name, brand_id), product_variants(variant_id PK, product_id FK, sku, mrp, selling_price), inventory(variant_id FK, warehouse_id FK, available_qty), carts(cart_id PK, user_id FK, status), cart_items(cart_id FK, variant_id FK, qty), orders(order_id PK, user_id FK, status, total_amount, created_at), and order_items(order_id FK, variant_id FK, qty, unit_price_at_purchase). The key design point is that order_items snapshots the price at purchase time - you must never join back to the live price table, because prices change and old invoices must stay correct. Index orders on (user_id, created_at) for order history and cart_items on cart_id.
Inheritance models an is-a relationship and binds the subclass to the parent’s implementation at compile time, so a change in the base class ripples into every subclass. Composition models a has-a relationship: the class holds a reference to a collaborator behind an interface, and behaviour can be swapped at runtime. Prefer composition for varying behaviour - a PricingStrategy field injected into Order beats a DiscountedOrder subclass, because you would otherwise need a new subclass for every combination of behaviours. Inheritance is still right for genuine type hierarchies with a stable contract.
Kadane’s algorithm scans once, keeping current_sum = max(num, current_sum + num) and best = max(best, current_sum). It runs in O(n) time and O(1) space. If every element is negative, initialising best to zero wrongly returns 0, so initialise best to the first element (or to negative infinity) and let the max operation pick the least-negative single element. To also return the indices, record the start position whenever current_sum resets to num.
Split it into offline and online paths. Offline, a batch job over clickstream, order history, and catalog data computes candidate sets - collaborative filtering on user-item interactions plus content-based similarity on brand, category, and skin-type attributes - and writes precomputed recommendations into a fast key-value store such as Redis, keyed by user_id. Online, the API reads that store in a few milliseconds, filters out out-of-stock or already-purchased items, and applies business rules like margin or campaign boosts before ranking. Use Kafka to stream fresh events into the feature store so the offline model retrains regularly, and always keep a fallback of trending or bestselling items for cold-start users with no history.
Use Floyd’s tortoise-and-hare: advance a slow pointer one node and a fast pointer two nodes per step; if they ever meet, a cycle exists. To find the cycle’s entry point, reset one pointer to the head and advance both one step at a time - they meet at the start of the loop. This is O(n) time and O(1) space, better than a hash set of visited nodes which costs O(n) space. The same idea detects cycles in any next-pointer structure, such as a chain of order-state transitions that must be acyclic.
Push the head of each list into a min-heap keyed by node value. Pop the smallest, append it to the result, and push that node’s next pointer if it exists. Repeat until the heap is empty. With k lists and n total nodes, time is O(n log k) and space is O(k) for the heap. Divide-and-conquer merging pairs of lists is also O(n log k) and avoids a heap if you prefer recursion. Nykaa OAs and DSA rounds report this family alongside array problems.
Separate read and write paths: serve product and inventory reads from cache and CDN; queue checkout writes behind a token or reservation system so you never oversell the last units. Pre-warm cache keys for sale SKUs, scale stateless API tiers horizontally, and rate-limit add-to-cart per user. Use a short-lived inventory hold at cart time, not only at payment, and monitor queue depth and p95 checkout latency as primary alerts.
Normalize queries (lowercase, trim), maintain an inverted index on tokenized product titles and brands, and fetch candidates with BM25 or similar scoring. For typos, generate edits within one or two Levenshtein distance on high-traffic queries, or use n-gram tokens so partial matches still hit. Blend text relevance with business boosts (in-stock, margin, campaign) in a reranker. Log zero-result queries to expand synonyms - critical for beauty terms users misspell.
Tables: warehouses, product_variants, inventory(variant_id, warehouse_id, available_qty) with a unique pair index. On order placement, allocate from the nearest warehouse with stock using a deterministic rule (pincode → warehouse priority list). Decrement with a conditional UPDATE … WHERE available_qty >= qty so two concurrent orders cannot sell the same unit. Expose ATP (available-to-promise) per pincode by summing eligible warehouses minus holds in open carts.
Join order_items to orders (filter created_at in current month and status not cancelled), join to product_variants and products for category_id, aggregate SUM(qty) or revenue per product_id within category, then rank with DENSE_RANK() OVER (PARTITION BY category_id ORDER BY sales DESC) and filter rank <= 5. Nykaa analytics screens in interviews often probe window functions and join hygiene, not only DSA.
When the same product and listing pages are read far more often than they change - typical for bestsellers and campaign landing pages. Cache key by variant_id or listing_id with a TTL short enough to tolerate brief staleness on price drops, or invalidate on publish events. Size the cache to hot keys only; long-tail SKUs can stay on database reads. Pair with CDN for images; application LRU helps API JSON and aggregation endpoints.
No public report mentions negative marking. Nykaa’s campus online round is a short coding test - 2 problems in 60 minutes in a 2021 report, a 90-minute assignment in a 2020 report - scored on working code, not on MCQs.
Nykaa does not publish one; campus reports cite 7.0 to 7.5 CGPA. A 2021 SDE-1 campus report lists 7 CGPA with at most a one-year gap, and older on-campus SDE reports list 7.5 CGPA for CS, IT and ECE branches. Your placement notice is the rule for your drive.
Nykaa typically runs 3 rounds for engineering hires: 1. DSA/Coding Round (45-60 minutes) - usually 2 medium-difficulty problems, occasionally harder for senior or competitive drives. 2. Low-Level Design (LLD) Round - a DB design plus object-oriented design exercise where you define classes, interfaces, database schemas, and apply relevant design patterns for a system (often something close to Nykaa’s own catalog, cart, or order-management domain). 3. Manager/HR Round - a detailed discussion of past projects and work experience, plus culture fit. The full process usually takes 2-4 weeks.
Coding rounds lean on arrays, sliding windows, stacks, trees, and dynamic programming at LeetCode-medium difficulty - candidate reports mention problems like Container With Most Water and Group Anagrams. The LLD round asks you to design a functional e-commerce-style system (candidates have reported a McDonald’s-outlet-style ordering system) with clean class design and appropriate design patterns. A separate HLD round covers something closer to Nykaa’s own domain (e.g. a targeted-campaigns/recommendation engine), often blended with a managerial conversation.
Most Nykaa engineering interviews run 3 rounds: a DSA/coding round, a low-level design round, and a manager/HR round (sometimes blended with a high-level design discussion). There’s no separate large HR-only round in many cases - cultural fit is assessed as part of the manager conversation.
The Low-Level Design round is a distinct, seriously-evaluated stage - you define classes, interfaces, and database schemas for a functional system and justify your design-pattern choices. A reported example asked candidates to design a McDonald’s-style outlet ordering system (menu items, order state, inventory), testing clean OOP structure rather than raw algorithmic speed.
Practice medium-level DSA (arrays, sliding window, stacks, trees, DP) and get comfortable designing a small object-oriented system end-to-end, including database schema and design patterns, since Nykaa’s LLD round is a distinct evaluated stage separate from DSA. Be ready to discuss your projects in detail and connect your interest to Nykaa’s e-commerce/beauty business and its scale challenges.
Not exactly - public write-ups for Nykaa skew toward experienced SDE hiring (SDE-2 and above), where the DSA-LLD-HLD structure is well documented. Fresher/campus loops likely lean lighter on the HLD stage and heavier on DSA fundamentals and the LLD round, but treat the process as a prep map rather than an exact script for your specific drive.
Public SDE write-ups converge on a DSA → dedicated LLD → manager/HLD shape. Interviewers score:
Soft fail modes: Easy-only grinding, designing with “Kafka” before you can write a CartItem class, or treating beauty-brand interest as a substitute for design depth.
Good fit: You enjoy product ecommerce, you can talk about SKUs with variants (shade, size), and you can write medium DSA without panic. Fashion/beauty interest is a plus in HR, not a substitute for LLD.
Harder path: You only did Easy LeetCode. Or you answer design with “we will use Kafka and microservices” and cannot write a Cart class. Nykaa panels have asked retail-outlet LLD and campaign HLD even for SDE-2; freshers should still practise the smaller version.
Use this as a default four-week loop before a Nykaa drive. Adjust to your invite timeline.
10-day crash version: Days 1-4 timed DSA, days 5-7 resume projects + CS fundamentals, days 8-9 mock interviews out loud, day 10 HR STAR stories on the HR page.
Candidate-reported fresher/early-career packages for Nykaa often cite SDE-1 often ₹10-18 LPA. Treat forum numbers as ranges, not guarantees - confirm the written offer letter for your team and location.
Interview process details and sample questions on this site are editorially organized from public candidate reports and hiring write-ups, with round structure, prep notes, and company-specific framing added by our team. For round-by-round stories, see the Nykaa interview experience page. For OA papers and coding drills, use Nykaa on placementpapers.app. OA quick answers and role-wise questions draw on Code360 Nykaa interview experiences (2020-2023), Glassdoor reviews for Nykaa SDE-2 backend interviews, a LeetCode Discuss Nykaa campus compensation post and Hyring’s Nykaa interview page.
Guides often searched alongside this page: flipkart interview questions · meesho interview questions · amazon interview questions · bigbasket interview questions · swiggy interview questions · blinkit interview questions.