Lenskart Technical Program Manager Interview: Questions & Prep (2026)

Lenskart is one of India's most recognised D2C eyewear brands, with tech teams running everything from its e-commerce platform and in-store POS systems to supply chain management, lens manufacturing, and last-mile logistics. A Technical Program Manager here typically owns large, cross-functional programs that touch engineering, product, retail operations, and vendor management, often at the same time.

As of July 2026, job listings showed 228 open roles at Lenskart, signalling an active hiring period. Candidates typically report 4-6 rounds covering a recruiter screen, a hiring manager discussion, one or two program management deep-dives, and a final round with senior leadership. The interview style tends to be practical: interviewers want real examples from your past, not textbook frameworks.

TPM openings in the broader market as of the same date included 41 in Bangalore, 14 in Delhi, 13 in Pune, and 12 in Hyderabad, reflecting where most of this demand is concentrated.

These questions come up frequently in Lenskart TPM interviews, based on what candidates report:

1. Walk me through a complex, multi-team program you owned from kickoff to launch. What were the hardest parts?
2. Lenskart operates both online and offline channels. How would you manage a program that needs both to ship at the same time?
3. Describe a time when engineering and business stakeholders had completely different priorities. How did you align them?
4. How do you track dependencies across multiple engineering squads working in parallel?
5. Tell me about a program that slipped its deadline. What caused it and what did you do?
6. How do you handle a stakeholder who keeps expanding scope mid-program?
7. Lenskart ships in multiple geographies. Have you managed programs with distributed teams across time zones?
8. How do you decide which risks to escalate versus handle yourself?
9. Walk me through how you run a post-mortem. What do you actually change after it?
10. How do you work with vendor or third-party teams when you have no direct authority over them?
11. Describe your approach to a program that involves both software and physical elements, for example in-store devices or manufacturing equipment.
12. How do you keep leadership informed without creating meeting overload for your engineering teams?

Q: Walk me through a complex, multi-team program you owned from kickoff to launch.

*Situation:* At my previous company, we needed to launch a unified order management system connecting three separate teams: e-commerce engineering, warehouse operations, and the customer support platform. Each team had its own roadmap and different release cadences.

*Task:* I was the sole TPM responsible for bringing all three to a single go-live date within a fixed window.

*Action:* I started with a two-day kickoff that mapped every team's dependencies on a shared board. I set up a weekly cross-team sync and a separate async update channel so engineers were not pulled into unnecessary calls. I flagged a critical API contract mismatch between the e-commerce and warehouse teams early on, pulled both leads into a working session, and we resolved it within days rather than letting it drift.

*Result:* We shipped on time. Post-launch, order processing errors dropped noticeably, and the customer support team reported fewer escalations in the first month.

---

Q: How did you handle a situation where a key stakeholder kept expanding scope mid-program?

*Situation:* During a retail app redesign, a senior business leader kept adding features after we had locked scope, citing competitive pressure.

*Task:* I needed to protect the launch date without damaging the relationship with that stakeholder.

*Action:* I created a simple impact table showing each new request mapped to the specific team it would affect, the estimated delay in weeks, and what we would need to drop from current scope to absorb it. I shared this before every meeting rather than simply declining requests. I also set up a formal change-request process so additions were documented and prioritised against existing scope, not added verbally.

*Result:* Scope additions dropped sharply. The launch went ahead on the original date, and the stakeholder later used the impact table format in their own planning reviews.

---

Q: Tell me about a program that slipped its deadline. What caused it and what did you do?

*Situation:* A supply chain visibility dashboard I was running slipped because a third-party data provider changed their API without notice shortly before our launch.

*Task:* I had to decide quickly whether to delay the full launch, go live with reduced features, or find an alternative data path.

*Action:* I mapped what data was still available through internal systems and called an emergency session with engineering. Within two days we had a fallback plan: launch with internal data only and surface a 'coming soon' label for the affected third-party feeds. I communicated the revised plan to leadership with a clear root-cause note and a timeline for the full feature.

*Result:* The core product went live on the original date with most of the planned functionality. Stakeholders appreciated the transparency, and the partial launch kept the business team's momentum going while we completed the full integration.

