Introduction
Hello Sudhanshu, would love to know about your professional background.
I'm a software engineer by profession. I started with front-end development but now I'm also doing a bit of back-end work. I graduated from a tier-3 college where the education and academics were not very strong.
At that time, I wasn't actually into software engineering. Instead, I was doing design and animation work.
However, slowly my interest shifted towards coding and engineering. That's when I joined a boot camp called Neog Camp. It was a 6-month cohort-based course focused on front-end development. After finishing the boot camp, I spent some time interviewing and then landed my first job as a software engineer.
Day in the life of a software engineer
What does a typical day look like for you as a software engineer?
My days usually start with a stand-up meeting first thing in the morning. After that, a typical day involves working on UIs, developing them, and integrating APIs with the UI.
In my current company, there aren't too many meetings happening right now. I probably spend about an hour and a half in meetings on average. Since my company is remote, I usually spend around 6 to 7 hours coding each day.
No two days are the same though. During release times, when features are going into production, there are often bug fixes and last-minute changes that need to be made. Those times can get somewhat hectic and we may have to stretch our hours a bit to accommodate the release schedule.
Outside of release periods, the day-to-day mostly revolves around UI development, API integration, and the occasional meeting. The majority of my time is spent hands-on with the code.
What is your mantra to get quality work done?
To ensure I'm delivering high-quality work, there are a few key things I focus on.
First, blocking off dedicated time where I won't be disturbed is crucial. Having uninterrupted stretches to really dive into the code helps me get into that flow state and make meaningful progress.
The second important aspect is thinking about the user perspective when reviewing what I've built. I try to put myself in the user's shoes and consider all the different things they might do with the feature or interface I've developed. This helps me identify edge cases and potential areas for improvement. In development, there are so many possible combinations and scenarios to account for. I make an effort to test and check as many of these as I can to ensure a smooth user experience.
Bugs and edge cases are inevitable in development, but by being proactive in considering the user's viewpoint and thoroughly testing, I can catch and resolve many potential issues before they make it to production.
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
For my workstation, I have two extended monitors - one set up vertically and one horizontally. I also use one external keyboard and mouse.
2. Software
A) Go-to browser
Google Chrome is my primary browser.
B) Core work and coding tools
Most people use VS Code, and I was using that too for a while. But recently I've switched to Cursor, which is a newer option. It's much better than VS Code in my opinion, especially because it has built-in GPT and Codex AI support. That's my main coding tool now. For API testing and development, I use Postman to check and make requests to APIs. And then for task and project management, I use whatever the company's standard tool is, whether that's Asana, Jira, or something else.
C) Favourite programming language
I prefer working with React the most.
Big Companies vs Startups
I noticed you’ve mostly worked at startups. Do you have a preference for working with startups?
I do have a bit of a preference towards startups, although I should mention that I haven't worked at a large MNC yet, so I can't make a direct comparison.
The main reason I'm drawn to startups is because I'm interested in entrepreneurship myself. I see myself potentially starting my own startup or business someday. Working at startups allows me to learn a lot about what it takes to build and grow a company from the early stages.
Startups often provide exposure to a wide range of responsibilities and the opportunity to make a significant impact. I find that environment very appealing and educational, especially considering my long-term goals.
That said, I recognize that there are likely valuable experiences and lessons to be gained from working at larger, established companies as well. I'm certainly open to that in the future.
But for now, the fast pace, broad exposure, and entrepreneurial spirit of startups are a great fit for me and my interests. It's a deliberate choice based on what I want to learn and the direction I see my career going in the long run.
How would you compare startups with big tech?
One key difference is the level of collaboration and connection with your team. At startups, since the teams are usually smaller, you get to collaborate with more people and form closer connections with everyone. In an MNC with a much larger staff, you might not have the opportunity to connect with every person.
Another aspect is the exposure to the company's industry and business model. At a startup, you often gain a deeper understanding of how the business operates and the market it serves.
At startups, the focus is often on shipping code and features quickly. There's a bit of an ad-hoc approach because you're not necessarily building for a massive user base right away. In contrast, my understanding is that at larger companies, there's more emphasis on optimization and perfecting the code before release. They may move a bit slower, but with more attention to detail in terms of performance, scalability, and best practices.
Essentially, startups prioritize speed and getting to market, which can sometimes mean compromising a bit on optimization. MNCs have the luxury of moving more methodically to ensure everything is fine-tuned.
I also suspect there might be more room for rapid growth in a startup environment. The pace of change and the need to wear many hats can lead to accelerated learning and advancement. In larger companies, growth paths may be a bit more structured and gradual. Again, this is just my perception based on what I've gathered from others in the industry.
The reality is that growth often depends heavily on the individual and their specific circumstances. Startups may offer a quicker trajectory, but both startups and MNCs have the potential to support significant growth. It comes down to factors like the company culture, available mentorship, and the developer's own initiative.
Navigating a New Tech Role
1. First month
In the first month, the focus should be on learning practices and tools that are new to you or that you didn't use much before, such as GitHub. It's important to get comfortable with the workflow of raising pull requests, getting code reviewed, making changes based on feedback, and managing branches.
You should also practice tasks like reviewing pull requests, which you may not have done previously when working on solo projects. Concentrate on mastering aspects of teamwork and collaboration that are different from independent work.
2. Next 3 Months:
Moving into the next 3 months, aim to take on important, core features that are central to the product or business. Look for opportunities to work on the key functionality and high-priority areas of the codebase. Gaining experience on these critical components will be very valuable for your future growth.
On the non-technical side, focus on building strong working relationships with your manager and teammates. Establish a reputation for doing great work and being thorough in your approach. Put extra effort into collaboration and communication, especially in a remote environment.
3. 6 to 12 Months:
As you enter the 6-12 month period, once you've gotten solid experience with the core technologies and features, start to broaden your scope. Expand your horizons by exploring adjacent areas, like picking up some backend skills if you've primarily worked on the front end.
Aim to become a more well-rounded developer with a wider understanding of the entire system. Take on increasing ownership and responsibility for projects and features. Continue to build your technical abilities while also honing your collaboration and leadership skills. Position yourself to take on larger, more complex initiatives as you move into your second year in the role.
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, your personal goals should be focused on thoroughly understanding the company's product and the problems it solves.
2. Next 3 Months:
As you move into the next 3 months, shift your focus to making tangible contributions to the product. Set a goal to develop and ship a significant feature, especially one that is considered a core part of the application.
3. 6 to 12 Months:
For the 6-12 month period, your goals should be more oriented around your overall growth as an engineer. In many startups, there is only one primary product or project. So rather than focusing on the number of projects you're involved in, aim to significantly level up your technical skills and expertise in your specific domain, whether that's frontend, backend, or full-stack development.
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?
Keeping your manager updated on what you're doing throughout the year is more important than what you discuss in just one meeting. During that meeting, focus on getting your manager on the same page about your goals and how you've reached them. If you've been keeping your manager in the loop all year, this meeting should be easy.
A good manager recognizes great work and helps developers grow. It's your responsibility to make your manager's job easier by keeping them informed about what you're accomplishing, how you're improving, and your overall progress.
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
My biggest motivation is my goal to start something of my own someday. With that in mind, I try to keep an eye out for opportunities to learn a bit about everything, whether it's design, product management, or new technologies. Continuously expanding my skillset across different areas is driven by my entrepreneurial aspirations.
2. Learning approach
I've found that the best approach is to dive right in and start a project using the new language or technology. Hands-on application is the most effective way for me to learn and retain new skills.
In terms of resources, I typically turn to YouTube tutorials when I'm learning a new language or framework. For understanding smaller concepts or specific topics, I find blog posts to be the most helpful.
I don't spend too much time taking detailed notes. Instead, I rely on directly applying what I'm learning to a project. I find that actively using the new skills helps me internalize them better than just writing notes.
In terms of whether I get to apply these skills? It depends on the specific skill. For example, I recently learned Express and Node.js, which happened to be used in my company's backend stack. So I got the opportunity to work with those technologies professionally.
However, there are certainly cases where the skills I pick up aren't directly applicable to my day job, either because they aren't part of the company's tech stack or because the nature of the work doesn't require them. In those situations, personal projects are my go-to avenue for hands-on practice and application.
I think it's important to recognize that while on-the-job challenges can be a great trigger for upskilling, they aren't the only avenue. Proactively starting personal projects to learn and apply new skills is incredibly valuable, even if they don't directly overlap with your work responsibilities. It broadens your overall competencies and keeps you adaptable in a fast-moving industry.
Qualities of 10x engineers
1. Technical traits
The standout engineers I've seen are truly passionate about engineering. They love what they do to the point where coding is their hobby. Even if they weren't getting paid, they would still be coding. That genuine passion and drive are the key differentiators for the best engineers.
2. Non-technical traits
To be honest, in my experience, many of the best engineers tend to be somewhat introverted. They aren't always the most socially adept or outgoing. This is a generalization and certainly not the case for everyone, but I've observed that the top engineers often focus more on the coding work itself rather than extensive interpersonal interactions. Again, this is just my personal observation and may not hold true universally.
I believe great engineers are proactive problem-solvers. They don't just complete assigned tasks but actively look for ways to improve processes, codebases, and products.
They have a keen eye for spotting inefficiencies or potential issues and take the initiative to address them.
Communication skills are also key, especially as you move into more senior roles. Being able to clearly articulate complex technical concepts, collaborate cross-functionally, and mentor junior team members are all important abilities.
Finally, I think the best engineers have a strong sense of ownership and accountability. They take pride in their work and feel responsible for the success of their projects and teams. They're willing to go above and beyond when needed.
What advice would you give someone to become a 10x engineer?
In my opinion, there are a few key points to becoming a great engineer. First, it's important to handle all edge cases and scenarios thoroughly. You should aim to build products that are robust and can scale well, even if the user base grows significantly overnight. The product shouldn't break down under increased load.
Secondly, as someone who aspires to start my own venture someday, I believe that being able to create a product that can achieve scale and maintain functionality under heavy usage is crucial. Focusing on scalability and reliability is a hallmark of great engineering.
You also have to figure out what kind of engineer you want to become.
Personally, I prefer to know more things rather than being an expert in only one area. While being a specialist is perfectly fine, I lean towards being a generalist.
The main reason for this is that I'm a very curious person by nature. I'm interested in understanding how great products are built from end to end, which involves many different aspects - frontend, backend, DevOps, cloud infrastructure, and more. I enjoy having a holistic view and being able to contribute across the stack.
I think there's a lot of value in being a T-shaped engineer, someone who has broad knowledge across multiple areas and can thrive in different project contexts. While they may not be the deepest expert in any single domain, they can adapt and contribute effectively to various parts of the system. That versatility and ability to connect the dots across the stack is something I find very appealing.
Negotiating salaries in Tech
First, I need to understand the current market conditions and typical salary ranges for the role and company. I can research this on sites like Glassdoor and by asking friends or connections in relevant communities.
Once I have a target compensation number in mind, the next step is pitching that number effectively to the hiring manager or potential manager. It's not just about knowing the market rate but being able to articulate why I deserve that level of compensation based on my skills and experience.
During the negotiation, I need to highlight my key strengths and qualifications that are relevant to the role. For example, if I'm interviewing for a front-end role but also have some back-end experience, I would mention that as added value.
It's also important to understand the components that make up the total compensation, like base salary, bonuses, equity, and benefits. I want to ensure I'm evaluating the full package, not just the base pay.
Assessing Job Offers: Beyond Salary
How do you assess multiple job offers beyond just the CTC?
There are some key factors I would consider:
1. I would consider the company itself - whether it is a dedicated tech company or not. Working for a company where technology is the core product and focus would be preferable.
2. The tech stack and languages/frameworks being used are also important factors. I want to ensure I'll be working with modern, in-demand technologies rather than outdated or niche stacks with limited applicability.
3. The team composition and culture fit are key considerations as well. I would try to get a sense of who would be my potential manager and coworkers. Having talented peers to learn from and a manager I gel with is crucial for growth and enjoyment. The overall engineering culture and values are also important factors that can make or break the experience.
4. Work arrangement preferences like remote, hybrid, or in-office would factor into my decision too. As an engineer, I prefer full remote roles for flexibility and time savings over commuting. However, I'm also open to hybrid models with some in-office time if the other factors are compelling enough.
5. The specific role responsibilities, opportunities for professional development, and pathways for career advancement at the company would be other major considerations beyond just compensation. I want an engaging role with the ability to continually learn and take on increasing scope over time.
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 core factors I would consider are largely the same - the company culture/values, tech stack, role responsibilities, professional growth opportunities, work arrangement flexibility, compensation package, etc. However, there are some nuances when weighing an internal promotion versus an outside offer.
With an internal promotion, I would evaluate if it represents a true leveling up of my role and responsibilities. Sometimes promotions just come with a title change but the day-to-day work remains fairly similar. An ideal promotion would allow me to take on leadership over a new project or initiative, manage a team, and expand my scope significantly. If it's just a minor bump in the title without meaningful new challenges, an external role may be more appealing for accelerated growth.
That said, there are advantages to an internal promotion as well. I'm already familiar with the company culture, onboarding is seamless, and there's a level of trust already established with stakeholders. The risks are lower than joining a completely new company.
The specifics of the compensation packages would be closely evaluated, looking at base pay, equity, bonuses, benefits, etc. An external offer may come with a higher base salary to incentivize the job switch.
Ultimately, at this stage of my career, growth opportunities would likely take precedence over pure compensation in my decision criteria. I want to be exposed to new technologies and stretch roles continually. If the internal promotion checks those boxes, I may lean towards staying. But an undeniably better tech stack, scope, and trajectory at an external company could sway me as well.
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?
Even after just two years in the industry, I've experienced periods of burnout and feeling drained. For me, the key signs are getting easily irritated at work, constantly feeling stressed, and having no motivation to be productive.
While burnout can happen, it's usually a temporary phase rather than a prolonged state. I try to maintain a solid work-life balance to avoid and recover from burnout. Having hobbies and activities completely separate from work is crucial - for me that's exercising and going to the gym regularly. Taking real breaks to unwind and recharge by disconnecting from work helps immensely.
During periods of burnout, while still on the job, it can help to have open conversations with my manager. Explaining that I'm feeling drained and asking for a shift to different tasks or projects that I may find more engaging and motivating can provide a mental reset. Managers are usually understanding about temporary burnout.
In addition to taking real time off, I'm also open to the possibility of taking extended career breaks in the future if needed to recharge fully.
Preventing prolonged burnout is important for sustainable productivity and personal well-being over the long run.
Overall, being self-aware about the symptoms of looming burnout, and being proactive about addressing it through a balance of hobbies, breaks, communication, and perspective shifts when needed is key. Burnout is normal, but letting it linger unaddressed can be unhealthy.
-
Sudhanshu's Linkedin
