Lenskart · Software Engineer
Updated · 2026-10-02

Lenskart Software Engineer
Interview Guide

THE 60-SECOND BRIEF

As a Software Engineer at Lenskart, you are at the heart of an omni-channel retail revolution. You will be responsible for building, scaling, and maintaining the robust platforms that power Lenskart’s massive inventory intelligence, supply chain, and customer-facing applications. Your work directly impacts how millions of users discover, purchase, and receive high-quality eyewear. This role requires a unique blend of technical precision and product-minded thinking. Whether you are optimizing search algorithms for the website, building complex inventory planning platforms, or architecting microservices for high-concurrency e-commerce traffic, your contributions directly translate to business growth and operational efficiency.

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

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

Data StructuresAlgorithms (Problem Solving)DSA (Coding Assessment)

22 min read

Browse Software Engineer questions

See the practice prompts

21Practice promptsAcross five skill areas

As a Software Engineer at Lenskart, you are at the heart of an omni-channel retail revolution. You will be responsible for building, scaling, and maintaining the robust platforms that power Lenskart’s massive inventory intelligence, supply chain, and customer-facing applications. Your work directly impacts how millions of users discover, purchase, and receive high-quality eyewear. This role requires a unique blend of technical precision and product-minded thinking. Whether you are optimizing search algorithms for the website, building complex inventory planning platforms, or architecting microservices for high-concurrency e-commerce traffic, your contributions directly translate to business growth and operational efficiency. You will operate in a fast-paced, data-driven environment where your ability to write clean, maintainable code is as critical as your ability to solve complex system-wide architectural challenges.

01

Online Assessment

reported

Initial assessment focusing on data structures, algorithms, and SQL.

What to demonstrate

  • Initial assessment focusing on data structures, algorithms, and SQL
  • Depth in Data Structures

How to prepare

  • Answer aloud and timed: Reverse a linked list using an optimized approach.
  • Answer aloud and timed: Check if the given braces are in order using a stack.
Lenskart Software Engineer candidate reports ↗
02

Technical Rounds

reported

Multiple rounds focusing on past projects, algorithm implementation, and system design.

What to demonstrate

  • Multiple rounds focusing on past projects, algorithm implementation, and system design
  • Depth in Data Structures

How to prepare

  • Answer aloud and timed: Find a pair in a rotated sorted array whose sum equals 'k'.
  • Answer aloud and timed: Implement a solution to identify if a binary tree is a Binary Search Tree (BST).
Lenskart Software Engineer candidate reports ↗
03

Final Round

reported

Managerial or leadership round evaluating alignment with company goals and teamwork.

What to demonstrate

  • Managerial or leadership round evaluating alignment with company goals and teamwork
  • Depth in Data Structures

How to prepare

  • Answer aloud and timed: Find the row with the most number of 1s in a row-wise sorted 2D array.
  • Answer aloud and timed: Provide a Low-Level Design (LLD) for a splitwise app.
Lenskart Software Engineer candidate reports ↗

PracHub editorial advice for the preparation topics above.

01

Structure your answers

When explaining your thought process, use the STAR method (Situation, Task, Action, Result) to keep your answers concise and impactful.

02

Master the fundamentals

Don't just learn frameworks; understand how they work under the hood (e.g., how a HashMap works in Java).

03

Be ready for behaviorals

Even in technical roles, be prepared to talk about how you handle conflict, deadlines, and team feedback.

04

Ask meaningful questions

At the end of your interview, ask about the team’s current technical debt or their approach to scaling, as this shows you are thinking like an engineer who cares about long-term product health.

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

18 technical prompts0 include a worked solution

Reverse a linked list using an optimized approach.

medium
Data Structures and Algorithms

Reverse a linked list using an optimized approach.

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?

Check if the given braces are in order using a stack.

medium
Data Structures and Algorithms

Check if the given braces are in order using a stack.

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?

Find a pair in a rotated sorted array whose sum equals 'k'.

medium
Data Structures and Algorithms

Find a pair in a rotated sorted array whose sum equals 'k'.

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 a solution to identify if a binary tree is a Binary Search Tree (BST).

medium
Data Structures and Algorithms

Implement a solution to identify if a binary tree is a Binary Search Tree (BST).

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?

