Introduction
Hi Drashti, would love to know a bit about your professional background.
Hello, I’m Drashti! I've been working as a developer for the past five years. I did my internship and have been working at the same company, Amedeus, since then. Overall, it's been a positive experience.
Currently, I'm looking to transition to a new area within the development field. I feel like this point in my career is a defining moment where I can decide where I want to go and what I want to navigate towards. I’m really excited for what’s next!
Day in the life of a software engineer
What does a typical day look like for you as a software engineer?
I work with a team that's mostly based in Bangalore and France, so we operate in two different time zones. We usually have our daily stand-up in the afternoon when both teams are available. I focus on my work during the morning because the second half of the day is mostly full of meetings, like daily stand-ups, refinement sessions, or anything else.
We work in an agile model, specifically the Scaled Agile Framework (SAFe), so we have a lot of meetings on refinement, planning, and everything code-wise. Currently, my team is working on cloud migration. As a developer, there's not much I'm doing on the coding part unless there's a specific feature to work on.
Sometimes we're also in production support. During those times, we spend most of our day solving queries or issues for other teams who are using our application. When there are tickets related to coding, we might spend around 80% of the day coding, but that's not the case every day.
If we're talking about technical meetings, I'd say they take up about 20% of my time. Another 20% is spent on functional or non-technical meetings. So yes, when I’m not coding heavily, around 40% of my time is spent on discussions.
What’s your mantra to get quality work done daily?
One thing that motivates me is that every ticket is planned with some story points, so you know by what time or how many days you have to finish it. We have three-week sprints, so if I take up a ticket, I know I have to finish it within three days, and I'll plan my things accordingly.
For example, if most of my time today went into meetings, I'll try to take fewer meetings tomorrow and focus on the first half of the day, which is usually meeting-free. When there are meetings with a lot of context switching, it's sometimes not very productive. So, I try to focus on non-meeting time to get my work done.
It's a combination of having an external timeline that you have to adhere to and knowing when you can focus without any context-switching.
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 work, we have our own laptops, and then we have two monitors with a docking station that we can connect to. I use the two extended monitors and use a separate mouse and keyboard.
2. Software
A. Go-to browser
I mostly use Chrome.
B. Core work and coding tools
I use Windows on my laptop, but most of our day-to-day tasks and activities are carried out on Linux because of the servers and our backend system.
If I'm working with single files or log files, or if I want to remember something, I use Notepad++. In case I need some structure in my files and want to see subfolders and different files, then I go for Visual Studio Code.
When we code, we use IntelliJ IDEA and plugins based on what we need for a project.
C. Favorite programming language
I mostly work with Java but I don’t have a favorite as such.
Big Companies vs Startups
I noticed you've mostly worked in big companies. Do you prefer big companies over startups?
I think I would be open to working at a startup because most of my experience until now has been in a big company.
How would you compare startups with big companies?
In a larger company, you go through a lot of processes like getting permissions, going through your management, and getting approvals. You have to follow a standard set of procedures because of obvious reasons – they want to work in a much more organized way due to the manpower they have.
On the other hand, I think startups can make rapid changes, which is a possibility that I find attractive. So, yeah, I think I would be interested in exploring opportunities at mid-size companies or startups.
What are the key qualities of someone who would be a perfect fit for a startup versus big tech?
People who like to balance their development work with discussions and communication with other people, or those who enjoy exploring areas beyond just pure development, might have more opportunities at bigger companies.
At a startup, I think if you're a developer, you will mostly be working on different types of technology stacks and be primarily focused on tech. So, people who have a strong interest in technology might find better and more interesting opportunities at startups.
Navigating a New Tech Role
1. First month
During the first month, you should focus on understanding the overall business of the company and what they're striving to achieve. Take the time to learn about your team's functional role, including what they're working on, why it's important, and who the customers or users are. Concentrate on grasping the functional aspects of the systems or applications, such as the features and capabilities they offer. This foundational knowledge will help you navigate the new role more effectively.
2. Next 3 months
Over the next three months, make sure you understand what your team plans to achieve in the short term, usually over two to three months. Know what you need to do to add value to the business during this time. If there's something important that matches your skills or interests, dive into it. This will let you contribute more and help you grow personally. It's important that what you learn and how you develop yourself matches what the team or company needs, as this will help your team succeed.
3. 6-12 months
In the next six to twelve months, try to take charge of a specific part of the code or a particular feature. Become an expert in that area. Taking ownership like this will not only help you grow professionally but also earn the trust and confidence of your team. As you show that you're reliable and good at what you do, people will start giving you more important tasks. They'll see that they can rely on you to do a great job, even when things get tough. Building this trust is crucial for showing how valuable you are to the team and setting yourself up for success in the long run.
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
→ Be able to clearly articulate the company's core business/mission and what your team builds/delivers.
→ Understand the key systems/applications your team owns and their main features/capabilities.
→ Know who the customers/users are for the products you work on.
2. The next 3 months
→ Can speak in depth about the team's current priorities and quarterly objectives.
→ Have taken ownership of tasks/projects aligned with your strengths.
→ Actively contributing code/implementations that drive business value.
3. 6-12 months
→ Established as the subject matter expert for a specific codebase/architecture domain.
→ The team comes to you for insights/guidance on that area of ownership.
→ Demonstrating the ability to independently take on ambiguous/complex tech challenges within your area of expertise.
→ Earning trust through consistently high-quality deliverables even on stretching work.
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?
First, you need to demonstrate that you've delivered on your assigned goals and responsibilities on time and met the expected performance metrics or KPIs. You can provide specific examples of projects or tasks where you achieved the desired outcomes.
Additionally, there are personal development goals that you set for yourself to work on over the year. You can highlight the areas where you've made progress, such as improving certain skills, taking on new challenges, or expanding your knowledge.
The expectations vary based on the level you're at. For example, as a more senior engineer, your manager likely expects you to collaborate cross-functionally, participate in forums or training, and stay up-to-date with industry trends. You can share examples of how you've done these things to demonstrate your growth.
At a more junior level, the focus may be more on actively participating in team activities like hackathons or ideation sessions. Or it could involve proposing new ideas or technologies that can improve efficiency or solve problems more effectively for the team. You can discuss any such initiatives you've driven to show your contributions.
Ultimately, the key is being able to articulate specific ways you've added value, whether through strong execution of your core responsibilities, investing in your professional development, or going above and beyond to benefit the broader team or organization. With tangible examples to back it up, you can make a solid case for a positive performance rating.
Upskilling in Tech
So you’ve been in the industry for over 3 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
Being in the industry for five years now, I've had to constantly upskill myself to keep up with new trends. I’m generally motivated by - first, working on a team with very experienced developers who are always discussing the latest tools and concepts exposes me to new ideas. When I hear them mention an unfamiliar term or technology, it naturally piques my curiosity to understand what it is and the value it brings. That leads me to research it further through reading and experimenting.
Additionally, sometimes there are organizational initiatives or training programs around adopting certain skills or technologies due to business needs. It's important to take advantage of those opportunities.
2. Learning Approach
In terms of the actual process, I rely heavily on official documentation and getting hands-on by setting up development environments on my computer for new tools or programming languages. While books and tutorials give me the theory, being able to apply it practically is crucial.
Once I've learned something new, I actively look for opportunities to use those skills on real projects at work when possible.
But that's not always immediately possible. The key is staying motivated to keep practicing and refreshing those skills, even if I'm not using them directly, because you never know when they may become valuable again.
Qualities of 10x engineers
I've noticed the top engineers have this next-level problem-solving ability. It's not just about knowing the tech stack inside-out, though that helps. The best ones can take on any problem that gets thrown their way and systematically break it down to get to the right solution. Give them a challenge in a completely new domain or language, and they'll still approach it like true engineers.
It's like, their minds are wired to deeply understand the root issue and think it through logically rather than just applying memorized fixes. And they can explain their thought process in a way that makes sense to others. You know an engineer is solid when they can teach as well as they can code.
On the flip side, you get some engineers who are super skilled in that one specific tech they've worked with for years. But put them outside that comfort zone, and they struggle to adopt that problem-solving mindset as easily.
The veterans who've stuck around for decades have that versatility down pat. They've been through all the tech shifts and iterations, yet still stayed hungry to learn and grow with the changes.
It's not just about knowing the tech - that's the difference between an okay engineer and an incredible force multiplier on the team.
What advice would you give engineers to become 10x engineers?
Talking about my personal experience - I'm constantly upskilling, picking up new tech stacks and tools as they emerge. Versatility is crucial - I can't get pigeonholed into just one language or domain. The goal is to remain resilient and adaptive, able to easily pivot between different products, platforms, and whatever comes my way.
But it's not just about focusing on the code. Over a couple of decades, you really want to elevate your communication abilities and leadership qualities too. I make an effort to speak up in forums, share new ideas, and earn credibility where people respect my viewpoints. The best engineers become go-to problem solvers who can rally teams around their vision.
I think we can also learn from great engineers to be fully invested in mentoring those around us and creating opportunities for everyone to grow together. If the whole team is leveling up, then I'm leveling up too in the process.
So that's the path I'm personally aiming for - simultaneously building up a diverse technical toolkit while deliberately working on those vital soft skills around communication, influence, and leadership. I think it’s the powerful combination of coding progress and outstanding team leadership that separates the top-tier engineers over 20 years.
How do you think companies can retain these engineers?
First, I think great engineers need intellectual freedom and autonomy. No one sticks around if they feel micromanaged or stuck in a rigid role year after year. Companies should let engineers rotate through different teams, experiment with the latest tech, and scratch that creative itch through things like innovation weeks.
It's also about fostering an open, collaborative culture where everyone truly has an influential voice. You can't have rigid hierarchies where only a couple of senior people are calling all the shots.
And of course, properly rewarding top-performing engineers through career progression and compensation is crucial. If they’re constantly driving massive impact, that should be reflected in their advancement. Companies can't get complacent about retaining stars.
At the end of the day, elite engineering talent will always be in demand with options. Companies need to create environments that give them creative freedom, amplify their influence, reward their impact, and continuously challenge them with new problems.
Negotiating salaries in Tech
First off, I'll do thorough research to understand the typical pay ranges and bumps people are getting for the role and my years of experience. Tapping my network, salary data sites like Glassdoor, and trusted former colleagues who recently made moves - helps me get a solid target compensation range to aim for.
The general rule of thumb is shooting for at least a 30-40% raise to make the switch worthwhile. But it's not just about the hard numbers. I'll be sure to emphasize the full scope of my skills and experience that make me an ideal fit for what they need. If I'm truly checking all their required boxes, I can justifiably push to land at the higher end of their range.
There's also negotiating the full comp package beyond just base salary - bonus potential, equity, extra PTO, etc. I'll aim to get clarity on all those components.
The main thing is going in with data-backed target numbers, and tying it all back to the total impact I'll bring based on my tech skills, experience, and demonstrated ability to be a long-term contributor. If I can sell that holistic value-add, there's a path to get my target compensation to make that leap.
Assessing Job Offers: Beyond Salary
How do you assess multiple job offers beyond just the CTC?
I would prioritize:
1. Product/Technical Fit
→ The tech stack and domain they're working in is important - I want to ensure it aligns with the areas I'm interested in and looking to grow my skills in. A modern, innovative stack is preferable over legacy tech.
→ The future roadmap and trajectory of the product itself matter too. Is it an exciting, forward-looking space with a runway for impactful work? Or a more stagnant, mature offering?
2. Work-Life Balance
→ Their stance on flexible work options like WFH is crucial. I likely wouldn't be interested if they mandate a strict 5 days per week in office policy with no flexibility.
→ Looking at their overall cultural emphasis on work-life balance and not just working people to the bone.
3. Culture and People
→ This is a big one - the workplace culture and quality of colleagues you'd be surrounded by day-to-day has a massive impact.
→ In interviews, I try to suss out if it's a collaborative environment that empowers engineers to have influence. Also, get a sense of mentorship opportunities.
→ I feel that mismatched values or a toxic culture can quickly make a role miserable, no matter how lucrative.
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?
1. Compensation
Of course, the pay increase with the promotion versus the new opportunity's offer needs to be weighed. But it's not just about the higher number - I have to consider the total compensation package (bonus, equity, benefits, etc.)
2. Career Growth Opportunities
A big factor is which path provides more runway for continued growth and skills expansion. An outside role may allow me to work with newer technologies I'm interested in or take on a more impactful scope. Whereas the promotion may keep me somewhat limited in my current domain without as much learning potential.
3. Leadership and Work Culture
The quality of leadership I'd be working under is crucial.
In my current company, I'm familiar with the management style and culture. An external move means adapting to a new leadership team's philosophies. I need to get a good sense of the work culture at the new company to ensure it's an environment I'd thrive in. There's no one-size-fits-all answer, I feel. It requires carefully breaking down the tangible compensation, the career growth possibilities, the leadership/culture fits, and of course, my own personal and family priorities at that specific career moment.
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?
1. On burnout
I've definitely had that feeling, mostly when I'm working on very monotonous tasks, doing the same things repeatedly for an extended period. It's more of a sense of boredom, I'd say.
When you already know what needs to be done, and there's no real problem-solving involved, just the same work over and over again. If this goes on for like two or three weeks straight, yeah, I start to feel burnt out.
I can usually tell I'm getting burned out when I wake up in the morning and just don't feel like working, you know? The thought of opening my laptop and starting the day feels daunting. Or if someone asks me a question and I find myself getting irritated, thinking, "They're asking the same thing again." That's when I know I'm reaching my limit.
2. On maintaining work-life balance
To recover from burnout and maintain a healthy work-life balance, I find that taking a vacation or engaging in some activities outside of work really helps. Going on a trek or meeting up with friends can make a big difference.
It's important to step away from the daily grind and recharge.
Sometimes, I'll bring up my concerns during regular one-on-one meetings with my manager. We have a pretty good relationship, so I feel comfortable just pinging them and mentioning that I'm starting to feel bored and looking for new challenges. However, it doesn't always lead to changes, especially when there are logistical issues involved, like having a manager based in a different country. If I mention it once or twice and nothing happens, I don't keep pushing it. Instead, I'll take some time off or try to find more engaging work on my own to keep myself motivated.
When I'm feeling particularly frustrated at work and need to push through, I'll focus on the timeline and deadlines. Knowing that I have to get something done by tomorrow can be a good motivator to just sit down and do it.
In other cases, especially when dealing with production support tasks, I'll try to find a challenging issue to solve. Working on something different and experiencing that sense of satisfaction can help me power through the more mundane tasks. Sometimes, I'll also take an hour or two to work on something I find interesting before getting back to what I'm supposed to be doing. It's all about finding little ways to break up the monotony and keep myself engaged.
