Nykaa · Software Engineer
Updated · 2026-10-02

Nykaa Software Engineer
Interview Guide

THE 60-SECOND BRIEF

A Software Engineer at Nykaa plays a pivotal role in shaping the technology that powers India's leading beauty, wellness, and fashion e-commerce platform. Operating at an incredible scale, the engineering team is responsible for building and maintaining high-concurrency systems that serve millions of active users daily. From optimizing search and recommendation engines to ensuring seamless, secure checkout pipelines during massive flash sales, your work directly influences the digital shopping experience of millions of consumers. At Nykaa, engineers do not work in isolation. You will be part of a highly collaborative environment where you will design microservices, optimize database schemas, and build resilient architectures. The engineering challenges here are diverse and complex, ranging from low-latency inventory management to sophisticated personalization algorithms.

This guide is scoped to a Software Engineer candidate at Nykaa.

Nykaa candidates report 4 rounds over 3-5 weeks. The stages below are what candidates describe, not a published process.

Data StructuresAlgorithms (DSA)Low-Level Design (LLD)

21 min read

Browse Software Engineer questions

See the practice prompts

18Practice promptsAcross five skill areas

A Software Engineer at Nykaa plays a pivotal role in shaping the technology that powers India's leading beauty, wellness, and fashion e-commerce platform. Operating at an incredible scale, the engineering team is responsible for building and maintaining high-concurrency systems that serve millions of active users daily. From optimizing search and recommendation engines to ensuring seamless, secure checkout pipelines during massive flash sales, your work directly influences the digital shopping experience of millions of consumers. At Nykaa, engineers do not work in isolation. You will be part of a highly collaborative environment where you will design microservices, optimize database schemas, and build resilient architectures. The engineering challenges here are diverse and complex, ranging from low-latency inventory management to sophisticated personalization algorithms. The role demands a strong balance of theoretical computer science fundamentals and practical system design skills. As a Software Engineer, you are expected to take complete ownership of your modules, write clean and highly optimized code, and continuously seek ways to improve system reliability and scalability. It is an inspiring space for engineers who thrive on solving real-world retail-tech challenges at scale.

The Nykaa interview process

01

Online Assessment

reported

Initial screening featuring competitive programming questions on arrays, stacks, trees, and dynamic programming.

What to demonstrate

  • Initial screening featuring competitive programming questions on arrays, stacks, trees, and dynamic programming
  • Depth in Data Structures

How to prepare

  • Answer aloud and timed: Find the largest subarray with an equal number of 0s and 1s.
  • Answer aloud and timed: Merge K sorted linked lists efficiently.
Nykaa Software Engineer candidate reports ↗
02

Core Technical Rounds

reported

Structured sessions focusing on Data Structures & Algorithms and System Design (both LLD and HLD).

What to demonstrate

  • Structured sessions focusing on Data Structures & Algorithms and System Design (both LLD and HLD)
  • Depth in Data Structures

How to prepare

  • Answer aloud and timed: Solve optimization problems using dynamic programming (DP) and greedy approaches.
  • Answer aloud and timed: Implement graph traversal algorithms to find shortest paths or connected components.
Nykaa Software Engineer candidate reports ↗
03

Hiring Manager Round

reported

Assessment of technical depth and past project experiences by the hiring manager.

What to demonstrate

  • Assessment of technical depth and past project experiences by the hiring manager
  • Depth in Data Structures

How to prepare

  • Prepare two projects you led end to end, each with the decision you owned and what it cost.
  • Have three questions about the team's roadmap and how success is measured in the first six months.
Nykaa Software Engineer candidate reports ↗
04

HR Discussion

reported

Evaluation of cultural fit and behavioral alignment with HR.

What to demonstrate

  • Evaluation of cultural fit and behavioral alignment with HR
  • Depth in Data Structures

