General Information

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.