Use STAR for every behavioural question. Keep Situation and Task brief so the bulk of your answer covers Action and Result. Lenskart interviewers tend to probe the Action section hard, asking what you specifically decided rather than what the team did, so go into the actual choices you made and why.

For 'how would you approach X' questions, use a three-step structure: first, understand the problem (who are the stakeholders, what are the dependencies, what does success look like); second, plan (milestones, risk log, communication cadence); third, execute and adapt (how you track progress and handle blockers). This signals systematic thinking without sounding like you are reciting a textbook.

For conflict or pushback questions, lead with the business context rather than the interpersonal tension. Interviewers want to see that you resolved disagreements by connecting them to data or customer impact, not by avoiding the conversation or pulling rank.

For metrics questions, be specific about what you measured and why. On-time delivery rate, defect escape rate, post-launch customer issues, and stakeholder satisfaction are all signals a TPM working at Lenskart's scale would reasonably track.

Lenskart TPM interviewers are looking for a few qualities in particular.

Ownership without authority. TPMs at Lenskart work across engineering, product, retail ops, and supply chain teams without direct reports in most of these areas. Interviewers want to see that you can drive alignment and accountability through influence rather than hierarchy.

Speed and pragmatism. Lenskart moves fast and its business spans physical and digital channels simultaneously. Candidates who show they have made good-enough decisions quickly, communicated clearly, and iterated afterward tend to do better than those who emphasise thoroughness at the expense of velocity.

Comfort with ambiguity. Expect at least one question where there is no clean answer. Interviewers want to see your reasoning process, not a perfect solution.

Stakeholder communication at multiple levels. You should be able to talk to an engineer about an API dependency and to a business leader about launch risk in the same week. Bring examples of both.

Data fluency. You do not need to be a data scientist, but you should be comfortable reading a dashboard, pulling a report, and using numbers to make a case or escalate a risk.

Week 1: Know the company.
Read Lenskart's recent press coverage and any public engineering blog posts you can find. Understand how their omnichannel model works: online orders, in-store prescriptions, home eye tests, and the lens manufacturing side. Your examples will land much better if they reference the kind of programs Lenskart actually runs rather than a generic tech company.

Week 2: Build your story bank.
List six to eight programs from your career that cover different question types: a complex multi-team program, a program that slipped or failed, a conflict with a stakeholder, a vendor management situation, and a data-driven decision. Write each in STAR format and practise saying them out loud, aiming for two to three minutes per story.

Week 3: Sharpen your technical depth.
Lenskart's TPMs need enough fluency to talk meaningfully with engineers. Brush up on how APIs, microservices, and data pipelines work if you are rusty. You do not need to write code, but you should be able to ask the right questions about risk, timeline, and trade-offs.

Before each round: Look up your interviewer on LinkedIn. If they come from supply chain or retail, lead with examples from those domains. If they come from pure-play tech, lean on platform or infrastructure programs.

Staying too high-level. The most common issue candidates report is describing what 'the team' did rather than what they personally decided. Lenskart interviewers probe with questions like 'what did YOU specifically do here?' Prepare to own specific decisions, not just outcomes.

Not knowing the business context. Candidates who treat this like a generic tech company interview miss the nuance of Lenskart's model. The intersection of physical retail, manufacturing, and e-commerce creates real complexity. Show that you understand it.

Confusing project management with program management. A project manager tracks tasks. A TPM manages risk, dependencies, and alignment across multiple teams simultaneously. Make sure your answers reflect that distinction clearly.

Vague results. Closing a STAR answer with 'the project was successful' without any signal of what changed is weak. Even qualitative results ('the sales team stopped escalating the issue') are more convincing than nothing.

Over-preparing for coding rounds. TPM interviews at Lenskart typically do not include whiteboard coding, candidates report. Spend that time on behavioural stories and stakeholder scenarios instead.

Not asking strong questions. The questions you ask at the end of each round signal whether you think like a TPM. Ask about current program challenges, how the team measures success, or what a typical escalation path looks like.