How to prepare

  • Answer aloud and timed: Design a parking lot system, detailing the class diagrams, design patterns used, and component trade-offs.
  • Answer aloud and timed: Design an autocorrect or search suggestion feature for an e-commerce catalog.
Nykaa Software Engineer candidate reports ↗

Where candidates lose points

PracHub editorial advice for the preparation topics above.

01

Communicate Your Approach First

In DSA rounds, never start coding immediately. Explain your brute-force approach, discuss its limitations, and then propose your optimized solution. Only start writing code once the interviewer agrees with your logic.

02

Prepare for Hybrid Design Questions

Do not compartmentalize LLD and HLD. A round designated as LLD can easily pivot into high-level discussions about caching, database scaling, and microservices communication. Be ready to transition smoothly between the two.

03

During recruitment drives, candidate volumes can be very high

If you do not receive immediate feedback after a round, proactively follow up with your HR coordinator to ensure your profile moves forward.

04

Know Your Resume Inside Out

Be prepared for intense questioning on your past projects. If you mention a specific technology, database, or architectural pattern on your resume, you must be able to justify why it was used and discuss its pros and cons.

Questions & practice

Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.

15 technical prompts0 include a worked solution

Find the largest subarray with an equal number of 0s and 1s.

medium
Data Structures & Algorithms (DSA)

Find the largest subarray with an equal number of 0s and 1s.

Approach
  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.
Follow-up
  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Merge K sorted linked lists efficiently.

medium
Data Structures & Algorithms (DSA)

Merge K sorted linked lists efficiently.

Approach
  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.
Follow-up
  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Solve optimization problems using dynamic programming (DP) and greedy approaches.

medium
Data Structures & Algorithms (DSA)

Solve optimization problems using dynamic programming (DP) and greedy approaches.

Approach
  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.
Follow-up
  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Implement graph traversal algorithms to find shortest paths or connected components.

medium
Data Structures & Algorithms (DSA)

Implement graph traversal algorithms to find shortest paths or connected components.

Approach
  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.
Follow-up
  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Solve array-based problems utilizing the sliding window or two-pointer techniques.

medium
Data Structures & Algorithms (DSA)

Solve array-based problems utilizing the sliding window or two-pointer techniques.

Approach
  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.
Follow-up
  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Explain advanced platform-specific concepts, such as memory management, computed properties, and design patter

medium
Technical Depth & Projects

Explain advanced platform-specific concepts, such as memory management, computed properties, and design patterns in iOS (for mobile-focused roles).

Approach
  1. Say what the runtime actually does before reasoning about the code.
  2. Name what is shared across threads and what owns each piece of state.
  3. Identify the window where an invariant is briefly untrue.
  4. Distinguish a value from a reference to it, and say which one you handed out.
Follow-up
  • What happens if two callers reach this at the same time?
  • Where could this allocate more than you expect?

Suggested practice checklist

Built from the rounds and topics Nykaa candidates report.

Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE

Prepare, practise & reflect

One practical outcome each day. Spend longer where you need it.

0 / 7 done
01Map the Nykaa loop
  • Write out the reported sequence: Online Assessment, Core Technical Rounds, Hiring Manager Round, HR Discussion.
  • For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 4 reported rounds, with the weakest marked.

02Work Data Structures
  • Spend the session on Data Structures, which Nykaa candidates report being tested on.
  • Write one worked example in Data Structures and time yourself on it.

Deliverable: One timed worked example in Data Structures.

03Work Algorithms (DSA)
  • Spend the session on Algorithms (DSA), which Nykaa candidates report being tested on.
  • Write one worked example in Algorithms (DSA) and time yourself on it.

Deliverable: One timed worked example in Algorithms (DSA).

04Work Low-Level Design (LLD)
  • Spend the session on Low-Level Design (LLD), which Nykaa candidates report being tested on.
  • Write one worked example in Low-Level Design (LLD) and time yourself on it.

Deliverable: One timed worked example in Low-Level Design (LLD).

