Introduction
Hello Zara, would love to know about your professional background.
Hi, I’m Zara! I graduated in 2013 and since then, I have been working mainly in individual contributor roles by choice. I started my career with a small startup called Fiberlink, which focused on corporate data security. Later, Fiberlink was acquired by IBM, and I was part of their workforce for a short while. After that, I decided to change my job and joined Amazon, where I've been working since then. I like it so far, and it's been a good experience. Overall, I have around 10 years of experience in the tech industry.
Day in the life of a software engineer
- What does a typical day look like for you as a software engineer?
As an individual contributor, I'm mainly responsible for owning the tech solutions and products, rather than managing people.
When I start my day, I usually check messages on our communication channels and respond to emails, as we have a global team across different time zones. After that, my day varies depending on my mood and priorities.
The primary activities I work on include:
→ Personal deliverables: Designing and writing code for the projects I'm responsible for.
→ Reviewing other people's work: This includes reviewing code, and designs, and helping teammates who may be blocked on certain tasks by providing input or discussing solutions to help them move forward.
→ Meetings: I attend stand-ups, project planning, and design review meetings.
→ Operations: On days when I'm on call, I spend the full day on operational tasks. Even when I'm not on call, I provide input on recurring issues and suggest ways to fix them for the long term, reducing our operational burden.
- How much time do you spend coding vs in meetings?
The actual code writing part probably takes just 15% to 20% of the overall delivery when I'm working on a project. A major part of my time goes into reviewing other people's code.
I've always been of the view that there is a huge difference between a programmer or coder versus an engineer. A programmer or coder is a subset of an engineer, as an engineer has many other things to focus on. Personally, I really want to increase the time I spend coding, but the current demand is such that only around 15% to 20% of my time is dedicated to writing code myself.
- What’s your mantra to get quality work done daily?
I usually make a list of things I want to accomplish in a week and then work on whatever I can do in a day, based on priority.
Also, in my team, I have set the standard that any code going into production has to be reviewed by at least two people, and I am often one of the reviewers. This not only ensures that we push less buggy code to production but also serves as part of the mentorship for other engineers in the team.
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
I've noticed that all my teammates in the office have fancy setups with laptops and monitors, one in horizontal orientation and another in vertical. However, in my 10-11 years of experience, I've never used an external monitor. I just work on my laptop, which is a MacBook Pro. It just works for me.
2. Software
A. Core work and coding tools
I primarily work in Java, so I mainly use IntelliJ as my IDE. The rest of the tools depend on the specific task I'm working on, and we also have some internal tools for various purposes.
Previously, when I worked as an Android developer, I used Android Studio and Eclipse.
B. Favorite programming language
I work mostly in Java, so I'm most familiar with it, but I wouldn't say I have a favorite language.
As engineers, we have to be flexible and not get too attached to a specific language because different languages have their own benefits and advantages.
The choice of language depends on the component we are writing, where it's going to run, and on what hardware. However, I have spent the majority of my career working in Java.
Big Tech vs Startups
- I noticed you've worked in both big tech (Amazon) and growth-stage startups (Fiberlink). Firstly, can you tell me your preference between the two?
I don't really have a preference for one over the other. Both big tech companies and startups have their own challenges and exciting aspects. But, based on my personal experience, I feel like I have learned more while working in big tech.
That said, it also depends on one's interests and the kind of problems they focus on solving, which can be very different between the two.
- How would you compare startups with big companies?
In a startup, the focus is more on how quickly you can deliver something, get it out there, and then iterate based on the feedback. It's a very fast-paced environment, and you have to wear multiple hats. You might be working on the backend, frontend, or even designing, all at the same time. The exposure is quite broad, but the depth might be limited.
On the other hand, in big tech companies, the focus is more on the scalability, reliability, and maintainability of the systems you are building. You have to think about how your system will behave when there are millions of users accessing it simultaneously. You also have to ensure that your system can handle failures gracefully and recover from them without impacting the user experience. This requires a different kind of problem-solving approach and mindset.
In big tech, there's a huge emphasis on the security and privacy of the code you're pushing. You have to consider how it will interact with its environment to ensure it's secure for the customer. There's a focus on customer data security, both in storage and transit. Operations are also critical - once you've launched the software, you can't just wash your hands of it. There's continuous operational maintenance, monitoring metrics, and finding ways to improve for the customer's benefit.
Performance and scalability are key considerations in big tech. The code you write might work for ten customers now, but can it scale to a thousand or a million? These factors need to be ingrained in the software design from the start, which is very different from the approach in startups.
In startups, especially in the early years, there's often less focus on testability and deployment quality, perhaps for good reasons. When you're just launching, you're planning for your first ten customers, not the next 10,000. Over-engineering the product for future growth doesn't make sense when you don't even know if the product will still be in the same form by then.
Both environments do what's good for their business, but the basis itself is very different. I've enjoyed working in both settings. In startups, I've been given open-ended problems like creating a secure chat app in just six weeks, and we made it happen. It's fun in its own way.
Ultimately, it's good to have both experiences and figure out what you enjoy more based on your career stage and goals.
Navigating a new tech role
- Since we're on the topic of getting into tech, I'd love to hear your top tips for someone navigating their first 12 months in a role. Let's break it down into three parts: the ideal 1-month, 3-month, and 6 to 12-month period.
1. First Month
Focus on understanding what the company does and how your team fits into the bigger picture.
Absorb as much information as you can about the product and the company.
Ask a lot of questions and leverage the leeway you have as a new team member
Build rapport with your teammates and establish good working relationships.
2. Next 3 months
Continue learning about the product, the company, and the domain.
Start contributing to the team's work and take on more responsibilities.
Identify areas where you can add value and make an impact.
Seek feedback from your manager and teammates to ensure you're on the right track.
3. 6-12 months
Evaluate what you can give to the company and what you can take from the company for your growth.
Remember that your growth and the company's growth are mutually beneficial.
Solidify your position in the team and become a go-to person for questions and guidance.
Look for opportunities to take on more challenging projects and expand your skill set.
Continue building strong relationships with your colleagues and stakeholders.
Throughout the first year, it's crucial to focus on gaining knowledge, creating a strong working rapport with your team, and establishing your footing in the company.
The first six months are primarily about absorbing information and asking questions, while the latter half of the year is about applying that knowledge, making an impact, and setting yourself up for long-term success in the role.
- If you had to give a KPI to know that you’ve succeeded in each of these phases, what would those be?
1. First Month
→ Understand the team's development process, coding standards, and guidelines
→ Familiarize myself with the codebase and the tools used by the team
→ Complete the assigned tasks, even if I need help from my teammates
→ Establish a good working relationship with my team and ask questions when needed
2. Next 3 months
→ Start taking on more complex tasks and deliver them with minimal assistance
→ Contribute to the team's discussions and planning sessions
→ Identify areas where I can improve the team's processes or codebase
→ Take ownership of my work and communicate effectively with stakeholders
3. 6-12 months
→ Become a go-to person for certain areas of the codebase or specific technologies
→ Mentor new team members and help them ramp up quickly
→ Identify and propose new projects or improvements to the team's processes
→ Deliver high-quality work consistently and meet the team's deadlines
The main KPIs revolve around my ability to deliver projects independently and become more self-sufficient over time. In the beginning, it's expected that I'll need help from my teammates, but as I grow in my role, I should be able to take on more complex tasks, deliver them with minimal assistance, and even start mentoring others.
Another important aspect is gaining a better understanding of the time and effort required for each task. As I spend more time with the team and the codebase, I should be able to estimate the duration of my tasks more accurately, which is a key indicator of my growth and success in the role.
- 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?
Honestly, I've never gone to my manager and said something like, "I did this and that, so I deserve a million dollars." I believe that if you're a good engineer and you're performing consistently year after year, you'll get what you deserve. Maybe I'm fortunate that I've never had to fight for recognition or compensation, even after delivering two major projects.
I always focus on my growth - am I improving as an engineer, am I on the right path to my next goal? And that goal can be anything, like becoming an SD2, SD3, or a principal engineer. I mainly focus on that because if you're focusing on your growth and career path, your paycheck will naturally match that level. But if you're only focusing on the paycheck, you might lose sight of what's going to get you there.
Getting more money can never work independently without you growing as an engineer. No company will just give you money because you say you delivered two products. They look at how well you executed the delivery. Did you deliver it in the estimated two months or did it take six months? There are a lot of factors to consider.
You need to constantly improve on those factors, and money is just a byproduct that keeps coming. Companies want to retain good people, grow them, and invest in them. So you have to become that kind of engineer for the promotions and money to flow.
Unless you have a strong reason to believe you've been treated unfairly, you shouldn’t feel the need to fight for recognition and compensation. If you have a good team, your manager will notice your impact.
Upskilling in Tech
- So you’ve been in the industry for 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
Two motivating factors help me decide what I want to learn next.
First, I consider what will help me grow in my immediate role and projects. I try to do that learning on the job. One thing I really like about working in big tech is having access to amazing senior engineers who can be mentors and guides. Just being in meetings, design discussions, and reviews with them, I feel like I learned something that would've taken me months to figure out on my own. The second factor is what will help me become a better engineer overall, without tying myself to a specific company. I think about whether I'd be employable anywhere else if I wanted to switch jobs tomorrow, or if I'm only employable at my current company.
So there's the learning to grow in my current role, and then there's the learning to be employable anywhere or even start my own thing. I focus my upskilling efforts along these two lines.
2. Learning approach:
A big part of my learning comes from my day-to-day work - the meetings, researching for upcoming projects, brainstorming solutions. When I'm brainstorming and get stuck, I try to explore different possibilities and really go in-depth on a topic. That's one way I learn.
For more personal learning, I usually do that at night after dinner when I'm about to go to bed. If I don't have a lot of time, I might just watch a 30-45-minute YouTube video on something I want to learn. Sometimes I'll do this on weekends too, but I try to avoid that and keep my weekends for non-tech, non-work stuff. So it's mainly weekday evenings after work, or during work hours if it's related to my immediate projects.
Qualities of 10x engineers
One thing I really look up to is their communication and writing skills. You might be surprised, but for a coder or programmer, it's not just about writing code. I'm not even touching on the technical aspects here - those are the bare minimum. You can't be an engineer unless you know how to code, understand algorithms and data structures, all that stuff.
But the non-technical skills are also super important, even if they sometimes get overlooked. You absolutely need that technical foundation, it's your bread and butter. But the non-technical part of how you communicate is what really sets them apart. I’ve noticed whenever I'm in a meeting with a principal engineer, senior principal, or distinguished engineer, you can really how incredibly they communicate and present their views or suggestions. It's so crisp and it changes based on who they're talking to.
The way they talk to an engineer like me is totally different from how they talk about the same exact topic or project to a product manager, VP, senior engineer, or junior engineer. It's a night and day difference, but they're still getting the same point across.
Another thing I've noticed is that the higher they climb in their career, the more humble they seem to get. For them, there's no such thing as a dumb question and they always encourage people to ask questions without worrying about whether they’re ‘right’. If you question why they picked one design over another, they'll never be arrogant and say "I designed this, just do it, no questions asked." They want you to ask questions so they can walk you through their reasoning.
You can ask them the same thing five times and they'll keep explaining because mentoring is part of their job. Learning and mentorship only happen when you're clarifying someone's doubts. It's not just dumping knowledge on you, they also have to shape how you think.
Every single time I leave a meeting with senior engineers, I walk away with a new insight. Maybe I'm presenting a design that I've gone over personally from every angle and put into a document. But then they'll ask a question, not to tell me I'm wrong, but to see if I considered something else or suggest looking at an alternative to see if it's better.
I always come back with the realization that this is something else to think about in the technical design. Something I missed. Maybe it works great for 10,000 customers but what about those two edge cases? That kind of insight comes with experience.
So communication, writing, mentorship, and tailoring your message to your audience are critical skills for an engineer, on top of the core tech skills that never go away.
- What advice would you give someone to become a 10x engineer?
There's a huge difference between a programmer and an engineer. Being an engineer is like a superset of skills - it goes way beyond just sitting at your laptop, hoodie up, headphones on, furiously typing away at the keyboard. It really depends on what you want out of your career and life.
But in my experience, as you grow and progress as an engineer, those non-technical skills become more and more crucial. You can't just be a code monkey. You need to be able to communicate effectively, collaborate with others, think strategically, and solve problems in a way that considers the bigger picture. Those soft skills are what truly differentiates a great engineer from someone who's just really good at coding.
So while having solid technical chops is always going to be important, I firmly believe that investing in and developing those non-technical abilities is just as essential for long-term success and growth as an engineer. It's not just about what you can do, but how you do it and who you do it with. Focusing on that stuff early in your career, alongside the technical things, is key to becoming a really phenomenal engineer in my book.
Joining FAANG
- Do you think all FAANG engineers are 10x engineers?
Not everyone is at the same level for various reasons, and it's not necessarily because they're not capable. Obviously, they're capable - I'm sure most big tech companies have rigorous entry criteria with 5-6 rounds of interviews covering coding, design, and non-technical aspects like leadership. If you can get through that process, you clearly have the talent and what it takes to succeed in big tech. But maybe that's not what you want, and so you don't continuously build on those skills. And that's totally fine - if you know it's not what you want to do, maybe you want to go out and do something else.
Not everyone is at the same level and it's all relative anyway. Just being at a FAANG company doesn't automatically make you a great engineer. It's about your personal goals, interests, and willingness to grow in both the technical and non-technical areas. Some folks might thrive in that environment, while others might find more fulfillment elsewhere. There's no one-size-fits-all answer.
- A lot of engineers aspire to work at Google. Do you have any advice for those looking to join Google as an engineer? Anything they can do with their resumes, interviews, or job search process?
One key thing is to avoid just spinning stories - the interviewers, they're trained to catch that. It's crucial to support your claims with data. Design discussions are very open-ended, so if I give you a problem and ask you to do a technical design, you should be able to validate your choices with data when questioned.
Inculcate the habit of thinking critically and questioning things. Sure, you might put a database here, a cache there, create a microservice, and so on. But are you doing that just because it's a pattern you always follow, or because it actually makes sense for this specific case? Have you done your due diligence in comparing different options? Is the cache really needed based on the latency requirements?
Instead of just following a pattern, think through every decision. That's something that's checked in interviews at every level, and in every project and design you'll work on. Why did you choose A over B? Did you consider option C? That out-of-the-box thinking is important.
For the technical part, people interviewing at big tech companies usually come prepared for the coding rounds, algorithms, and data structures. They can write code even if it's just on pencil and paper. In my experience, the more difficult rounds are the design rounds and the more abstract, open-ended rounds. They're not binary, not just correct or incorrect.
In a design or leadership round, it's never a clear yes or no. Maybe your design is completely wrong, but were you trying to think about the right things? Did you have strong reasoning for what you suggested? That ability to reason and question is crucial. And again, the non-technical skills are super important too.
So my advice would be to focus on developing that critical thinking, questioning mindset, and ability to justify your decisions with data and reasoning.
Combine that with solid technical preparation and strong non-technical skills, and you'll be well-equipped to tackle the FAANG interview process.
Assessing Job Offers: Beyond Salary
- How do you assess multiple job offers beyond just the CTC?
When I was in this exact position, interviewing while working at IBM, I had offers from two companies. One company was offering a higher CTC, but the team they were placing me in would have me doing Android development, which I was already doing at Fiberlink. I wanted to do something different. So, I took the other job, which paid less but gave me the opportunity to work on something new and exciting.
I think it's crucial to know what you want to do and what work seems more exciting to you. That's one of the most important factors for me personally. Even when switching teams within a company, I always base my decision on the work I'll be doing. Day in and day out, the area you work in should excite you; otherwise, the job starts looking like just a job, you know?
The other important factors are of course looking at the culture of both companies and seeing where you fit - I think it’s important to assess what you prioritize in work cultures as well and go according to that.
The most obvious ones are obviously checking the company, its growth, and vision and see if it aligns with your career goals. When you go beyond salary, you give yourself more space to make an infact more informed decisions sometimes as these factors are carefully thought out before you make a choice. I’d encourage engineers to do this after they have crossed a certain phase in their careers.
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?
I've actually been through this exact situation at Amazon. I was due for a promotion, but I wasn't enjoying the work. The other opportunity seemed really good at the time, in terms of the work I would be doing. I wasn't sure if that opportunity would still be there eight months from now when I was promoted. So, I chose not to take the promotion and switched teams because I liked the work more.
A very senior person at Amazon gave me some valuable advice during that time. He said, "Your career is a marathon, not a sprint. A year here and there in your promotion isn't going to matter 15 years down the line. You're probably not going to remember that, but you are going to remember and build upon all the learnings that you'll do in that one year." He emphasized that if you feel like you have stagnated in your learning, then you have to take that decision.
I think that was very pointed advice at the time. It really resonated with me because I believe that if you're good at what you're doing, money will come. The priority is to make sure that what you're working on is essentially what you want to work on, whether that's through another offer or a promotion. It's crucial to consider your growth and learning opportunities, even if it means forgoing a promotion in the short term. Ultimately, the experiences and skills you gain during that time will be far more valuable in the long run.
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. Signs of burnout
So many times, especially during the pandemic when we were all stuck inside the house with nothing else to do. I went into a very bad pattern of spending most of my free time just working. That, combined with so many things going on in the world, led to burnout.
Strict deadlines and stressful work are part of the job, but one of the most important things I've learned in the last two or three years is to recognize and identify if I am burning out.
There might be different small hints, like getting more irritable, even after work hours, with family members or people who help out at home. Not wanting to go out and do something fun. Constantly thinking about work or being stressed about deadlines. Even when trying to sleep, worrying about remaining tasks, or if what I committed in production is correct.
I was very oblivious to all of that initially, but I've learned that the first crucial step is recognizing these signs of burnout.
2. Recovering from Burnout
If you have reached burnout multiple times in a matter of two or three years, you should recognize that there is probably a consistent bad pattern you are following.
You should try to incorporate things in your schedule and life that will help you avoid getting into that situation. For example, we have a global team, and I reached a point where I was having meetings outside office hours every night of the week. No one was forcing me to do that, but I preferred working late at night rather than waking up early to interact with the teams in Seattle or California. If you're in a global team, there's no way you won't need to interact with them.
Night meetings suited me more, but I realized that throughout the week, even after office hours, I wasn't able to do anything else, like meet friends, because I had set up meetings at 10 pm. I recognized that pattern and purposely started setting boundaries by blocking my calendar, starting with two days a week.
Eventually, the project and those deadlines subsided, but I took that learning and would now try to apply it, irrespective of the next project. Mental health and general well-being are obviously very important. Recognizing your signs, and long-term patterns, and improving on those while finding outlets is crucial.
3. Maintaining work-life balance
I think to maintain a fairly okay work-life balance, I try out new things outside of work every other week that lift my spirits up. I like trying out new restaurants and cafes, so when I'm meeting friends, I usually do that. I also have a nephew, and I think spending 1 hour with him is all the fun I need. I love doing that, so I think mostly every weekend, at least one day I spend with him.
Very recently, I have started learning horse riding. I go for that on weekends, and it was a very conscious decision. I wanted to do something that was not confined indoors; I wanted to pick up an activity that was more outdoors. I'm enjoying that.
.jpg/)
Otherwise, it's normal stuff like binging on Netflix. Some days, I just spend 5 hours in my bed, doing nothing. Maybe I'm scrolling through Instagram reels, or maybe I'm reading something or I'm just a person in my bed with no movement, haha. I think it all comes down to being super intentional for taking time to recharge.
