Introduction
Hi Anmol, would love to know a bit about your professional background.
Hi, I’m Anmol! I started my career right after graduating with my B.Tech from VIT Vellore. I got a campus placement at Infosys, and at that time I had some experience with the computer field. However, my primary focus was on mechanical engineering, not computer science. It was a bit of a surprise when I ended up working with mainframe technology at Infosys, which is a very old technology dating back to the 1960s. I had to deal with code that was written decades ago. That's when I realized that if I wanted to progress in the computer science field, I would need to gain more relevant skills and knowledge.
So in my spare time, I started learning web technologies like HTML, CSS, and JavaScript on my own. Gradually, I was able to build up enough knowledge to interview for a project within Infosys, and I was lucky enough to get it. At that point, I wanted to get into backend work, but I ended up in a React.js project instead. I didn't have much knowledge of React at the time, and it was quite daunting. However, I spent a lot of time learning the codebase and React itself after work. There's a lot of peripheral technology that you have to learn to really understand how everything works. I spent a couple of years working on that project at Infosys.
Currently, I work at EPAM as part of their EPAM Anywhere initiative, which allows me to work remotely with different clients on their front-end stack. I also have some experience with backend technologies that I get to work on when I can. It's been an interesting journey so far, constantly learning and expanding my skills.
Day in the life of a software engineer
What does a typical day look like for you as a software engineer?
A typical day for me usually starts with a daily standup call, which is a consistent part of my schedule for about 5 days a week, around 9:30 am. After the standup, the flow of my day depends on where we are in the current sprint cycle.
At the beginning of a new sprint, which is usually on Mondays, we have a sprint planning call. This is where we decide how many story points each developer will be taking on, and what features we'll be working on over the next two weeks. The product team also joins these meetings to specify the features, write the user stories, and discuss any edge cases with the engineering team and QA and this goes on for the entire day.
How much time do you spend coding vs in meetings?
In terms of the split between coding and meetings, I'd say it's roughly 60/40 these days. When I was a junior engineer, I spent the majority of my time hands-on with the codebase. But as I've grown into a more senior role, I do find myself spending more time in a leadership capacity - explaining tasks to junior developers, aligning the team, and so on. However, I still very much enjoy the coding aspect and try to maximize my time spent there.
What’s your mantra to get quality work done daily?
Throughout the sprint, I try to dedicate the mornings to writing code, as I find my brain works better in the morning for that kind of focused work. In the afternoons, I'm more open to meetings and discussions. This could include product grooming sessions, where we dive deeper into the upcoming features, or meetings to sync up with other team members.
Towards the end of the sprint, we also have a retrospective meeting to discuss what went well, what could be improved, and any learnings from the past two weeks.
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.
.jpg/)
1. Hardware Setup
I prefer to keep my setup fairly mobile. While I do have a designated workstation, I like to have the flexibility to work from different rooms or locations. So I primarily use a laptop, which my current company, EPAM, has provided me - an HP Evo with 32GB of RAM and an Intel i7 processor.
I find that a laptop works well for me, even though most software developers I know would happily take an extended monitor setup if given the option. I do have a separate keyboard and mouse that I use sometimes, but I don't find myself needing them all the time.
2. Software
A. Go-to browser
I use both Microsoft Edge and Chrome.
B. Core work and coding tools
Visual Studio Code is my go-to code editor. I find it provides a great overview of the codebase and has helpful extensions that make my day-to-day coding much smoother. Git is an essential part of my toolset as well, for managing version control.
I also use Docker occasionally, Postman for API testing, and MongoDB Atlas as a GUI for visualizing my database. For documentation and note-taking, I rely on Notion.
C. Favorite programming language
I'd say JavaScript is my bread and butter these days. As a front-end-focused engineer, I've become very comfortable and proficient with JavaScript, including frameworks like React. However, I try to stay adaptable - for data analysis projects, I would likely reach for Python or R instead.
Overall, while I have my preferred tools and languages, I try to stay flexible and use the right technology for the job at hand. Maintaining a mobile, adaptable setup helps me work efficiently across different client projects and requirements.
Big Companies vs Startups
I noticed you've worked in both big companies (Infosys) and startups (Give). Firstly, can you tell me your preference between the two?
In the current market situation, with a lot of turmoil in the industry, I would prefer to work in big companies rather than startups. However, when I was in college, I was hoping to get into a startup because, in the early years of your career, it's better to join a startup to gain valuable experience and kickstart your career.
At a startup, you get good growth opportunities, learning experiences, and the chance to see how a product is developed from scratch. If I were still in college, I would go for a startup, but at this point in my career, I would prefer working for big companies.
How would you compare startups with big companies?
Both large companies and startups have their own advantages. At a place like Infosys, which is a much bigger organization, there are more established processes, tooling, and support systems in place. The infrastructure is more robust and there can be more stability and resources available. On the other hand, at smaller startups, the team sizes are tighter-knit and there's often more flexibility and nimbleness in how you can approach problems. You get to wear more hats and have a bigger impact on the overall direction of the product or project.
Personally, I've found that I thrive a bit more in a startup-like environment where I can take more ownership and have a more direct influence. The faster pace and the need to be adaptable keep me engaged. But I can certainly appreciate the benefits of the enterprise-level resources and processes as well. I'd also be very honest that the amount of learning can sometimes vary quite a bit between companies. At Infosys, I did gain a lot of valuable experience, but I find I'm able to learn even more at places like the startup I worked at previously, or my current company EPAM, which is another large organization.
At startups, you tend to have more control over the technology stack you use, and there's often less red tape or security restrictions to work around. However, the bigger companies do have the advantage of exposure to industry best practices from very experienced professionals.
In the end, I think it comes down to individual preference and what motivates you most as an engineer. Both large companies and startups have their merits, and I've enjoyed the unique experiences I've had at each type of organization.
What are the key qualities of someone who would be a perfect fit for a startup versus big tech?
In my experience, I believe the ideal environment for a software engineer can vary quite a bit depending on the stage of their career.
For developers who are early in their careers, I would generally recommend starting at a startup if possible. The fast-paced, hands-on nature of a startup environment can be incredibly beneficial in the early stages. You get to take on more responsibility, wear multiple hats, and learn a wide range of skills very quickly.
The downsides of potentially facing layoffs or instability at a startup are usually outweighed by the valuable experience you can gain. Getting comfortable with that kind of fast-paced, adaptable mindset early on can really set you up well for the rest of your career.
On the other hand, for developers who are later in their careers and looking for more stability, larger established companies tend to be a better fit. These organizations often have more robust processes, resources, and support systems in place. The work may be a bit more siloed, but you can focus on honing your expertise within a specific domain.
Experienced engineers may also be drawn to the reputation and industry best practices you can learn from the seasoned professionals at a big tech company. The tradeoff is potentially less autonomy and a slower pace of work compared to a startup.
Ultimately, I think it comes down to the individual developer's preferences and the stage they're at in their career.
Both startup and enterprise environments have their advantages, and many engineers can thrive in either setting if they have the right mindset and skills.
But for those just starting out, I would generally recommend the startup route to get that crucial early-career experience.
Navigating a New Tech Role
1. First month
→ For a new grad/junior engineer, the onboarding process may be faster at a startup vs a larger company. Larger companies often have more compliance and formalities to go through.
→ Spend time getting familiar with the company's internal tools, communication channels, and key people/mentors. Don't be afraid to ask questions.
→ As an experienced engineer switching companies, you'll still need to "hit the reset button" - understand the codebase structure, testing practices, compliance requirements, etc.
2. Next 3 months
→ Adjust to the speed and culture of the company, whether it's a fast-paced startup or a more established enterprise.
→ As a junior, soak up as much guidance and knowledge from your more experienced colleagues as possible. This can be a "make or break" period.
→ Don't expect to become a master of the codebase overnight. It takes time to really understand the nuances.
3. 6-12 months
→ Continue diving deeper into the codebase and identifying areas to improve or take on more responsibility.
→ For juniors, those "superpower" abilities of quickly identifying issues or optimizations will come with experience over time.
→ If things feel too monotonous, don't be afraid to speak up and express interest in branching out into new areas.
→ For seniors, you'll likely reach a point of mastery over the first year, but continue looking for ways to further optimize processes or try new approaches.
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
By the end of the first month, having a solid grasp of the company's business and strong working relationships with your peers should be the key KPIs.
2. The next 3 months
Over the following 3 months, the focus should shift more towards making smaller, incremental contributions and suggestions based on your growing understanding of the codebase and team dynamics.
You can start providing feedback on potential improvements, whether that's related to technical implementation, processes, or other areas.
The goal here is to demonstrate your ability to not just understand the existing system, but also identify opportunities for enhancement. Actively seeking feedback from your team and continuously working towards better alignment with the company's requirements should be the KPIs during this phase.
3. 6-12 months
In the latter half of the first year, the objective should be to truly establish yourself as a valuable addition to the team and the organization as a whole. This means going beyond simply meeting expectations - you should be proactively providing insightful technological suggestions and solutions that could meaningfully benefit the company.
Leverage your now comprehensive understanding of the codebase, tooling, and processes to identify areas for improvement and pitch ideas that showcase your technical expertise and strategic thinking.
Continuously seeking feedback and demonstrating a mindset of continuous improvement should be the KPIs at this stage, as you work towards becoming a trusted, impactful member of the team.
At the end of someone’s first year, what should their pitch to the manager be to ensure a successful appraisal, considering the KPIs you've mentioned?
1. Continuously align on goals
- At the start of the year, have an open discussion with your manager to align your yearly goals and priorities. Don't just set them in stone and forget about them.
- Proactively check in with your manager every 2-3 months to get feedback on your progress. Understand if you're meeting, exceeding, or falling short of expectations.
- Use these check-ins to strike the right balance between your priorities and the company/manager's requirements. Stay adaptable as things evolve.
2. Gather feedback from multiple sources
- Don't just rely on feedback from your direct manager. Also, seek input from your team leads, senior colleagues, and even your peers.
- Getting a well-rounded perspective on your performance and contributions throughout the year will strengthen your case during the final review.
3. Communicate key accomplishments
- When it comes time for the year-end review, be prepared to clearly articulate your major contributions and impact over the past 12 months.
- Quantify your achievements where possible, and tie them back to how they benefited the team, project, or overall business.
- Emphasize areas where you exceeded expectations or took on additional responsibilities beyond your core role.
Upskilling in Tech
So you’ve been in the industry for over 6 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?
For me, my long-term goal has always been to become a software architect or principal architect as I progress in my career. That has been the primary driver behind the time I spend upskilling, whether it's on weekends, holidays, or after work hours.
I try to stay as updated as possible on the latest front-end frameworks, back-end technologies, DevOps tools, and emerging areas like AI and web3. I leverage resources like YouTube, Medium, and Twitter to keep my finger on the pulse of industry trends.
However, I'm very selective and deliberate about where I focus my learning efforts. While technologies like AI and web3 are certainly exciting, my priority is to first solidify my core software architecture skills. I believe having a strong foundational understanding of the full stack, from front-end to back-end, is crucial before diving into more specialized or complex domains.
The way I see it, being a "jack of all trades" in software engineering, with depth in key areas, will serve me better in achieving my goal of becoming an architectural leader. Rather than spreading myself thin, I'm focused on selectively enhancing my expertise to support my long-term career aspirations.
Of course, I do keep an eye on emerging trends and make sure I'm aware of their potential impact. But I'm quite intentional about aligning my upskilling with my overarching objectives. It's a more targeted approach compared to earlier in my career when I was simply trying to soak up as much knowledge as possible across the board.
Qualities of 10x engineers
1. Non-technical
A) Resilience and perseverance
I've learned that having an attitude of not giving up is crucial. In my experience as a senior dev, I've faced numerous challenges, like projects failing to launch, products not gaining traction, or falling short of benchmarks. The key is to stay motivated and not let these setbacks discourage you.
B) Openness to feedback
I've noticed that some devs get disheartened when they compare themselves to their peers or seniors. However, I believe that being open to feedback from everyone, regardless of their level, is essential. There's always an opportunity to learn from others, so I keep an open mind.
C) Perceptiveness
The best engineers I've collaborated with are highly perceptive. They're always ready to absorb information from various sources and people. This helps them stay informed and adapt to new situations effectively.
2. Technical
A) In-depth knowledge of tools
This goes without saying but great engineers have a deep understanding of their tools. This foundational knowledge is invaluable.
B) Focus on principles
While new technologies and frameworks emerge regularly, the underlying principles often remain the same. Great engineers choose to focus on these principles, I think that’s why it’s easy for them to stay adaptable in this chaotic industry.
C) Problem-solving skills
At the end of the day, our job is to solve real-world problems.
Great engineers approach challenges with an open mind and avoid getting too attached to any particular tech stack.
Instead, they focus on understanding the key features and trade-offs of different technologies to find the best solution for the product.
What advice would you give engineers to become 10x engineers?
Don't shy away from difficult projects or tasks. Embrace them as opportunities to learn and grow. When you face setbacks, use them as a chance to reassess, adapt, and come back stronger. Actively seek feedback from your colleagues, regardless of their level. Find mentors who can guide you and provide insights based on their experiences. Be open to constructive criticism and use it to improve your skills.
Stay curious and keep learning. Explore new technologies, attend workshops, and participate in hackathons. But remember, don't just focus on the latest trends; make sure you understand the fundamental principles behind them.
Great engineers are not just technically proficient; they also work well with others. Collaborate with your team members, share your knowledge, and learn from their experiences. Communicate clearly and effectively to ensure everyone is on the same page. Take ownership of your work and strive for excellence.
Don't just focus on completing tasks; think about how your contributions impact the overall product and the end-users.
Go the extra mile to ensure the quality and reliability of your work.
Do you think every engineer on a team can be a 'great' engineer?
Well, yeah, that is possible. I mean, if the team is well-aligned, I would say they will grow very progressively and inclusively together. It really depends on the leader as well as the team itself. Both of them need to be perceptive and keep the communication open on both sides.
A team of great engineers can happen, but I haven't actually seen it happen though. More often, there tends to be a mix of varying skill levels and mindsets within a typical engineering team. The ideal scenario would be having an entire team of elite, "10x" caliber engineers. But that's not necessarily a realistic expectation. The more common reality is having a range of experience and capabilities on the team.
The focus then needs to be on fostering an environment conducive to collective growth and mutual learning. The team leader plays a critical role in facilitating that kind of collaborative culture where everyone can progress together.
Negotiating salaries in Tech
The first step is to do thorough research using resources like Glassdoor and Ambitionbox. These can provide a good ballpark idea of the salary range for a particular role and seniority level at different companies, especially startups. I also try to understand the funding stage and trajectory of the company, as that gives valuable context.
For lower salary ranges, say below 10 lakhs, it's often easier to negotiate a higher percentage increase. However, once you get into the 20-25 lakh range and above, the percentage hike tends to be smaller. That's where the specific skills, experience, and value I can bring to the company become more important factors.
One key thing I always consider is the overall compensation package, not just the base salary. For startups especially, equity components like ESOPs can be a significant part of the offer. So I try to understand the company's potential trajectory and growth plans to evaluate the true worth of those equity-based benefits.
The leverage I have in the negotiation also depends a lot on whether I'm the one more eager for the role, or if the company is really keen to hire me. When I have multiple offers on the table, I'm in a much stronger position to negotiate aggressively. Whereas if the company holds more bargaining power, my ability to influence the compensation gets diminished.
So I try not to get fixated on a single salary number. I do comprehensive research, consider the full compensation package, and leverage my position strategically. Maintaining this nuanced, big-picture perspective helps me navigate these tricky salary negotiations more effectively.
Assessing Job Offers: Beyond Salary
How do you assess multiple job offers beyond just the CTC?
The first thing I would look at is the nature of the role itself. Is it going to challenge me and provide opportunities for growth, or is it a more monotonous position than I've had before? Even if one offer has a higher salary, I would be more inclined to go for the role that pushes me out of my comfort zone and promises more professional development.
As a senior engineer, I've learned that money isn't everything.
If I can make do with a slightly lower salary, but the growth prospects in the company are excellent, I would likely prioritize that over a higher-paying but stagnant role.
This is especially true for early-career engineers - taking a lower-salary job with strong growth potential is often better than a higher-paying position with limited upside.
Another important factor I consider is the overall benefits and perks package, not just the base compensation. If the salaries are fairly comparable between the two offers, I'll dive into the details of the other benefits like healthcare, retirement contributions, vacation time, and so on. These supplementary elements can make a meaningful difference in the total value proposition.
In the end, it's about finding the right balance between compensation, growth opportunities, and overall job fit and satisfaction. The goal is to optimize for long-term career progression, not just chase the highest immediate paycheck.
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?
First and foremost, I look at the nature of the role itself - is it going to provide meaningful growth opportunities and challenge me in new ways? Even if the new job offer has higher compensation, I'm more inclined to go for the role that pushes me out of my comfort zone and promises more professional development.
That said, I also recognize that the comfort and familiarity of my current company can be a strong pull, especially for high-performing engineers like myself. The hassle of starting over at a new organization, and building new relationships from scratch, can be a deterrent - even if the market reality is that the highest pay increases typically come from changing employers rather than internal promotions.
Beyond just the financial aspects, the work environment is a crucial consideration for me. I do extensive research on the culture, values, and day-to-day experiences at any prospective new employer. Ensuring a good fit in that regard can be just as important as compensation.
Ultimately, it comes down to striking the right balance. I weigh the potential upsides of a new role, environment, and career growth against the comfort and stability of my current position. There's no one-size-fits-all answer, as it's highly dependent on my specific situation and priorities at that point in time.
The key is to avoid getting overly fixated on any single factor, like just chasing the highest salary. I try to take a holistic view, evaluating the full package of what each option has to offer in terms of professional development, job satisfaction, and long-term career growth.
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?
Actually, earlier in my career, I went through periods of burnout, where the monotony and demands of the work started taking a toll on me. This happened around the year-and-a-half to two-year mark in my initial roles. During that time, I even put on a lot of weight because I was spending so much time worrying about or doing work, and not prioritizing my health.
I've learned that as you gain more experience, it does become easier to grasp things faster and more efficiently. But when you're starting out, there's just a lot to figure out, which can make it easier to get burned out.
The key is to establish clear boundaries and make sure to carve out time for yourself, even if the workload feels overwhelming. Taking time off, whether it's a few hours, a day, or longer, is essential to recharge and maintain your well-being.
I realize now that in the long run - I plan to be working for at least another couple of decades - prioritizing my health has to come first. So I make sure to have open conversations with my colleagues and managers about their expectations and try to find a middle ground where I can strike a healthy balance.
It's easy to get totally immersed in the work, which is great in moderation but can become unhealthy if it's 24/7. I've had to learn to be more mindful about taking breaks, eating well, exercising, and protecting my personal time. Otherwise, the burnout creeps back in.
Maintaining that balance is an ongoing process, and it looks different for everyone. But the key is to not be afraid to set boundaries, communicate your needs, and ultimately put your physical and mental health first. That way, you can remain engaged and productive in the long haul.
