Lenskart
Internet
5001-10000 Employees
3.6 (Glassdoor)
Claimed
Manages Culture Code and Employee Benefits
About Lenskart
Lenskart's mission is to give India a vision. Lenskart.com is India's fastest growing eyewear company and largest eyewear company online. Lenskart's products range from prescription eyewear, branded contact lenses and sunglasses, all equipped with the customers'​ eye power. Lenskart is backed by IDG Ventures, Unilazer Ventures and TPG Capital.
With a growing chain of offline stores in all cities in India, and its unique Home Eye Check-up service which takes expert optometrists to customers homes/office for an eye test, Lenskart has done what no one could till now. Clearer vision is absolutely accessible now!
So, Log On, Play On!
With a growing chain of offline stores in all cities in India, and its unique Home Eye Check-up service which takes expert optometrists to customers homes/office for an eye test, Lenskart has done what no one could till now. Clearer vision is absolutely accessible now!
So, Log On, Play On!
Lenskart Culture Code
Data-Driven
Top
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.
There have been cases where we released a feature and dropped it without hesitation as the metrics were not meeting our internal benchmark.
Great Code Quality
Top
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.
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.
Conscious Work-Life Balance
Top
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!
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!
Team Oriented
Top
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.
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.
Diversity, Equity and Inclusion (DEI)
Top
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".
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
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.
Lenskart Culture Code QnA
<div>We follow the Github flow process, but it is structured slightly differently as we have teams in different countries.</div>
<div>Senior engineers will do the code reviews, and we often try to mentor junior developers to do code reviews to build confidence and expertise.</div>
<div>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.</div>
<div>The ideas are from stakeholders, and then the product managers or team leads will plan the timeline, priority and effort. <br><br>Next, the developers will chime in with their questions, and the development process will begin once the developer feels comfortable enough. <br><br>Developers are encouraged to talk to stakeholders directly to clear doubts and get further clarification.</div>
<div>Bugs are prioritised by the team lead, product manager and stakeholders. Generally, any bug on the critical path takes precedence over everything else.</div>
<div>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.</div>
<div>1 or 2 sprints</div>
<div>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!</div>
<div>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.</div>
<div>We do estimations based on task size, the level of the engineer, and the code complexity.</div>
<div>We do post mortems at the end of every sprint in a round table session where everyone is encouraged to speak up.</div>
<div>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.</div>
<div>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.</div>
<div>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.</div>
<div>Yes, sometimes developers can have the opportunity to work on different projects.</div>
<div>About 20%</div>
<div>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.</div>
<div>Upfront, but in a non-emotional manner. We tell them the mistakes, learnings, and what to do going forward.</div>
<div>We encourage team lunches and dinner/drinks regularly to shoot the breeze and build camaraderie.</div>
<div>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.</div>
