My experience as a Software Engineer at Helpshift
I have been at Helpshift for around a year now, and it has been a beautiful experience so far. Filled with mistakes, lots of learning, and surely a lot of fun. From learning how to write good code, documenting projects and meetings, communicating with different teams, to playing FIFA, TT, chess, badminton, football, and so many new board games, it has been amazing.
I work as a Frontend engineer at Helpshift and each day has been kind of fun and challenging. Working on exciting new projects, participating in various kinds of discussions, and cherishing the people and culture that the team has developed, each day is unique in its own sense.
With this article, I will try to cover different aspects that have been a part of my journey here at Helpshift so far.
- Cross-team discussions
- Code review
- Knowledge Sharing
- Tech Debts and Initiatives
- 1 on 1 session
- The Fun parts
Cross-team discussions
Every project involves a collective effort across teams. The product team comes with documentation around the problem that we are trying to solve and a potential solution to it - The product requirement. After thorough discussions, once the product requirement is all clear, with the help of the product document and detailed design document, the developers are expected to come up with time estimations. The frontend and the backend developer create and decide on an XHR spec, which is the contract for different APIs to be involved in the development process. This basically involves the changes in existing XHRs and details of new XHRs to be added.
Code Reviews
Once you start with the development phase of the project, you start with getting the dev spec being reviewed by 2 more engineers in the team. A dev spec (developer specification) is basically detailed documentation of the implementation plan, identifying code areas to be changed, new requirements, and pseudo-code for the same. The review discussion is usually initiated by a brainstorming session around the project and its expected implementation. This is done just to make sure that all possible scenarios are covered and nothing is missed, neither from a code understanding point of view nor from an edge case handling point of view. In this process, you are also expected to break the entire project down into smaller tasks with estimations to each.
Once you start with the coding part, we have a set of coding conventions in place. It is encouraged to make smaller commits, following those conventions and every single commit is reviewed by 2 peer developers. While reviewing a commit, a developer sees it from readability, efficiency, reusability, and adherence to convention point of view. The reviewers either approve the commit if the commit looks good to them or they leave comments specifying things that can be improved upon in the commit. Once all the comments are resolved and you get approval from both the reviewers on the commit, then only the commit gets merged to the branch.
This is one of the very important ways of learning while developing. Similarly, you also review the code of other developers and hence are able to learn by being on both sides of the process.
Knowledge Sharing
Every developer works on a different project and hence comes across different kinds of interesting problems or topics. All such topics get discussed across the team and many get documented for further action. This brings a lot of learning which otherwise you wouldn’t have encountered.
Also, every Thursday, we have frontend lightning talk which is all about learning new things in the frontend space — be it around performance, libraries, security, browsers, basically anything frontend. One of us comes up with a topic/learning and presents it to the team and explains all of it, the team does discussions around it and whenever there is a possibility of it being helpful for the product, we tend to make one-page documents to take that ahead.
Similar to this, we have more such weekly sessions across teams and an overall engineering lightning talk, every Friday.
Tech Debts and Initiatives
Along with all the efficient code you write, the repositories are also home to some tech debt or things to be improved upon as the tech keeps changing and evolving at such a fast pace.
It’s important to pause and have a look at those and take initiatives in that direction — how to remove the tech debts, how can we improve the processes, what can make the development cycle faster, and all other things that fall in this territory.
Also, as mentioned earlier, we have coding standards in place. If during our development phase, we feel like any convention isn’t really helpful, or if any new convention can be helpful, we encourage such discussions and make amendments accordingly as per the larger team.
Taking initiatives in such directions, in identifying debt, in breaking it down into achievable, in improving workflows, is encouraged across the team and done enthusiastically by many. This also works in helping you grow multifold as an engineer.
1 on 1 session
Mentoring is a very natural process in Helpshift. Every day you’ll end up learning something or the other from all the folks here.
The streamlined process of mentorship is the 1:1 sessions with your managers or senior developers or peer developers. The 1:1 sessions are encouraged to be good meaningful conversations around growth, career, aligning paths, setting and knowing expectations, getting to know the other person and their thought processes better, and insights into how things work in other verticals.
They can be literally about anything, the way you expect them to be, and hence seek the maximum benefit you can out of them.
The Fun parts
When I first joined Helpshift as an intern during my last college semester, I was mesmerized by the culture and the people here. Along with being amazing developers, so many of them had such interesting hobbies which they passionately followed along with work. You would find people playing the sitar and tabla in the office after office hours, you would find people playing new board games each day with the same enthusiasm to learn the rules and give it a try. You’ll find people hustling over the TT table, beating each other in FIFA matches and so much more.
Apart from these, the team books court to play football and badminton on a weekly basis. We go for chai outside the office and have so many varied good and fun conversations. Though now the work environment is hybrid, the passion among people to follow their hobbies, the urge to maintain this culture is still there intact in both online and offline environments.
Overall, Helpshift is a fun place to be. Not only do you grow technically here, but also as a person and end up building good bonds. I am sure there is a lot that I must have missed mentioning and a lot more that I am yet to experience.
Though this might feel like a marketing article, surprisingly it’s not! This is honestly how my experience at Helpshift has been so far and this is what makes me look forward to growing here.
