My journey as a Software Engineer at a fast growing startup
My learnings and experience working as a Software Engineer at a fast-growing startup
In this article, I will share what is it like to work as a Software Engineer at a fast-growing startup. I will share my journey and experiences working as a Software Engineer in the past few years. In the end, I will also share some learnings that you can take note of if you are also someone who is going to start or just started working as a Software Engineer.
A little background about myself 🙋♂️
After graduating a couple of years back, I started working as a Software Engineer at a leading healthcare startup in India. Being passionate about startups, I always wanted to work at one of those, as I had heard many great things about work culture and the quality of work exposure that people get.
In my college days, I was mostly involved in full-stack web development and had mostly worked on PHP and MEAN(MongoDB, ExpressJs, Angular and NodeJs) stack.
The startup journey 🌟
I started my full-time job as a Software Engineer. I was working as a backend engineer in one of the most critical and core teams of the startup which dealt with the catalogue of products and their various properties.
The project that I was part of 💻
My team was responsible for all things about the product not only the static information that gets shown on the website but also its dynamic properties like its stock availability, price, discounts, etc which are calculated at each city level throughout India in real-time.
Apart from this, our project also had various algorithms and logic which dealt with showing substitutes / similar products in case the requested product was not available in a particular city in real-time.
It was a monolith project back then and was developed using Ruby on Rails, Redis and MySQL.
The first couple of months were pretty intense for me with lots of learning and understanding of the product, system and this new tech stack.
After the first six months, I was pretty comfortable working on medium-sized features and a few large-sized features with some guidance from my team members.
Coping up with the scale 🏹
Then COVID hit India by late 2019. During this time, our startup being in the healthcare e-commerce domain got unimaginable 3x boosts in growth. With this, even the product, audiences and features grew in numbers and size and existing systems started becoming overhead in terms of maintenance and scale.
We started doing optimisations in the existing code and infrastructure, like upscaling the application and database servers, optimising the code, optimising database and cache queries, etc. All these helped us to a certain extent but were still not much performant. At the same time, we also saw a few changes in the business models which could mean major changes in our services. So we had to think of a long-term solution to cope with this scale and extensibility, keeping in mind that the tech for these new business changes should be scalable and maintainable.
So we decided to split this single monolith into multiple small independent services so that they can be scaled and maintained independently. The new tech stack chosen was Java(Springboot Webflux), Redis, Kafka and MongoDB to keep in line with the newer requirements and the increasing scale.
The journey from here 💫
Being in the core and critical team of the company, I got a chance to directly work towards these things. The next six months were crazy in terms of learnings in the new tech stack again, managing multiple services and trying to cope with the rapid growth. But as difficult as it seems, it was immensely wonderful in knowing and being part of this journey.
It was during this period that I got a whole new set of experiences which I could have never got otherwise, to work from scratch on building the micro-services end to end and migrate the live traffic from monolith service to these micro-services without any business interruption.
At this point, I not only learned about product development but also about how the systems are built at scale and what it means to build a distributed system. Our team as well grew in size and I was also mentoring new joiners. I also started making proper documentation so that it's easier for the new joiners to refer to it. All this happened in a matter of just 1 year!
So by the end of 2 years into this startup where I joined as a fresher, I had worked on a monolith system, later transformed the system into microservices, migrated the live traffic to these new services, guided new joiners and also made significant tech documentation for our team.
My observations 🕵🏻♂️
There were a couple of things that I loved about this experience.
There was a lot of flexibility for trying out things. It does not matter if you are a fresher or a senior; if you prove that you are capable of doing what is required, then you can get great opportunities and chances to work on some amazing projects with some amazing teams.
In startups, there are fewer processes in place which enable teams to work more on the features that matter the most and deliver them in less time, which might not be possible in some big tech companies.
People are also extremely friendly and transparent in most startups, be it a fresher or most senior technical architect/lead, the people are almost always willing to help.
The pace of a startup is much faster compared to a bigger organisation. This also means you get to contribute a lot to the startup growth journey. So just after a year or two, if you had built great products, or worked with an amazing team on good projects, the work experience and work ethic you gain and exhibit helps you become a great software engineer ahead.
My learnings 💡
Apart from the experiences that I have shared above, I am also sharing a few learnings below that I got while working, which helped me grow personally and professionally.
Initially, after spending some time on the tech stack, you get used to it and coding in itself becomes easy. As a next step, try to understand the complete product/project you are working on.
Try to get overall high-level knowledge of your system. Read through the Architecture docs, RFCs, and decision records designed for your system.
Read the product documents(PRDs, research docs, etc) to know the historical metrics of previous versions of your product and how it has evolved.
Be proactive in resolving queries raised by customers/other teams. This will help you to know your system better
Spend time understanding your service metrics, like the API latencies, throughput patterns, database latency, time-consuming database queries, etc. For this, you can start being actively involved in the service deployments/release, as the team would usually be monitoring all these metrics after any deployment.
Always think about optimising the system as much as you can.
Always speak up, no one else might speak for you. Whatever you do, make sure you keep your team well-informed to avoid any confusion.
If the potential release feature affects the team or other stakeholders, call out early to the team and the stakeholders. Never hesitate to come up with any new idea or findings, be it extremely silly or serious, it can have a huge impact sometimes. Don't wait for other folks in the team to figure it out later. Be proactive.
There are instances where changes at one level might affect other areas too in your service, that's why unit, regression, and sanity tests are most important to do even if you are a developer. Always think about the modularization of the project/feature that you are developing. Avoid code smells! Do a thorough dev testing of your changes before raising a merge request with the team.
If other teams are integrated with your service or actively using your services, then it is your responsibility to support and help them regarding any of the queries or problems they are facing while using your service APIs, events, etc.
Always try to be present and actively support your team. This also helps to build credibility and trust in your team.
Show extreme ownership in the features you are working on. Be proactive in understanding the feature, asking doubts, reaching out to stakeholders for the changes, etc. This will help you grow further as a Software Engineer and also build trust within the team.
Take breaks! Only working all day and doing nothing else will eventually lead to burnout after some time. Make sure you take breaks in between. Play sports, go travel, trek or do something different that you like apart from work. This will help you in being more productive at work as well and also maintains your mental and physical health.
That's it from my end. Please like or comment below if you like this or if you want to share your startup experiences as well. 😃
Let's connect 💫
I am planning to write frequently on various Software Engineering topics, you can subscribe to my newsletter below so that you get an email notification on my latest post. 💻