Lenskart Work Culture

Lenskart

Claimed

Lenskart is Asia’s largest eyewear company serving 40 Million people - helping them see better and lead better quality lives. We have more than 1500 omnichannel stores across 175 cities in India, Singapore and Dubai. Our aim is to serve One Billion eyes by 2025 globally. And in this journey, we want to go beyond vision correction to transform the way people see and experience the world. That’s our new purpose - and we can only get there through cutting-edge technology and exceptional people.

We share metrics such as Net-Promoter Score (NPS), Monthly Active Users (MAU), Daily Active Users (DAU) etc., among the various team leads to understand which feature is working out and which is not, and we quickly iterate from there.

There have been cases where we released a feature and dropped it without hesitation as the metrics were not meeting our internal benchmark.

At Lenskart, we focus on readable code and standardisation to avoid cognitive overloads. Even things such as how to structure "if" statements are standardised. We also pay extra attention to other areas like library versions, node versions and naming conventions.

One example of how we further achieve code quality is our strong belief in using strongly typed languages, hence our choice of TypeScript instead of JavaScript.

In addition, we also actively allocate time to clean up technical debt and write tests.

At Lenskart, we strongly believe in and advocate for good work-life balance through the different practices implemented.

We have flexible hours and a hybrid working arrangement where we can work from home on certain days.

Also, we avoid contacting and pinging each other outside of working hours and at weekends, unless it is an emergency like the website being down and users being unable to transact. Luckily, this rarely happens as we make it a point not to deploy on Friday.

We also have regular group lunches and dinners to catch up on non-work stuff!

One of the traits we actively look for is collaborativeness, as a non-collaborative teammate can be very disruptive to the team. To us, collaboration means one is willing to help and ask for help in tasks, regardless of whether it is technical or non-technical.

The last round of the interviews is a culture-fit round, where we ask candidates behavioural questions to understand how they would approach problems. Some candidates have been rejected before despite being technically strong because they are more silo.

During performance reviews of the engineering team, team members from the non-technical department will also provide feedback on how collaborative an engineer is.

We try to hire across a broad spectrum of candidates as we believe that people of different cultures, gender and personalities will have different viewpoints, preventing groupthink and highlighting blind spots in any decision-making.

For example, during meetings, we will try to get the quiet ones to chime in with their thoughts or ask them leading questions to prompt them to share their thoughts and knowledge. The last thing we want is to have comments and ideas from the same few voices. Team leads will also keep quiet and be the last to speak to listen to others first. We want to avoid cultivating a follower mentality and culture of "Yes, I agree".

Pair programming occurs on a need-to basis, which can be because of code unfamiliarity or seniority. Junior developers will encounter pair programming more often, but senior developers may also initiate it if they are touching a part of the codebase with which they are not very familiar. Pair programming is encouraged for tricky tickets.

Culture QnA

We follow the Github flow process, but it is structured slightly differently as we have teams in different countries.

Senior engineers will do the code reviews, and we often try to mentor junior developers to do code reviews to build confidence and expertise.

We don't deploy on Fridays except in rare cases, and all senior engineers have to take the lead for being on call. Junior developers will pair with a senior developer. We have automated messages coming into Discord for any production issues.

The ideas are from stakeholders, and then the product managers or team leads will plan the timeline, priority and effort.

Next, the developers will chime in with their questions, and the development process will begin once the developer feels comfortable enough.

Developers are encouraged to talk to stakeholders directly to clear doubts and get further clarification.

Bugs are prioritised by the team lead, product manager and stakeholders. Generally, any bug on the critical path takes precedence over everything else.

We allocate time regularly to clean up tech debt and refactor code. Small technical debts can be cleaned up during development, and the developers decide on that.

1 or 2 sprints

Newcomers will have access to the documentation to get the project up and running, and a senior developer will oversee that. They are also quickly assigned a simple ticket to fix and get onboard ASAP to build confidence and productivity!

We pair-program on a need-to basis. It could be due to code unfamiliarity, seniority of the developer etc. Pair programming is encouraged for tricky tickets.

We do estimations based on task size, the level of the engineer, and the code complexity.

We do post mortems at the end of every sprint in a round table session where everyone is encouraged to speak up.

For developers, we try to avoid as many meetings as possible; Meetings are kept short, and developers can drop out of the meeting if they feel they are not needed.

We evaluate for team impact, code quality and cohesiveness. No point in meeting the milestone for a project and having 80% of the developers quit after the project.

We generally let the developers decide which hours they are more productive. Some are morning birds, some are night hours, and we try not to overload them with tasks we see on the JIRA board.

Yes, sometimes developers can have the opportunity to work on different projects.

About 20%

It depends on whether the internal developer can get up to speed fast enough to fill the role, or it is faster to get an external candidate. Generally, we prefer internal promotion as the internal candidate already fits the culture to a T, while there is still a risk with external candidates.

Upfront, but in a non-emotional manner. We tell them the mistakes, learnings, and what to do going forward.

We encourage team lunches and dinner/drinks regularly to shoot the breeze and build camaraderie.