From Fresher to SDE-3: My journey at Swiggy

I started my career as a software engineer at Swiggy after graduating from BITS in 2019. I was excited about this new path but didn't know what to expect since it was my first real job.

Looking back, some of the highlights from my time at Swiggy include:

• Working on 4 different teams, from fulfilment to assignment to delivery

• Contributing consistently to an open-source project and driving its adoption internally

• Starting as an SDE fresher and leaving as an SDE-3 after three years

I had the opportunity to work with helpful mentors and colleagues, and these three years were the most valuable journey for me. In this document, I will share what worked well for me and how any engineer getting into a startup could make the most of it:

Read, read, and read:

• Read through service documentation, and if you find gaps, ask your mentors and take the initiative to suggest upgrades to the documentation.

• No one will be as invested in your growth story as you. Developing a habit of scanning technical documents shouldn't be hard, especially right out of college. Pick a topic each week and start reading its documentation. For example, if your team heavily uses DynamoDB as part of their database infrastructure, understand its architecture and why DynamoDB is preferred over something like MongoDB. This will lead to two things:

  • It will allow you to actively participate, follow, and contribute to technical discussions with senior engineers on the team, building their confidence in you to handle technically challenging tasks.

  • It will allow you to develop a research acumen that comes in handy when dealing with some technical specifications you may not have encountered before. As a fresh graduate, you will find yourself in such situations quite often.

Learn from feedback:

• Pay attention to feedback from pull request (PR) reviews. Very critical and immediately actionable feedback comes from PR reviews. Make it a point to reduce the frequency of similar feedback in future PRs. Writing good code is an art. If any of the suggestions seem confounding or difficult to understand, follow these steps in order:

  • Search on Google and look for relevant Stack Overflow pages.

  • Search for similar code pieces on GitHub or Bitbucket.

  • Ask your mentor or any senior engineer.

• Have a "can-do, will-do" attitude, no matter how daunting the project may seem. The worst that could happen is you might need help from a senior engineer in your team. Never hesitate to seek help when you are stuck, but make sure to have done sufficient research on your own before entering any discussion. In the long run, this strategy has worked well for me.

Proactive involvement:

• Develop a product backward thinking and proactively get involved in product discussions. Unlike college, catching corner cases is much more intense as it involves real-world scenarios, and missing any can have serious consequences. For example, users are quick to find loopholes while requesting for refund and if your unfiltered list of cancellation reasons shared with upstreams includes ‘tech outage’, you can probably gauge the impending nightmare.

• Find open-source projects being used in your company and start contributing to them. The first step is to go through the documentation (no surprise here) and the recent PRs. This will give you a fair idea of what ongoing issues are with the project. Our minds are like clay, and restricting yourself to the stack used in your team for too long will make it difficult for you to work on a new service on a different stack.

Thanks for reading my first blog! Leave a comment below with any questions or feedback you may have - I'd love to hear from you!❤️