Find the row with the most number of 1s in a row-wise sorted 2D array.

medium
Data Structures and Algorithms

Find the row with the most number of 1s in a row-wise sorted 2D array.

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 a search box service.

medium
System Design and Architecture

Implement a search box service.

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 the Java 8 features and their practical use cases.

medium
Language-Specific and Core Fundamentals

Explain the Java 8 features and their practical use cases.

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?

What is a Singleton class, and how do you implement it correctly?

medium
Language-Specific and Core Fundamentals

What is a Singleton class, and how do you implement it correctly?

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?

Explain the view lifecycle and main callbacks in Android.

medium
Language-Specific and Core Fundamentals

Explain the view lifecycle and main callbacks in Android.

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?

Which thread does the ViewModel run on by default?

medium
Language-Specific and Core Fundamentals

Which thread does the ViewModel run on by default?

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?

What is debouncing in JavaScript, and how do you implement it?

medium
Language-Specific and Core Fundamentals

What is debouncing in JavaScript, and how do you implement it?

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?

Built from the rounds and topics Lenskart 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 Lenskart loop
  • Write out the reported sequence: Online Assessment, Technical Rounds, Final Round.
  • 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 3 reported rounds, with the weakest marked.

02Work Data Structures
  • Spend the session on Data Structures, which Lenskart 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 (Problem Solving)
  • Spend the session on Algorithms (Problem Solving), which Lenskart candidates report being tested on.
  • Write one worked example in Algorithms (Problem Solving) and time yourself on it.

Deliverable: One timed worked example in Algorithms (Problem Solving).

04Work DSA (Coding Assessment)
  • Spend the session on DSA (Coding Assessment), which Lenskart candidates report being tested on.
  • Write one worked example in DSA (Coding Assessment) and time yourself on it.

Deliverable: One timed worked example in DSA (Coding Assessment).

05Answer out loud: Data Structures and Algorithms
  • Answer aloud, timed: Reverse a linked list using an optimized approach.
  • Answer aloud, timed: Check if the given braces are in order using a stack.

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

06Answer out loud: System Design and Architecture
  • Answer aloud, timed: Provide a Low-Level Design (LLD) for a splitwise app.
  • Answer aloud, timed: Design a Parking Lot system (HLD + LLD).

Deliverable: Spoken answers to 2 reported System Design and Architecture question(s), under time.

07Answer out loud: Language-Specific and Core Fundamentals
  • Answer aloud, timed: Explain the Java 8 features and their practical use cases.
  • Answer aloud, timed: What is a Singleton class, and how do you implement it correctly?

Deliverable: Spoken answers to 2 reported Language-Specific and Core Fundamentals question(s), under time.

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

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

Turn a code review disagreement into a decision

easy
code reviewoptimistic concurrencycommunication

A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

Approach
  1. Sort the disagreement before writing anything. A silently discarded write is a correctness claim about data; the choice between 409 and 412 is taste. Only the first justifies blocking a merge, and saying which one you are doing is most of the value of the comment.
  2. Make the claim reproducible in the comment itself with an interleaving rather than a principle: A reads version 7, B reads version 7, B commits version 8, A's predicate matches zero rows, A is told it succeeded and A's edit is gone.
  3. Offer the alternative with its cost attached: return 409 carrying the current version and the revision that won, so the client can re-read and re-apply. Note that automatic retry is not the fix, because a retry re-reads the winner's state and reapplies an intent formed against data that no longer exists.
  4. Apply an escalation rule you can state: two round trips on the thread, then a call, and the service's owner decides rather than the reviewer. A reviewer who cannot be overruled is a bottleneck with extra steps.
Follow-up
  • Where would you put the test that fails if someone reintroduces the swallowed zero rowcount?
  • The author says clients cannot handle a 409. How do you check whether that is true?

Reverse your own decision and price the reversal

medium
reversibilitymeasurementmigrations

Describe a technical decision you made and later reversed. Pick one that cost something: a service you split and merged back, a cache you added and removed, an index you created that pushed the planner onto a worse plan, a projection you rebuilt from scratch. State what you believed when you decided, the measurement that changed your mind, how long the wrong version ran in production, and what the reversal cost in migrations, dual writes, and a deprecation window for callers you did not own.

