Introduction
- Hello Amey, would love to know about your professional background.
Hi, I'm Amey! I've been working as a software engineer for around 8 years now. Completed my B.Tech in Computer Science from NIT Trichy back in 2015. After college, I kicked things off at Qualcomm, working on embedded systems stuff. Then spent a couple of years at Amazon - and was part of the Prime Video and international orders teams there. Also did a stint in the startup world for a bit. Worked at a social media platform called ShareChat, which focused on payments. And then at a SaaS company, Postman, that does API management.
These days, I'm at Airbnb as a senior software engineer in the payments team. So yeah, that's been my journey so far, moving through different companies and tech domains over the years.
Day in the life of a software engineer
- What does a typical day look like for you as a software engineer?
The days depend on which phase the current project is in - there are typically three phases it goes through.
In the planning/ideation phase upfront, I spend a ton of my time researching, talking to stakeholders, and documenting everything meticulously. It's crucial to write down all the approaches we're considering, thoughts we have, decisions made, and the rationale behind them. That way we maintain a solid knowledge base as we firm up the plan.
Once we move into the implementation phase, things are more clear-cut. The majority of my time here goes towards actually putting my head down and coding out the working solution. I coordinate within teams and keep stakeholders updated, but discussions take more of a backseat compared to the planning phase.
Then in the third phase after launch, observation and iteration take over. I won't say discussions increase again, but I do spend a lot of time closely monitoring metrics - seeing what's going well, and what needs improvement, and proactively working on fixes or incremental changes accordingly based on real-world feedback.
So it's researching and meticulous documentation up front, coding during implementation, and then monitoring/iterating post-launch as we get real data flowing in. The distribution of tasks keeps shifting as the project moves through these three phases.
- What’s your mantra to get quality work done daily?
For me, there are a couple of key things that help in getting quality work done consistently. First off, planning and clarity on exactly what I need to do is crucial. It's not just about having a generic to-do list, but clearly defining the specific goals I'm working towards and what success criteria I need to meet. Without that clarity upfront, I could just end up randomly wasting time without actually accomplishing anything tangible.
Documentation is another big part of my process. We often have to juggle multiple parallel discussions and by the time it comes to actual implementation, it's easy to deviate or lose track of the finer details we had aligned on earlier. So I make sure to document the core aspects of our thought process, decisions made, and the underlying rationale. I'm not talking about over-documenting everything, but just capturing the crux.
Having quantifiable goals defined upfront, and a good documentation trail of the plan - those are two main things that help me stay streamlined and deliver quality work day after day, no matter what phase I'm operating in. It prevents me from going off track or losing context from all the theoretical discussions.
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
My primary machine is a MacBook, which I'm really comfortable with - the trackpad especially is excellent, so I don't feel the need for an external mouse. I do like having one or two extra monitors hooked up though, as it boosts productivity by being able to glance at multiple things in parallel.
But overall, I try to keep my hardware setup pretty minimal and portable since I'm working fully remotely. Just the laptop plus an extra screen or two is my sweet spot.
2. Software
A. Go-to browser
For browsing, Chrome is my go-to pretty much 99% of the time. It handles everything I need.
B. Core work and coding tools
I'm a huge fan of the JetBrains IDEs - using IntelliJ currently for my Java work. But I've used their other IDEs like PyCharm, WebStorm, etc across different languages and they all have that same smooth experience that I've gotten used to over the years. I'm also quite particular about optimizing my terminal setup with custom aliases, shortcuts, etc. Right now I’m using iTerm2 which is great for split panes and windows. Other than that, nothing too fancy - just Google Docs or Confluence for documentation.
C. Favorite programming language
You know, I've come to realize that languages are just tools - they each have their strengths for different use cases. So I don't have any innate preference or bias towards one over the other. But if I had to pick one I'm most comfortable with currently, it would be Java since that's what I've spent the most time on in recent years. At the end of the day though, the language is secondary - it's more about the core programming concepts.
Big Companies vs Startups
- I noticed you've worked in both big companies (Airbnb) and startups (ShareChat). Firstly, can you tell me your preference between the two?
I don’t have a specific preference - I think it depends on the team for me, not the company. I've seen cases in startups where if you don't land on the right team, you can either have a really bad work experience or an amazing one. So there's a lot of variance.
- How would you compare startups with big tech?
The main difference I've noticed is that at startups, you often encounter a lot of unsolved problems that you have to figure out from scratch. This can be good in a sense because when you're trying to solve a core business problem, you don't want to waste time on trivial things like just setting up a database when existing engines can do that with a few clicks. The opportunity to tackle those bigger challenges head-on is valuable.
However, working at a startup without any established processes can also be a downside. They tend to work in a very ad-hoc manner - just getting things done as they come up without following a defined process. And that's where getting experience at larger, more mature companies becomes important too.
You want to understand what those standardized best practices and processes look like - how teams are run in a structured way to deliver quality results consistently for 99% of the problems you face. That's the side of engineering discipline you may miss out on if you only work at startups early on.
So in summary, I think startups are great for getting a problem-solving experience early in your career when you can get your hands dirty with the core challenges. But you should also make sure to work at bigger product companies to learn those broader engineering processes and systems. There's value in both environments for a well-rounded perspective. First, get that raw experience of building things from scratch, then understand how to apply processes for consistent delivery at scale. Both are important competencies in my opinion.
Navigating a New Tech Role
1. First month
→ The most crucial thing is to properly set up all the tools and technologies your team uses - whether it's 10 different tools, get them configured correctly.
→ Don't hesitate to ask questions frequently in this initial period. No question is stupid when you're brand new. Take full advantage by asking as many questions as needed to understand the setup and working environment.
2. Next 3 Months:
→ Shift your focus to deeply understanding the business aspect and the bigger picture behind your team's work. Go beyond just the engineering side.
→ As an engineer, it's important to know why certain decisions are made, the rationale, advantages, etc. With that context on motivations and numbers, everything becomes easier to understand.
→ Spend these 3 months internalizing the business drivers and the users/customers you're solving for with your product.
3. 6 to 12 Months:
→ Now expand your knowledge outside just your immediate team's workstream. Understand what other teams are working on across the organization.
→ Start thinking about how you can contribute back to the team beyond just your assigned tasks. You'll have a good grasp by now of what's working well and what processes/systems can be improved.
→ Don't just execute, but identify areas for optimization and share those perspectives to make an impact. However, ensure you have the depth of understanding first before trying to influence.
→ Speaking of influence, this is a key aspect to focus on in this phase for accelerating your growth. It's not just about your contributions, but how you can positively influence the efforts of others around you - but be careful not to try influencing prematurely before you've built up sufficient context on the codebase and systems. You don't want to come across as naive or just making suggestions from books without real knowledge.
My overall advice is to systematically build up your understanding and context over those phases, only then try to drive more influence and impact within the wider team/organization.
- 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
Complete an onboarding checklist - setting up all required tools/technologies, going through documentation, and understanding the working environment. A simple checklist ensures you cover all the basics.
2. Next 3 Months:
Be able to clearly articulate the "why" behind your team's work - the motivations, business rationale, and advantages of the approaches taken. Don't just know "what" you're doing.
Gain autonomy and reduce dependency on asking for help constantly. You should be able to work more independently by doing your due diligence before asking questions to teammates.
3. 6 to 12 Months:
Track how many people are coming to you for help/suggestions. This is an indicator that you've established trust and the ability to positively influence those around you. Check if the leadership is confident in assigning you projects without micromanagement. If they believe you can reliably deliver quality work independently, it shows you've grown into a key contributor.
Essentially, you should transition from being the one constantly asking questions to becoming the one who can guide others based on your implementation experience and context. My overall advice is to systematically build up your understanding and context over those phases, only then try to drive more influence and impact within the wider team/organization.
- 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?
The key is to proactively track and document your work throughout the year, instead of trying to recollect everything right before the review.
→ Maintain a running log or document where you note down.
→ Major projects/tasks you worked on and your specific contributions
→ Important suggestions/inputs you provided in meetings
→ Areas where you feel you excelled or could have improved
This documentation becomes a valuable record to refer back to when putting together your self-assessment. It makes sure you don't miss out on highlighting key accomplishments just because you forgot the details over the course of the year. Also, don't wait for the year-end review to get feedback. Have regular check-ins and one-on-ones with your manager throughout the year. During these:
→ Set concrete goals for the upcoming weeks/months and align expectations with your manager
→ Get their assessment of how you're progressing against those goals
→ Identify areas for improvement candidly - being honest about growth areas builds trust
→ The review process should not have any major surprises if you've had this open dialogue consistently. Come prepared with your documented achievements and reflections. But also be ready to receive feedback with an open mind.
The underlying principle is to be proactive about managing your career growth and performance. Don't make year-end reviews a scramble by keeping your manager in the loop and maintaining a record through the year itself.
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 motivation is the impact I can create - being able to add more value and solve meaningful problems excites me the most. The trigger for me is not just about learning new tech stacks/languages, but understanding how companies have applied technologies to solve real-world challenges. I like to learn decision-making frameworks and gain insights from how others have tackled problems, not just theoretical knowledge.
- 2. Learning approach
Most of my upskilling happens by attending meetups and talks where people share experiences using different technologies and the problems they face. I also read tech blogs and white papers from companies like Netflix, Uber, etc. which document their solution journeys in detail. I mostly prefer content that provides the context and thought process behind solutions, not just the solutions themselves.
I try my best to take notes but frankly I haven't made it a habit yet due to going back and forth between devices. I do think note-taking can be really powerful! I’d recommend summarizing key paragraphs in one line to be able to quickly revisit the content years later.
- 3. Practical Application
I actively contributed to open source and worked on personal projects early in my career. But I’ve taken a break from that for the last 1-2 years to focus more on learning, especially around leadership skills. I see myself going back to contributing to hobby projects again in the future.
I’d say just focus on constantly learning from the real-world experiences of others, understanding decision-making principles, and be able to use that knowledge to create more impact in your career.
Qualities of 10x engineers
I think the main differentiator between a great engineer and an average one is the trust the team has on them. And this trust comes from getting things done properly, whatever is coming your way, within the stipulated time. That's what matters and speaks volumes.
An average engineer has a very short-sighted view. But a great engineer is very practical. They understand the business so well that they know that for a particular problem, how long the solution is required for - whether it's just a trivial temporary fix or if they need to think about it from a long-term point of view. They have a good blend of short-term and long-term thinking based on context.
One more quality great engineers have is they follow a T-shaped learning approach. They have a depth of expertise in one or two fields where they are unbeatable masters. But they also have breadth - they may not have expertise in all areas, but they are still aware of what is happening in other domains.
- What advice would you give someone to become a 10x engineer?
Being curious and always learning takes you places. If you only do the work assigned, you'll remain average.
When you're curious, you explore how things are implemented internally. Like if using a library, you dig into why it's efficient instead of just using it as a black box.
Your curiosity should extend to understanding what other options and approaches are out there from other teams and companies. That's how you attain depth as well as breadth of knowledge. But this curiosity cannot come at the cost of your deliverables.
You have to be smart about planning your learning. Most companies will give you 10-20% time for research and learning, but not 80%. You first have to build trust by executing well. If you're super knowledgeable but people don't trust you to deliver, that's not an ideal situation.
- How do you think companies can retain these engineers?
As an engineer, two key things help companies retain talent - good culture and alignment with personal aspirations.
Money alone won't make people stick around for long if the work culture is poor.
The other aspect is whether the company can provide a path or at least a roadmap aligned with the engineer's long-term goals for upskilling in certain areas or working on particular domains. If that alignment is missing, they will inevitably look for those opportunities elsewhere.
Companies need to foster an enjoyable culture and be able to chart out growth opportunities that match their engineers' personal aspirations in order to retain 10x talent long-term.
Negotiating salaries in Tech
Yes, negotiating can be tricky - not just in tech but across industries. To get a ballpark range for your experience level at a given company, there are a lot of helpful resources out there. Websites like Levels. fyi, Blind, FishBowl, and LinkedIn let people anonymously share compensation data. Glassdoor is another useful site. Your professional network can also provide insights into typical pay ranges. Ask your friends, ask their friends. That’s how you will get to know the truest numbers.
I’ve learned that the key is to go into negotiations informed about the company's typical pay brackets for your role, rather than just throwing out a random number. When proposing a salary, don't just state a figure. Explain why you deserve that amount by highlighting your capabilities, accomplishments, and the value you bring to the table. Backing up your ask with data and reasoning gives the decision-makers more confidence.
Don't be shy about negotiating - there's no harm in trying as long as you make a solid case. If you have a competing offer, that can also strengthen your negotiating position by signaling that another company sees that value in you.
- Based on your experience, how do you typically determine when it's time to wrap up negotiations and accept an offer?
As for knowing when to wrap up negotiations, there's no set formula. You'll get a gut sense from the discussions whether you're making headway or not. Companies won't rescind an offer just because you tried negotiating reasonably. But continuously pushing the same number after it's clear they won't budge could sour things. Read the room and know when you've made your best case.
Assessing Job Offers: Beyond Salary
- How do you assess multiple job offers beyond just the CTC?
A few things really matter to me. First off, it's all about the culture. You want to work in a company that respects you and where you feel like you belong. Check out the company's values and see if they match up with yours.
Next up, think about how each opportunity fits into your career goals. Does the role help you grow in the direction you want to go?
Choosing a company is like choosing between a rocket and a plane. You might be okay with earning a bit less at a rocket ship company rather than a more stable one. If you're confident the rocket's going to take off, you want to be on board because you know it's going places. Money is important, but sometimes you might be okay with earning a bit less if it means joining a high-growth company.
There are other things to think about too, like benefits, learning opportunities, commute, work-life balance, and what your career path might look like. It's all about finding the right balance between what you need now and where you want to go in the future.
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?
You should focus on the responsibilities you're getting because that's what matters in the long run. Go for the role that offers more responsibilities, regardless of the title.
Here's how I see it: think about what's important to you. Money, company culture, your career goals, and how the company is growing. Give each of these factors a score out of ten based on how important they are to you.
For example, if you've got loans to pay off, money might be more important to you than someone who's debt-free. Once you've given each factor a score, multiply it by its importance score and add them all up. This gives you an idea of how each offer stacks up against the other.
I'm not saying that you should just go by the score. But calculating those scores just gives you some idea. You know, if these two offers are comparable, or if one is a very clear winner.
Navigating Layoffs
- The past year has been tough for engineers facing layoffs. Did anyone in your circle get laid off in the last year?
Yes, I know quite a few people. But what I've learned is that they were able to find great opportunities at new companies, simply because they are highly skilled at what they do. Of course, the availability of roles is not as much as how it was when companies were going overboard to recruit talent. But if you are truly capable and have potential, there will always be companies interested in hiring you.
I've personally seen multiple companies vying to recruit exceptional candidates even in this market. Those candidates ended up being able to negotiate significantly higher salaries than initially offered, purely because three or four firms were competing for them. And these weren't cases of active job seekers - I knew people who were laid off, yet found themselves in an extremely advantageous position with the luxury of weighing multiple offers.
So if you are truly worth it, if you have valuable skills, there will be ups and downs but your talent will always be appreciated regardless of market conditions. You can rest assured about that. The state of the market does play a role, but if you continue developing yourself, you don't have to worry about these fluctuations as much.
- Job advice
1. Job search
In terms of specific job search advice - the first key is to never settle for a company you aren't enthusiastic about joining, just because you got laid off. Give yourself ample time to find the right fit.
Update all your professional profiles and resumes on job sites immediately. But more importantly, really lean on your network. You likely have numerous friends who would be happy to refer you if they know your capabilities. Don't hesitate to send your resume to your connections and let them know exactly what kind of role and company you're seeking to align with your skill set.
2. Interview process
A) Non-technical
During the interview process, a big factor is understanding precisely what that company, team, or hiring manager values and is looking for in candidates. If you can frame your background as the solution to their specific needs, they'll prioritize you over other applicants.
You obviously can't directly ask what they want, but get skilled at asking insightful questions to uncover those needs, then position yourself as the ideal match.
B) Technical
Technical interview performance is a prerequisite. But especially at senior levels, convincingly articulating how you will solve the team's problems and fulfill their key requirements can strengthen your candidacy.
The goal is to make them see you as the perfect fit they're looking for. With a strategic approach centered on showcasing your valuable skills, you'll uncover promising roles despite market headwinds. Just avoid rashly taking something you'll regret because you feel rushed after the layoff. With patience and positioning yourself as the elite solution, you'll find your next great opportunity.
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?
If you’re burning out, I think it's important to understand if this is a one-off situation due to certain circumstances, or if it's becoming a consistent pattern. If there is a legitimate, short-term need for extended hours on a critical project you're invested in, everyone understands that. The issue is when the burnout stems from an ongoing pattern without a clear necessity.
If that's the case, you have to ask yourself - are you being exploited? Is this level of burnout really required, or is it just to extract maximum productivity at the expense of your personal life? You get a sense when it feels purposefully excessive. Then you have to evaluate if this job is worth that personal cost, or if you would be better respected elsewhere with a healthier balance.
- 1. Signs of burnout
Sometimes recognizing burnout itself can be tricky, as it may manifest in different ways beyond just long hours. For me, one clear sign is if I spend entire weekends just sleeping and doing nothing else. That signals I'm not getting enough recharging rest during the week to enjoy downtime on weekends.
Mental burnout unrelated to sheer hours is another factor. If you have to deal with draining office politics or toxic interpersonal dynamics, even with a limited workload, that can induce a feeling of burnout as well. It comes through in your mindset and how discussions make you feel, beyond just time invested.
- 2. Recovering from burnout and maintaining work-life balance
- .jpeg/)
If I do feel I'm burning out, the first step is validating the root cause. Is it an excessive workload despite my efficiency? Or am I being inefficient and creating unnecessary burnout myself? Once I identify the true driver and assume it's not my own productive practices lacking, then I have an open discussion with my manager. A healthy relationship where you can surface these issues is important.
My personal strategy is that after an intense burnout period, I make a point to take 2 to 3 days completely off, beyond just weekends. Whether a short vacation or extended staycation - totally unplugging and doing non-work activities I enjoy is crucial for bouncing back.