05Answer out loud: Data Structures & Algorithms (DSA)
  • Answer aloud, timed: Find the largest subarray with an equal number of 0s and 1s.
  • Answer aloud, timed: Merge K sorted linked lists efficiently.

Deliverable: Spoken answers to 2 reported Data Structures & Algorithms (DSA) question(s), under time.

06Answer out loud: System Design (LLD & HLD)
  • Answer aloud, timed: Design a movie ticket booking system, focusing on database schema design, class structures, and concurrency control.
  • Answer aloud, timed: Design a parking lot system, detailing the class diagrams, design patterns used, and component trade-offs.

Deliverable: Spoken answers to 2 reported System Design (LLD & HLD) question(s), under time.

07Answer out loud: Technical Depth & Projects
  • Answer aloud, timed: Walk through the database schema of a previous project and justify your choice of SQL versus NoSQL.
  • Answer aloud, timed: Explain how you handle state management, API latencies, and rendering performance in a frontend application (for frontend-focused roles).

Deliverable: Spoken answers to 2 reported Technical Depth & Projects question(s), under time.

Expand any day for tasks and deliverables. Your progress is saved on this device.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

Estimate work you have never done and defend the range

hard
estimationbackfillsexpand-contract

You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.

Approach
  1. Decompose into independently deployable steps before estimating anything: add the column nullable, write both shapes, backfill in batches, verify, move reads, stop writing the old shape, drop it. That is four deploys spread over days, and the calendar estimate is dominated by them rather than by the loop's runtime.
  2. Do the arithmetic aloud for the part that has arithmetic in it: batch size times number of batches times per-batch duration, at a write rate the primary can absorb alongside roughly 1.2k writes per second of production traffic. The loop is throttled by replication lag and lock waits, not by how fast it can issue statements.
  3. Price the schema step by its lock rather than its statement duration. In PostgreSQL an ALTER TABLE taking ACCESS EXCLUSIVE waits for every open transaction on that table while later queries queue behind it, so a millisecond change issued during a thirty-second analytics query stalls that table for thirty seconds. Adding a nullable column with a non-volatile default avoids a rewrite from version 11; a new index wants CREATE INDEX CONCURRENTLY, which cannot run inside a transaction block and leaves an invalid index behind if it fails.
  4. Express the answer as a range whose endpoints each trace to a stated assumption, then name the cheapest experiment that collapses it, which is almost always running one real batch against the real table and multiplying.
Follow-up
  • How do you verify the backfill genuinely finished, given rows written by production traffic while it ran?
  • Where does the backfill resume from after a worker is killed mid-batch, and what makes that resume point trustworthy?

Argue against a design, lose, and commit anyway

medium
disagreementservice boundariesdecision records

Describe a design you argued against and lost. State the failure you predicted as a named mechanism, not a feeling about complexity: two services that would need one transaction, a projection with no rebuild path, a write path with no idempotency key. Say what evidence you brought, what the decision maker weighed instead, and what you did after the decision was made: what you instrumented, what you wrote down, and whether the prediction came true. Five minutes.

Approach
  1. State the prediction in falsifiable form up front: the mechanism, the condition that triggers it, and the observable outcome. A prediction that cannot be checked also cannot be credited to you later.
  2. Show the evidence you had at the time and label each piece honestly as measured, analogous, or intuition. Keeping the intuition is fine; disguising it as data is the thing that erodes your standing in the next argument.
  3. Represent the opposing case at full strength, including the constraint you did not control: a fixed date, a team boundary, or the fact that the decision was cheap to reverse and yours was not.
  4. Make disagree-and-commit concrete. Name the artefact you left behind so the prediction could be settled without you: the alert and its threshold, the counter on the dashboard, the decision note that recorded the trade-off and the condition that would revisit it.
Follow-up
  • What threshold on that alert would have proved you right, and did anyone ever look at it?
  • If the same proposal arrived tomorrow with the same deadline, would you argue it the same way?

