Introduction
- Hello Souvik, would love to know about your professional background.
- 
Hi, I’m Souvik! I graduated in 2022 from NIT Allahabad (MNNIT) in Computer Science and Engineering. After that, I got placed into Standard Chartered as a software engineer and worked there for close to two years.
Then, I decided I wanted to explore the startup side of things a little bit more. So I joined this early-stage startup called FuturElectra, where I'm currently in the role of the founding engineer, looking after product and tech. That’s about it.
Day in the life of a software engineer
- What does a typical day look like for you as a software engineer?
Every day is quite different, but I'll touch upon the things I try to cover as part of my responsibilities as a founding engineer.
I ensure that the requirements for the engineering team are ready so we can start with the front-end and back-end development without getting blocked by discussions. Startups often don't have the luxury of proper processes, especially in the early stages.
I spend more time on the architecture design of how our systems should work and how the product’s user experience should be (UI/UX) I have regular meetings with our sales and collection teams to understand the challenges they face and how we can integrate tech to solve their problems. For example, building a notification system to help them identify customers with pending payments and the amounts they need to pay, including penalties, to assist them in making calls and ensuring payments come through.
After gathering requirements and having internal discussions with the founder and tech team, I prepared the architectural design of how the backend and frontend systems would work. I document these and provide them to the team. I also get involved in the backend development. Since we currently don't have a DevOps engineer, part of my day is spent setting up environments and servers to ensure everything runs smoothly.
Tech Stack
- With so many new tools popping up in the tech world every day, it can be hard to keep track! Can you tell us some specific tools that you swear by? Give us a peek into your tech stack.
- 
- 1. Hardware Setup
I use a MacBook for my work.
When I'm working at the office, I connect my MacBook to a bigger monitor for better focus when documenting or working on architectural design. However, when I'm working from home, I don't have the option as I recently shifted and don't have a monitor there.
I prefer using an external keyboard to maintain a better posture when working for long hours.
- 2. Software
A. Go-to browser
It depends on the purpose. For personal work, I prefer using Brave. However, when working on projects for Future Electra, I prefer using Chrome.
B. Core work and coding tools
I have consciously chosen to stick to a simple tech stack of JavaScript-based backend and frontend to enable quick shipping and iterations, which is crucial for a startup in the process of making an MVP and finding product-market fit.
We have chosen AWS for cloud services because of its extensive community support, making it easier to find solutions to problems through Google or Stack Overflow searches. I am also quite familiar with AWS.
Big Companies vs Startups
- I noticed you’ve worked at both big companies (Standard Chartered) and startups (FuturElectra). Firstly, can you tell me your preference between the two?
I think it's too early for me to make a definitive choice because I spent around two years working at Standard Chartered, and it's just been six or seven months here at Future Electra. I'm still exploring how things work at an early-stage startup, now that I have experienced both sides.
Both work cultures have their pros and cons, but in terms of my personal preference, I am the kind of person who will take a higher risk for a higher reward. I tend to think about the long-term benefits, so I value the startup culture more because there's a lot of upside potential if the product you're working on finds its product-market fit, gains traction, and eventually captures a bigger market share.
At this point, because I'm willing to take the risk, my preference would be startups over MNCs.
- How would you compare startups with big tech?
1. Documentation and standard operating procedures (SOPs):
- → MNCs have well-established procedures for moving from one step to another, and everything is set.
- → In early-stage startups, there is a lack of documentation and SOPs, and things are quite ad hoc.
This was one of the differences I took time to get used to when transitioning from an MNC to a startup.
2. Work hours and on-call responsibilities:
- → At startups, employees are expected to be available for any outage problems that happen at any time, even in the middle of the night. Founders may call if something is not working in production.
- → While this also happens at MNCs, it's difficult to compare the two because outages occur in both places, and they need to be resolved anyway.
3. Compensation structure:
- → There is a significant difference in the pay scale between startups and MNCs.
- → At startups, employees often take a pay cut but are compensated with employee stock options (ESOPs).
This ties into the higher risk and higher reward aspect of working at a startup. If the startup succeeds, the reward can be substantial.
Navigating a New Tech Role
1. First month
In the first month, the best thing to do is to try to understand the codebase and the coding practices and standards being followed at the firm. If these are not documented, you can talk to your seniors and ask a lot of questions about the practices they follow or what is being followed at the firm. Firms generally have a set of practices for every particular language, like how functions should be declared and how things should be done in a particular manner. I learn a lot by asking a lot of questions.
It also matters to try to understand the leadership style of your manager or whoever you are reporting to because that will help you bond with them better. If you need something or want to ask something, you can put it in the correct way and then learn from them.
2. Next 3 Months:
The next three months would be themed around figuring out how you can add value to the team.
It's about finding out how you can complement the skills that are already there in the team with yours and the things you are better at.
For example, in our case, I can handle the backend systems and the DevOps very well. If there is someone who can handle the front end for me, then the team as a whole is getting value added because that person is complementing the skills of the rest of the team. I would be looking at what skills I can add to the team so that we as a team can be more productive and efficient in delivering whatever projects we are doing.
3. 6 to 12 Months:
Most of the points I would say will not be applicable for freshers straight out of college, but they will be applicable for slightly senior people who are experienced SD1s or SD2s. Once you have crossed that three-month period, you'll be looking to make the maximum impact you can on the team so that the team recognizes your efforts, which will be helpful in your career growth as well.
In the 6-12 months, I would look forward to taking on more code reviews, looking through other people's code, and trying to review the code of juniors. Participate in on-calls and try to understand the procedures to be followed when something breaks in production. Try to be a part of the on-calls voluntarily.
You can also try to volunteer to interview people. Communicate with the HR manager or the person responsible for hiring for your team and let them know you are interested in taking interviews for new folks they might be looking to add to their team. This is one of the ways you can make an impact and put in your case better so that you'll get better opportunities to grow.
If you are not liking the project you are placed in, you can look into the option of working with other teams or changing teams if your firm allows it. Try talking with your colleagues in other teams or anyone you have access to from other teams and understand what work they are doing. If it is of interest to you, you can get in touch with their hiring managers and put out your work and the impact you have already made on your team. This way, if they are hiring anytime, you'll be in their books.
- If you had to give a KPI to know that you’ve succeeded in each of these phases, what would those be?
1. First month
In the first month, since I'll be going through the codebase and understanding my team's culture, I think the best KPI to maximize would be the number of lines of code that I read and comprehend from the actual codebase of the team I'm a part of. Getting deeply familiar with the existing systems and architecture will lay a strong foundation for my work in the coming months.
By the end of this period, I aim to know which teams are working on what projects, how they communicate, and how I can communicate with them effectively. I will prioritize collaboration as it's the best way to grasp the intricacies of our product.
2. Next 3 Months:
Over the next three months, I think it's important to focus on building relationships and getting integrated with the team. One key KPI I would set is the number of one-on-one coffees or lunches I have with people from my own team as well as other teams. This will help me understand the different work streams and get to know my colleagues better.
Another helpful KPI would be the number of code reviews I participate in. Even if I don't get as many code reviews as a senior engineer might, being proactive about reviewing my peers' work will help me learn and contribute more effectively.
Additionally, since I may not get assigned major development tasks in these initial months, a KPI around the number of smaller projects or tasks I'm able to complete, and the story points I'm able to deliver, would be a good way to demonstrate my productivity.
3. 6 to 12 Months:
In the 6-12 month timeframe, now that I've established a strong foundation and rapport within the team, I would set a KPI around taking on more ownership and leadership responsibilities. This could involve metrics like the number of new hires I've helped onboard and mentor, or the number of process improvements I've suggested and implemented to drive better efficiency and collaboration within the team.
The focus would shift from just delivery to also demonstrating my ability to influence the broader team and the company in a meaningful way.
This holistic approach, covering technical, collaborative, and strategic aspects, will help me make a significant impact in the first year of the new role.
- Finally, let’s say someone has completed their first year at their job, at the end of 12 months, if they want to have a successful appraisal, what should their pitch be to the manager given the KPIs you’ve mentioned?
I have this practice of noting down all the details of the project I'm working on, including the bugs and root cause analyses (RCAs) done as the project is being developed and delivered into production. I document how many of these issues I was a part of and how I helped the team, basically noting down all the impact I brought to that project. By the year-end, you might have completed two to three projects, so you'll have a list of things to speak about in your review, such as the team additions you made, the critical bugs you solved that could have become a significant issue in production, or how quickly you were able to turn things around if something broke in production.
If you're doing other things like taking interviews or being part of on-calls, you can also document those. Instead of just documenting and directly presenting it on the day of the appraisal, it's better to communicate consistently with everyone throughout the year. If any issues happen, you should first acknowledge that the issue occurred, and the earlier you communicate, the better. Your manager will not be very angry at you if you communicate effectively. If you can quickly turn the issue around and communicate the things you have fixed and how it's been taken care of to prevent it from repeating, that shows you're doing the right thing for the team and will keep you in their good books.
At the time of appraisals, they can check all the things you have done, and if you follow these practices, you'll likely get a good appraisal at the year-end. It's important to communicate within the year and not just towards the end because good managers would want to give you an appraisal and see you grow if you have been very consistent in your performance throughout the year.
Upskilling in Tech
- So you’ve been in the industry for over 10 years now - I’m sure you must have picked up new skills during this time. Can you tell me what was the motivation for upskilling and how did you go about it?
- 1. Motivation
The key motivation for me is to build systems that are resilient.
The aim is that whatever you build should not fail for any edge case, and there should not be anything left unturned that can cause an outage or issue later. To do that, you need to practice good coding standards and procedures.
- 2. Learning approach
For me, whenever I learn something new, whether it's from a mistake I made, something that broke, or if I'm reading an engineering blog or a good article about any technology, I like to take notes. I have a personal OneNote with different sections for backend, frontend, and different technologies within those areas.
When I'm learning something new, let's say I'm doing a code review and I learn about a new way of implementing something, I'll make a note and think through the reason for making this choice versus what I already do. This opens up my mind to considering more than one solution for the same problem and understanding how one is better than the other.
- 3. Resources to upskill
In my initial years as a software developer, my focus was on writing good code and solving difficult problems through practicing data structures and algorithms. There are two approaches to this: competitive programming or traditional DSA practice on platforms like LeetCode. My target was to be able to solve problems and write clean, modularized code. The book "Clean Code" lays down the principles and practices to follow, specifying what you should not be doing and what could lead to less clean code.
After gaining one to one and a half years of experience, you'll transition into the design part of things. It's important to understand system design at both low and high levels. I have followed the System Design Primer and the two-volume book on system design by Alex Xu. One volume is more focused on the interview side of system design, while the other is about actually building things.
Engineering blogs from companies like Google, Netflix, and Uber are interesting to read and learn from, as their engineers explain what they have built and how they have solved particular problems. If similar problems occur in your firm, you can take references from those blogs.
Arpit Bhayani's YouTube channel is also a good resource. He is a senior software engineer at Google and is currently the CTO and co-founder of Profile.fyi. He has a good playlist of videos explaining the internals and workings of various systems and technologies in detail, which has been really helpful for me in understanding the intricacies of each technology we use.
Qualities of 10x engineers
1. Technical traits
The first thing that comes to my mind is that you should be able to write clean code. If you're writing something and the other person doesn't understand it, you should probably write it again. It may happen that down the line, you come across your own code and are not able to understand what is being written and what the code is particularly doing. Writing clean code helps a lot, not just in terms of code reviews for the other person but also in debugging problems.
It's much easier if you have your code modularized to find the bug specifically and to have error measures in place so that it reports where there could be an edge case failure. The best engineers have these things implemented in their code early on, so even while they are developing, they are able to cover all the test cases. Their code has high coverage of all possible cases, so they don't take much back and forth between code reviews to get through and become live in production. They make sure they do their unit testing and integration testing themselves before putting things up, ensuring the code is ready for the final round of testing and can go live.
The fewer iterations you have to do, the better, and that is one of the key things to being a good engineer. Other than that, I think as a team, if you have a culture where the focus is not on who made the mistake but rather on how to ensure that this mistake does not happen in the system again, that's important.
If you can build practices, SOPs, conditions, or rule sets where bad code cannot go through the system itself and ensure that if things pass through your rule set once, they are bound to not fail in production for the reasons that are already known, that's key. There can be situations where a new issue arises, and in that case, it's okay. We can find a solution to the new situation. I've seen that the best engineers, even my seniors, don't focus on who made the mistake. Instead, they look at how to ensure it won't happen again and implement those things in the practices themselves. That is one of the traits of being a good engineer.
2. Non-technical traits
In terms of non-technical traits, the best engineers are able to communicate with non-technical people, like the sales team or the product team, because they have understood things from a very high level and they understand the product requirements inside out. (10x Engineers are generally good product owners as well). They can break it down into simple, plain English that non-technical folks can understand.
Within the team, the best engineers mostly have a very helpful nature. They volunteer to assist juniors or offer workshops and masterclasses if people want to learn something new. For example, if a particular new batch of freshers has come in, a senior might volunteer to give them a workshop on Spring Boot or any of the technologies they are particularly good at. That's one of the things I've seen the best engineers have - a very helpful nature.
Negotiating salaries in Tech
1. On research
To understand the numbers at a well-known MNC that has been there for many years, it's possible that some of your alumni or seniors would be working there. Since you have access to those people, you can ask them about the average number for the experience level you are currently at.
There are also other sites, like the discuss section in LeetCode for compensation at various companies. People post about their interview experiences and compensation details for different companies. If you search for the particular company and the level you are applying at, it's highly likely that you will find some set of numbers. You can take an average based on which one suits your case best because there are ranges from tier 3 and tier 2 colleges to NITs, IITs, and BITs. Companies try to pay differently to all these tiers of colleges, so you can check for your case, considering the kind of experience you bring to the table.
Other sites like Levels.fyi and Glassdoor are also helpful, but they mostly provide the base salary and maybe the bonus, not the complete compensation package. So it's better to ask your seniors or whoever you have access to in that company or go to LeetCode to find out the numbers.
2. On negotiation approach
Before coming to the negotiation, you need to make sure they like you because they need to believe you deserve what you're negotiating for. The first thing to ensure is that you have performed well in the interviews and they are willing to keep you. Then you could be in a position to negotiate for a better offer than what they are offering because you can't just ask for something without giving a justifiable explanation. They also need to justify it internally and act on it because they may have some constraints within their team, and they have to vouch for you to bring that compensation for your offer.
The compensation package consists of many things like salary, bonus, allowances, stocks, and location. The more options you give them to negotiate, the more likely it is that you'll get a better compensation package that appropriately matches your expectations. Maybe they have constraints and can't increase the cash component above a certain range, but they can make more movement on the stock side of things. Don't focus on just one aspect; look at it as a whole package and try to negotiate on that.
Whenever you're negotiating, keep in mind that companies never negotiate - it's the people who are negotiating.
Assessing Job Offers: Beyond Salary
- How do you assess multiple job offers beyond just the CTC?
In the case where salary is not a major consideration because both offers are similar, the next thing I would consider is the culture of the team. I try to talk to ex-employees or current employees, whoever I have access to, and understand the specifics of the particular team I'm trying to join. I want to know about the team's culture and the leadership style of the manager because every person has a different leadership style, and I need to understand that to grow in my career.
After culture, location is the next factor. If the job is closer to my family or at a location where I am willing to relocate, that would be one of my preferences.
If there's a tie between culture and location, then it will boil down to the product they are working on and the problems they solve. I consider how interesting the work is and whether it would be too mundane, like doing the same thing again after two or three months. I would prefer a place where I would get to learn and work on different things so that I can mature as a software engineer and have a broader understanding. Wherever I am in my career, that diversity of experience will be helpful for me.
Assessing Job Offers: Promotion vs New Job
- At some point, you or someone you know might have an offer for a new role outside your current company or a promotion internally. How would you decide between the two?
The framework I use to look at these situations, where I'm given the option of getting promoted at my current company versus getting a new job, involves considering three main factors, which are different from the previous three.
1. Role
I would consider whether I'm being given a senior role compared to my current one, both in the promotion and the new job. Assuming both roles are senior positions, this would be a point for consideration.
2. Impact and growth
I would have some bias for my current team because I know I have made an impact there, and if I stay, I can grow faster. If I go to a new company, I'll have to establish my impact again and prove to the new manager that I am a good engineer. I would have to do all that work from scratch. So I would consider whether I want to stay in my current company or look out for a new role based on the potential for impact and growth.
3. Salary
Of course, salary would be a factor to consider. If I am being offered a significantly higher salary in the new role, then it could be a reason to consider moving.
Avoiding Burnout and Maintaining Work-life Balance
- Given that you’ve spent a long time in this fast-paced industry - what strategies do you recommend for avoiding burnout and maintaining a healthy work-life balance?
I have felt burnout during the initial days of building a startup, especially when I was the only engineer on the team. I had to handle everything from deciding what to build, designing the product, coding, ensuring correct deployment, and making it available for people to use. There were phases where I got burned out because I had a lot on my plate and didn't have many people to delegate work to or get help from. As the only engineer at a startup, there was no one else to ask for guidance. Sometimes, I got burned out because I wasn't taking breaks and was working for continuous hours.
1. Recognizing burnout
I know I'm burning out when I start questioning my decisions, like why I chose this place or why I'm here. When these kinds of questions start kicking in, I understand that something is wrong and that I might be getting burned out. Another sign is when I become more disinterested in something I was highly interested in earlier. That's an indication that I'm overdoing it, and it's causing burnout. There are also physical symptoms, like not being able to sleep properly or focus on things I previously found interesting.
2. Advice for maintaining work-life balance
-
I learned from my burnout phase that I wasn't taking care of myself physically. I wasn't exercising or eating properly, often skipping meals or not eating on time. I realized that if you eat well and exercise, you'll have better sleep and be refreshed the next day to take on new challenges without getting burnt out.
Taking breaks in between work is also crucial because it's not possible or productive to work 24 hours or for long stretches.
It's better to work in sprints of 2 hours each and take small breaks in between.
Go for a walk, do something physical like going up and down the stairs to get your blood flowing. This way, you'll be recharged for the next 2-hour sprint, keep burnout at a distance, and reduce work-related stress.
Having hobbies outside of work also helps. If you have time after work to do things that interest you, like playing a sport with friends on weekends or practicing music, it can help rejuvenate your mood and refresh you for the next day.