Approach
  1. State the original rationale without irony, in the version you would still defend given what was known then. If it is not defensible, the story is about carelessness rather than judgement, and a different example serves you better.
  2. Give the measurement that moved with a before and after: the p99 that did not improve, the cache hit rate that sat at 40%, the plan that flipped to a sequential scan once the table passed a size you can name.
  3. Cost the reversal in steps, not adjectives: expand-and-contract deploys, the dual-write window, the callers who had to be notified, the rows already written in the wrong shape that had to be backfilled or abandoned.
  4. Distinguish reversal from rewrite by naming what you kept. Most good reversals preserve the schema or the interface and undo one decision inside it, which is also why they were affordable.
Follow-up
  • What in that decision was irreversible, and did you know it was irreversible when you made it?
  • How did you tell the people who had already built on top of the original decision?

Narrate an outage you owned from page to postmortem

hard
incident responseblast radiuspostmortems

Pick an incident you personally drove, ideally one where writes were affected rather than reads. In six to eight minutes: state the symptom as it first appeared on a dashboard, the blast radius you established before you knew the cause, the mitigation you applied and when, the mechanism you eventually proved, and the follow-up that would prevent a repeat. Bring numbers: error rate, tenants affected, minutes to mitigate, minutes to resolve. If you cannot name what you measured, choose a different incident.

Approach
  1. Open on the signal rather than the cause: which metric at which percentile moved, on which service, at what time, so the listener follows the same evidence you had rather than a conclusion you already reached.
  2. Separate mitigation from diagnosis out loud. State what you did to stop the bleeding (flag off, shed traffic, drain a lease, roll back a deploy) and say plainly that you did it before the mechanism was known, because those are two jobs with different deadlines.
  3. Establish blast radius in countable terms: how many tenants, how many writes, and crucially whether the effect was loss or only delay. An append-only revision table or a pending outbox row means the change survived and the projection was merely behind, which is a repair rather than a data-loss incident.
  4. Prove the mechanism instead of asserting it. Name the trace span that grew, the plan that flipped to a sequential scan, the lease that expired, plus one alternative you ruled out and the signal that stayed flat while you ruled it out.
Follow-up
  • What would you do differently in the first five minutes, given the same dashboard and no more information?
  • Which follow-up action did you deliberately not take, and why was dropping it the right call?
  • 01

    A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

  • 02

    Describe a technical decision you made and later reversed. Pick one that cost something: a service you split and merged back, a cache you added and removed, an index you created that pushed the planner onto a worse plan, a projection you rebuilt from scratch. State what you believed when you decided, the measurement that changed your mind, how long the wrong version ran in production, and what the reversal cost in migrations, dual writes, and a deprecation window for callers you did not own.

  • 03

    Pick an incident you personally drove, ideally one where writes were affected rather than reads. In six to eight minutes: state the symptom as it first appeared on a dashboard, the blast radius you established before you knew the cause, the mitigation you applied and when, the mechanism you eventually proved, and the follow-up that would prevent a repeat. Bring numbers: error rate, tenants affected, minutes to mitigate, minutes to resolve. If you cannot name what you measured, choose a different incident.

PracHub preparation framework ↗
How long should I spend preparing for the technical rounds?

Given the importance of DSA and system design, most candidates find that 4–6 weeks of consistent practice is necessary to feel confident.

Lenskart Software Engineer candidate reports ↗
What is the most common reason for rejection?

Failing to provide an optimized solution or struggling with the core fundamentals of the language (like Java collections or concurrency) are the most frequent reasons.

Lenskart Software Engineer candidate reports ↗
Is the culture at Lenskart fast-paced?

Yes, it is a high-growth environment. You should expect to work on urgent deliverables and demonstrate a high level of ownership.

Lenskart Software Engineer candidate reports ↗
What is the typical timeline from the first round to an offer?

While it can vary, the process generally moves within a few weeks, though scheduling can sometimes be delayed. Stay proactive in your follow-ups.

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

Lenskart interviews most often cover Java, Problem Solving, Data Structures, Linked Lists, and Python. The exact emphasis depends on the specific role you apply for.

Lenskart 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.