Ship under a deadline and bound the debt you chose

medium
paginationtechnical debttradeoffs

You have four days to ship a tenant-facing listing endpoint. The version you would defend uses keyset pagination over (tenant_id, status, updated_at DESC, resource_id DESC); the version you can finish uses LIMIT/OFFSET with no matching index. Describe a deadline call you actually made of this shape: what you shipped, what you knowingly deferred, how you bounded the damage with a mechanism rather than an intention, and the specific numeric condition that would force the follow-up. Name who you told and where you wrote it down.

Approach
  1. Name the deferred failure precisely instead of calling it slow. OFFSET n makes the database produce and discard n rows, so cost grows with page depth; without an index matching the sort, every matching row is read and sorted before the limit applies; and rows inserted between two page fetches shift across the boundary so items are skipped or repeated with nothing in the response to signal it.
  2. Bound the blast radius with something mechanical rather than a promise: cap maximum page depth, cap page size, restrict the endpoint to one internal caller, or keep it behind a flag. State which failure each cap removes and which it leaves standing.
  3. Attach a number to the trigger and wire it to an alarm: the first tenant crossing N resources, or the endpoint's p99 crossing its share of the 400 ms budget, so the debt announces itself instead of waiting to be remembered.
  4. Write it where the next engineer looks, which is the code and the ticket, not a chat message: what was deferred, why, the cap, and the trigger.
Follow-up
  • At what page depth does the offset version breach your latency budget, given your page size and row counts?
  • What breaks first when you switch to keyset pagination later, and what does a client holding an old page token see?
  • 01

    You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.

  • 02

    Describe a design you argued against and lost. State the failure you predicted as a named mechanism, not a feeling about complexity: two services that would need one transaction, a projection with no rebuild path, a write path with no idempotency key. Say what evidence you brought, what the decision maker weighed instead, and what you did after the decision was made: what you instrumented, what you wrote down, and whether the prediction came true. Five minutes.

  • 03

    You have four days to ship a tenant-facing listing endpoint. The version you would defend uses keyset pagination over (tenant_id, status, updated_at DESC, resource_id DESC); the version you can finish uses LIMIT/OFFSET with no matching index. Describe a deadline call you actually made of this shape: what you shipped, what you knowingly deferred, how you bounded the damage with a mechanism rather than an intention, and the specific numeric condition that would force the follow-up. Name who you told and where you wrote it down.

PracHub preparation framework ↗

Frequently asked questions

How difficult are the DSA rounds at Nykaa?

The DSA rounds generally feature LeetCode Medium level questions, though you may occasionally face hard-level questions during competitive campus placements or senior engineering interviews. Focus on mastering arrays, sliding windows, stacks, trees, and dynamic programming.

Nykaa Software Engineer candidate reports ↗
What is the expectation in the LLD round?

You are expected to design a fully functional system using object-oriented principles. You should clearly define your classes, interfaces, database schemas, and apply appropriate design patterns. Be prepared to write executable or pseudo-code to demonstrate your design.

Nykaa Software Engineer candidate reports ↗
How long does the entire hiring process take?

If you are attending a weekend hiring drive, the technical rounds are typically completed on the same day. For standard off-campus hiring, the process can take anywhere from 2 to 4 weeks from the initial screen to the final offer.

Nykaa Software Engineer candidate reports ↗
Does Nykaa offer remote work options for Software Engineers?

Nykaa generally operates on a hybrid work model. The primary engineering hubs are located in Gurgaon, Bengaluru, and Mumbai, and physical presence at the office is typically required for a specified number of days per week.

Nykaa Software Engineer candidate reports ↗
What topics does Nykaa test in interviews?

Nykaa interviews most often cover Problem Solving, System Design, SQL, Java, and Collaborative Filtering. The exact emphasis depends on the specific role you apply for.

Nykaa Software Engineer candidate reports ↗
Sources & methodology 3 sources ↗

No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.

Browse Software Engineer questions