Introduction
Hi Yash, would love to know a bit about your professional background.
Hey, I'm Yash, a software engineer with experience at JP Morgan and startups like Nanonets. I thrive in fast-paced environments, working with the MERN stack, Java, Python, and AWS.
Day in the life of a software engineer
What does a typical day look like for you as a software engineer?
I usually start my day by looking at my calendar and reviewing the different meetings I have planned for the day. Most of these are product team meetings or tech-related collaborations.
We use these meetings to discuss the things we're currently working on, as well as plan out the work for the next few weeks or months - things like our quarterly goals and objectives.
So the day begins with getting an overview of what's on the agenda and what needs my focus. Apart from the day-to-day tasks, I also need to be aware of any special things happening that day that might require me to pause my current work.
After the initial meetings, I try to get some dedicated time to work on the longer-term projects and tasks. This involves coding, testing, and other hands-on technical work. The afternoons are usually spent connecting with our clients, many of whom are based in India. We use this time to get new requirements, resolve any issues, and generally sync up on the work.
So in summary, my days tend to be a mix of internal meetings, technical work, and client interactions. It's a balance of planning, collaborating, and executing the engineering tasks at hand.
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
At our company, we primarily use Apple MacBook laptops for our day-to-day work and meetings. Our display setups are a mix of Samsung and Apple monitors.
2. Software
A. Go-to browser
I've recently switched from using the Brave browser to trying out the new Rogue browser. I was previously a Chrome user, but I'm finding Rogue to be a promising alternative these days.
B. Core work and coding tools
In terms of the actual tech stack, the majority of our work (around 80%) involves the MERN stack - that's React and Angular on the front end, along with Java, Python, and a bit of Kotlin on the back end. We use these technologies for most of our web development projects.
For our machine learning and AI-related work, Python is the go-to language. We also leverage Google Cloud Platform (GCP) to some degree, but the majority of our infrastructure is hosted on AWS.
Overall, we have a pretty robust and versatile tech stack that allows us to tackle a wide range of software engineering challenges for our clients.
Big Tech vs Startups
I noticed you've worked in both big companies (JP Morgan) and startups (Nanonets). Firstly, can you tell me your preference between the two?
Without a doubt, I much prefer the startup environment these days. When I was at JP Morgan, I found the teams to be quite slow-moving, and there weren't as many opportunities for professional and technical growth.
That's why I decided to make the switch to a startup. I joined when the team was just 15 people, and I've witnessed it grow to over 200 now. It's been an incredibly rewarding journey.
How would you compare startups with big companies?
The key difference is the sense of freedom and ability to drive impact at a startup. In a larger company, there are often a lot of processes and red tape you have to go through just to get something implemented or try out new ideas. But at a startup, you're much more focused on just solving problems.
There's also a lot more work to be done, which means longer hours. But for me personally, that trade-off is worth it to have the autonomy and ability to directly influence the product and the company's direction.
I can see myself happily working at a startup for the next 10-15 years. The fast pace, lack of bureaucracy, and opportunity to truly own projects are what I find most appealing as a software engineer.
Navigating a New Tech Role
1. First month
The key focus in the first month should be to deeply understand the user base and the problem you're trying to solve. Don't just jump into the codebase or get bogged down in technical details right away.
Spend time learning about your users - who they are, their pain points, and how they currently use the product.
This user-centric mindset will be crucial as you start building and iterating. Also, use this time to get familiar with the overall codebase, architecture, and tech stack, but don't worry about mastering everything yet.
2. Next 3 months
Now that you have a solid grasp of the user needs, start getting your hands dirty with the technical work. Identify areas where you can make an impact, whether it's improving existing features, fixing bugs, or building new functionality. Focus on shipping incremental improvements rather than big, complex projects. Demonstrate your ability to independently deliver value. Additionally, continue learning the codebase in-depth and build relationships with your new teammates.
3. 6-12 months
In this longer timeframe, you can start taking on more ambitious projects and initiatives. Leverage your user understanding and technical expertise to propose new ideas and drive the product roadmap. Look for opportunities to mentor junior engineers and share your knowledge. Additionally, diversify your skill set - explore adjacent technologies, participate in hackathons, or take on cross-functional work. This will make you a more well-rounded and valuable engineer in the long run.
The common thread across all these stages is maintaining a strong user focus. An engineer who deeply understands their customers and builds with their needs in mind will be far more effective than one who is purely technically-minded. Keep this principle at the forefront as you navigate the first year in your new tech 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
First Month:
→ Develop a deep understanding of the codebase, architecture, and tech stack
→ Gain clarity on the business model, user base, and the core problem the product is solving
→ Build relationships with team members and key stakeholders
→ Identify quick win opportunities to contribute, even if small
2. The next 3 months
→ Identify and propose opportunities to improve existing features or optimize the codebase
→ Deliver high-quality code and demonstrate the ability to work independently
→ Continuously learn and expand your technical skills relevant to the project
→ Start participating in discussions around the product roadmap and new feature ideas
3. 6-12 months
→ Own the development of at least 1-2 major new features or functionality
→ Proactively identify ways to improve engineering practices, processes, or tooling
→ Mentor junior engineers and share your knowledge with the team
→ Explore adjacent technologies or take on cross-functional initiatives to diversify your skillset
The key themes across these phases are:
1) Understand the business and users first, before diving into the technical work.
2) Demonstrate your ability to independently deliver value, even in small ways initially.
3) Continuously learn, expand your impact, and become a more well-rounded engineer.
4) Contribute to the product vision and roadmap, not just the implementation.
By focusing on these areas, you'll be able to make a strong impact in your first year and set yourself up for long-term growth and advancement in the company.
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?
Well, as a senior engineer, I feel there are a few key things to focus on during this year-end review process. First and foremost, it's important to be transparent about the performance and achievements of your team. After all, you are responsible for their growth and development, not just your own.
I always make sure to highlight the wins and contributions of my team members - who have been excelling, and who might need additional support or opportunities to improve. Showing that level of ownership and insight into your team's progress goes a long way.
Beyond that, you'll want to communicate your own growth goals and aspirations. Are you looking to take on more management responsibilities and lead a larger team? Or do you feel the need to step back and dedicate more time to honing your technical skills? Express those preferences clearly.
And as a technical leader, it's crucial to demonstrate your awareness of the broader industry landscape. Show that you're staying ahead of emerging technologies and trends and that you can identify strategic architectural challenges the business may face down the line. This helps position you as a true strategic partner, not just a hands-on coder.
The key is to strike the right balance - highlighting your team's wins, outlining your own development goals, and showcasing your visionary, big-picture thinking.
This well-rounded approach will allow your manager to fully appreciate the impact you've had over the past year, and where you can continue driving value in the future.
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
As a software engineer, my motivation for continuously upskilling and learning new technologies is primarily driven by the problems I encounter in my work. When I come across a challenge that seems difficult to solve with my current skill set, that's when I get the urge to expand my knowledge.
Many times, I'll see other engineers or teams doing something that appears to be a "black box" - I don't understand how they're able to implement it. But when I dive deeper and learn the underlying principles and techniques, I realize it's actually quite straightforward. There were just a few key pieces of knowledge that I needed to acquire.
Fundamentally, my motivation stems from the fact that in software, everything has been built by someone. So the more I can grasp and understand the technical landscape, the better equipped I'll be to solve the problems in front of me. This continuous growth of knowledge is essential for my own development as an engineer
2. Learning Approach
When it comes to actually learning a new skill or technology, I try to take a very hands-on, implementation-focused approach. Rather than just reading articles or documentation, I look for opportunities to directly apply the new knowledge.
For example, if a cloud provider like AWS launches a new service, I first assess whether it could be beneficial to implement within my team or company. If so, I propose taking ownership of that implementation. This ensures I don't just passively learn the theory, but get deep into the practical nuances of how to use the technology.
I find that this approach of "learn by doing" is much more effective than pure reading or studying. When I have a concrete problem to solve using a new skill, I'm forced to really understand it inside out. And the bonus is that I'm also delivering value to the business in the process.
Of course, there are limits to this approach - I can't always implement every new technology that emerges. However, I try to strike a balance, focusing my hands-on learning on the tools and techniques that I believe will be most relevant and impactful for my work.
Qualities of 10x engineers
Based on my observations, the qualities that really set apart great engineers go beyond just their technical prowess. While strong technical skills are certainly important, truly exceptional engineers also exhibit a deep understanding of the business and user needs.
One key quality I've noticed is their willingness to push back and challenge requests, rather than simply executing blindly.
A great engineer will analyze a new feature request and consider questions like - who exactly will benefit from this? What percentage of our user base is it really serving? Is there a better way to achieve the underlying objective?
This ability to think critically about the business impact, and not just the technical implementation, is crucial.
Great engineers don't just build products - they think strategically about the long-term effects on the company and its customers.
Another distinguishing factor is their proactive nature. Rather than waiting for features to be handed down, they're constantly seeking opportunities to identify new solutions or open up untapped potential. They're not afraid to bring bold ideas to the table, backed by a thorough understanding of the users and the product roadmap.
What advice would you give someone to become a 10x engineer?
For engineers aspiring to reach this level of excellence, my advice would be to continuously broaden your perspective beyond just the coding and technical work.
Invest time in deeply understanding your users - who they are, what their pain points are, and how they're currently using the product. This user-centric mindset will help you make more impactful decisions when it comes to feature prioritization and product development.
Additionally, make an effort to understand the business strategy and objectives. Don't just focus on the mechanics of building features - understand the commercial reasoning behind them. This big-picture view will allow you to think more entrepreneurially and identify opportunities that could truly move the needle.
And importantly, be willing to push back when necessary. Don't be afraid to challenge requests or ideas if you genuinely believe there's a better way forward. Develop the confidence to voice your perspective and champion solutions that may not be the obvious choice.
By blending strong technical abilities with a strategic, user-focused mindset, you can truly elevate yourself to the level of a "great" engineer - one who not only implements brilliantly but shapes the product and business in meaningful ways.
Negotiating salaries in Tech
When it comes to negotiating tech salaries, the key is to approach it with a strong understanding of the market and what you truly deserve, while also maintaining a balanced and pragmatic mindset.
First and foremost, it's crucial to do your research. Connect with peers in your network, join developer communities, and leverage anonymous platforms like Blind or Grapevine to get a sense of the current compensation ranges for roles and experience levels similar to yours. Understand the variables at play - things like location, technical stack, and years of experience can all significantly impact the market rate.
Armed with this market knowledge, you'll be in a much stronger position to advocate for a fair salary that aligns with your abilities and the value you can bring to the organization. Don't just accept the first offer - be prepared to push back constructively if it falls short of your research-backed expectations.
At the same time, it's important not to approach salary negotiations in an overly aggressive or unrealistic manner.
The goal should be to find a mutually beneficial arrangement, not to simply extract the maximum possible compensation.
Consider factors like the company's financial situation, growth potential, and ability to meet your needs.
I was particularly struck by an insightful approach taken by one founder I interviewed. Rather than getting into a back-and-forth negotiation, he simply asked me, "What number would allow you to not have to worry about money and just focus on doing great work for us?" This shifted the conversation away from a combative stance and towards finding a compensation level that would enable me to be truly engaged and productive.
Ultimately, the key is to balance your awareness of market rates with an understanding of the broader context. If you can demonstrate your value and articulate a fair salary ask grounded in research, while also showing flexibility and a collaborative spirit, you'll be much more likely to land in a compensation sweet spot that works for both you and the employer.
Assessing Job Offers: Beyond Salary
How do you assess multiple job offers beyond just the CTC?
You raise an excellent point - when faced with two job offers with similar compensation, there are several other key factors I would consider in making my decision:
1. Tech Stack and Engineering Culture
→ I'm very interested in the specific technologies and tools the engineering team is using. Is it a stack I'm excited to work with and continue developing my skills in?
→ Just as importantly, I'd want to get a sense of the overall engineering culture - the level of autonomy and freedom developers have, the collaborative dynamic, the approach to problem-solving, etc. A healthy, empowering culture is crucial for my personal growth.
2. Work Arrangements and Flexibility
→ As you mentioned, the balance between remote and in-office work is an important consideration for me these days. While I do value the learning opportunities that come from in-person interactions, I also appreciate the benefits of remote or hybrid models.
→ Beyond just the remote/office split, I'd also look at the overall flexibility the company offers - things like flexible scheduling, generous PTO, etc. The ability to maintain a healthy work-life balance is a key priority.
3. Growth Opportunities and Challenges
→ I'm very motivated by the prospect of tackling new, complex problems and continually expanding my technical capabilities. So I'd carefully assess the types of projects and challenges I'd be able to take on in each role.
→ Additionally, I'd want to understand the potential growth trajectory - are there clear pathways for advancement and increased responsibilities over time? The opportunity for professional development is crucial.
4. Mission, Values, and Impact
→ While compensation is certainly important, I'm also highly motivated by the ability to work on something meaningful and impactful. So I'd closely evaluate the company's mission, values, and the real-world problems they're trying to solve.
→ Knowing that my work is contributing to the greater good and aligns with my own principles is a key factor in my decision-making.
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?
Some factors I would consider in this situation are:
1. Financial Considerations:
→ If the external offer provided significantly higher total compensation, that would be a stronger pull factor, even if I was satisfied with the promotion at my current company.
→ However, as you noted, if the pay increase with the promotion was adequate and met my financial needs, that could outweigh the allure of a higher-paying external role.
2. Growth and Learning Opportunities:
→ The ability to continue growing, learning new skills, and tackling fresh challenges is very important to me. If the promotion offered genuine avenues for professional development, that would be a major advantage.
→ Conversely, if the external role presented more stimulating work and the chance to expand my expertise in new areas, that could make it the more attractive option.
3. Organizational Factors:
→ My comfort level, relationships, and reputation within my current company is valuable. The "known quantity" of staying put has some inherent benefits.
→ However, the opportunity to join a new environment, with a different culture and set of dynamics, can also be appealing for professional growth.
Overall, I think it would come down to carefully weighing the specific details and long-term potential of each option. If the promotion provided strong compensation, compelling growth prospects, and an environment I was genuinely excited about, I would likely lean towards staying. However, a truly transformative external offer with exceptional learning opportunities could still sway me to make the jump, despite the comfort of my current role.
The decision would require a holistic assessment, considering both the tangible factors as well as the more intangible elements of cultural fit and professional fulfillment. There's no one-size-fits-all answer, but a thoughtful, balanced evaluation of the alternatives is key.
Navigating Layoffs
The past year has been tough for engineers facing layoffs. Did anyone in your circle get laid off in the last year?
While I haven't had any immediate colleagues or close friends directly affected, I know the last year has been quite challenging for many in the industry. The layoffs have been widespread and have certainly caused a lot of uncertainty and stress for engineers.
What do you think can be a good job search strategy for engineers going through a layoff right now?
In times like these, I believe the best strategy is to focus your efforts on smaller, high-growth startups rather than larger, more established companies.
The bigger tech firms are often facing more financial pressure and are understandably more hesitant to bring on new headcount. Smaller startups, on the other hand, are likely still hungry for talented engineers to help them tackle their ambitious goals and continue scaling.
The key is to be proactive in reaching out to these smaller companies. Don't wait for them to post job listings - instead, research the startups operating in spaces that excite you, and then personalize your outreach to the founders or engineering leaders. Demonstrate your genuine passion for their mission and the problems they're trying to solve.
While the hiring processes at smaller firms may not be as robust or defined as larger enterprises, that can actually work to your advantage. Showcase your eagerness, resilience, and adaptability - qualities that are highly valued by scrappier, fast-moving organizations.
Additionally, be prepared to highlight not just your technical chops, but also your broader business acumen and strategic thinking.
Startups often need engineers who can wear multiple hats and contribute beyond just the code.
It may take some persistence, but I believe this direct, tailored approach to pursuing opportunities at high-potential startups is one of the best paths forward in the current market climate. The chance to get in early, wear multiple hats, and truly shape the direction of the business can be incredibly rewarding.
The most important thing is to maintain a positive, proactive mindset. These challenges are temporary, and by positioning yourself strategically, you can emerge even stronger on the other side.
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?
.jpg/)
Yeah, I did experience some burnout during my time at JP Morgan. It wasn't so much the workload that got to me, but more the sense of just sitting in meetings all day without actually accomplishing much. That feeling of spinning your wheels can really start to pile up and become frustrating.
However, I've learned that taking regular breaks is crucial to avoid burnout. Even if it's just stepping away for a few weeks to recharge, it makes a big difference. I make sure to get that time off, whether it's going on vacation or just disconnecting for a bit.
And I've found it helpful to maintain a diverse social circle, not just other developers. Talking to people from different backgrounds and disciplines helps provide fresh perspectives and prevents me from getting stuck in an insular tech bubble.
The key is staying self-aware and proactively managing your well-being. Burnout is a real risk in this fast-paced industry, but with the right balance of work and personal time, you can avoid it and keep that passion and enthusiasm going strong.
