Introduction
Hi Akhil, would love to know a bit about your professional background.
Hi, I'm Akhil! I've been working as a software engineer for a little over ten years now.
Throughout my career, I've had three main positions.
I started at a company called Fiberlink, which was a medium-sized company when I joined. Shortly after, it was acquired by IBM, so I got to experience the transition from working in a smaller environment to being part of a larger corporation as IBM became more involved.
The second phase of my career was working as a consultant. During this time, I also helped a company in the AI space, focusing on machine learning and mobile development.
For the past four and a half years or so, I've been in my third phase, working at Google.
Day in the life of a software engineer
What does a typical day look like for you as a software engineer?
My days are quite consistent, with some variation of course.
I have some protective time in the morning just for myself. When I get to the office, I have breakfast - Google is very famous for providing all meals. :)
From around 10 AM to 1:30 PM, I'm essentially going from meeting to meeting for about 3 hours. These meetings fall into two main categories:
- Meetings with my team of seven or eight people. I get updates from them, ensure they're unblocked, clarify their next steps, and address any doubts or technical issues they have. If I can't answer something, I redirect them to the right people.
- Meetings with people further up the chain, where I provide updates on what the whole team is doing, whether we're on track, what I need from them, and discuss any necessary collaborations with other teams.
- After lunch, from about 1:45 PM or 2 PM until 5 PM, I have a slot on my calendar where I auto-decline any meetings. This is when I focus on my design work, architecture work, and any individual coding contributions. I don't code nearly as much as I used to, but I still try to do some. I take a quick break after that and then spend another hour or so learning something new. That's pretty much my whole day!
How much time do you spend coding vs in meetings?
I think the answer depends a lot on the nature of the company. I'll use two extreme examples: a startup model and a Google model.
In startups, when you just join, at most 10% of your time is spent in meetings, basically just stand-ups and specific questions from your lead. 90% of your time should be designing and coding. Very early on, it'll be mostly coding because the design is often done for you, and you have to implement it. Later, it'll switch to more of a mix.
At Google, even early in your career, you'll probably spend at least 25% to 30% of your time in meetings, with the remaining time split between design and coding. The design coding part tends to lean more toward design because there are more reviews, and things are done slower in larger companies.
For someone at my level, about 40% of my time is spent in meetings. Another 20% is spent reviewing code and design, 20% on creating my own designs, and around 20% on coding.
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
In terms of hardware, I generally use Apple products, but nowadays, almost everything I do is online, so it doesn't make that much difference. Nearly nothing I run is running on a local machine. Even in my side projects, almost everything is running on AWS or Azure.
I use a large monitor, but I'm not a big fan of dual monitors personally. I've tried it a few times, and it doesn't really work that much for me. I'm someone who doesn't like to have a lot of things open, so I work on one thing at a time.
2. Software
A. Go-to browser
I've started using this thing called Arc, which is like an AI browser. At work, I obviously just use Chrome.
B. Core work and coding tools
At Google, everything I use is internal. But essentially, I use something equivalent to Sublime Text with a lot of standard plugins. The stuff I'm using most often now is AI-complete plugins and things like that. We have something very similar to Docker and Kubernetes for packaging and deployment.
C. Favorite programming language
I tend to default to Python for things that I want to quickly put together.
Big Tech vs Startups
I noticed you've worked in both big tech (Google) and growth-stage startups (Fiberlink). Firstly, can you tell me your preference between the two?
I'm really happy at Google right now. I feel like I'm still learning a lot, but I'm also able to have a big impact and work on really interesting problems.
That said, I could see myself going back to a startup at some point in the future, especially if I have an idea that I'm passionate about.
What are the key qualities of someone who would be a perfect fit for a startup versus big tech?
This is an interesting question. If I were to answer it from the perspective of helping someone gain something from this, I think your career is divided into phases.
Right now, I feel like I have completed the first phase of my career and I'm in the second phase. I would say the first phase is about learning, and the second phase is your implementation phase, where you get stuff done.
The length of your learning phase and implementation phase varies, and it's also not clear-cut. I am still learning every day - I spend almost an hour a day learning new things.
1. On starting tech careers at a startup
I think that early in your career, working at a startup is incredibly valuable. The reason for that is that you get to wear a lot of hats, you get to see a lot of different things, and you get to learn a lot very quickly.
In a startup, you're often thrown into the deep end, and you have to figure things out. That can be really challenging, but it's also an incredible learning opportunity.
2. Moving on to big companies
As you progress in your career, I think there's a lot of value in working at a larger company.
You get to see how things are done at scale, you get to work with incredibly smart people, and you get access to resources and opportunities that you might not have at a smaller company.
If you're a little uncertain, I would structure a career like this:
A) Learning phase
Start by spending some time at a place like Google or a big company known as a product company with coding excellence. It can be a very small company as well, but it should have these standards of coding excellence.
The first two to three years, or even as little as one year, will give you the background and best practices you need.
The first key thing to everything is to know who you are. For example, some people learn best when they're not the smartest people in the room. Google is the perfect place for that - there will always be an expert who knows more than you, and you'll always be able to find answers.
So, if you're extremely diligent, regimented in how you learn, and can take the best out of things while still diving deep once the answer is given to you, then a big company is great. You'll learn from the best and probably learn faster. But be honest with yourself about whether you are that person - which is why I say that in the learning phase of your career, you need to decide what type of learner you are.
B) Implementation phase
The implementation phase of your career is also very different. In a big company, if you like very structured planning, routine, delegation at a large scale, understanding the surface level of technical problems, and then splitting them up and breaking them down into smaller teams, that's great.
But if you still like getting your hands dirty, dealing with a lot of ambiguity, and switching between roles continuously, a startup is better for your implementation phase.
What you realize is that the answer may be completely different depending on which phase of your career you're in.
Navigating a New Tech Role
1. First month
In the first month, it's crucial not to focus on achieving things too quickly or getting a promotion right away, especially in companies with hierarchical structures. Instead, use this time to understand the company's architecture and learn the basics.
Again, think about what type of learner you are. If you learn best through projects, try to get involved in them.
"Don't focus too much on pleasing people or taking on tasks just for visibility, as this can sacrifice learning the fundamentals that will be important later in your career."
2. Next 3 months
Over the next three months, continue learning about the company, the tech stack, and the nitty-gritty aspects of your job.
Start making a career plan within the company. Pay attention to the teams that are going places and attend meetings with higher-level people whenever possible. Get involved in as much as you can, even as a junior engineer, to learn about the company's direction on a larger scale.
"Start being assertive and figuring out what you want in your career, as this is something almost no one does at this stage."
3. 6-12 months
In the 6-12 month period, aim to be in the teams that you think will be the most impactful. Take advantage of the fact that most people at your level aren't thinking strategically about their careers.
By being proactive early on, you'll have an advantage before everyone else starts competing for good projects. Continue to learn and grow in your role, but also keep an eye on the bigger picture and the direction of the company.
Make sure you're actively shaping your career path and not just being pushed into whatever is convenient. If you do this, you'll be able to define a much better career track for yourself, and people will notice.
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
→ Get to know your team and start familiarizing yourself with the tech stack.
→ Develop a learning plan for mastering the rest of the tech stack in the coming months.
2. The next 3 months
→ Gain a comprehensive understanding of the company's tech stack.
→ Be ready to tackle a diverse range of problems as an engineer.
→ Start building a career plan, identifying areas where you want to focus your efforts.
→ Begin to understand the direction you want to take your career, even if you don't have the leverage to push for specific projects yet.
3. 6-12 months
→ Excel at the projects you're assigned, even if they're not ideal, while actively seeking ways to move toward your desired direction.
→ Develop a clear plan for what you want to achieve long-term and start working towards it
→ Aim to take on impactful, large-scale projects that align with your career goals.
→ If your company allows, consider transferring to roles or taking on additional projects that fit your long-term plan after the 12-month mark.
"Remember, while you may not have complete control over your projects as a junior engineer, recognizing when you're in the wrong space and finding ways to move in the right direction is crucial."
Great engineers not only excel in their current projects but also proactively shape their careers by seeking out the right opportunities and experiences.
At the end of someone’s first year, what should their pitch to the manager be to ensure a successful appraisal, considering the KPIs you've mentioned?
1. On taking ownership of your career
The best advice I ever received in this area is that however wonderful your manager is, how great the team is, how well-structured the company is on metrics and everything else, no one cares about your career the way you do.
I'm saying this specifically for a career because obviously in your personal life, you have important people. But when it comes to your career, even your spouse is not going to think about it even a tiny percent of the amount you're going to think about it. So you need to own it.
2. On documenting your achievements
What I do is, at a weekly level, I write a summary of what I did, just for me. The impact this has on my documentation, compared to others, is significant. As a good engineer, there are many things you do that you'll 100% forget, and no one else is going to remember them for you.
For example, there was a team dealing with an LLM that was generating incorrect outputs (hallucinations). Despite their efforts to prompt engineers and restrict the LLM's API access, they were still getting a lot of incorrect outputs. I suggested having a second LLM review the answers provided, which took me about two minutes to think of. This idea was based on a previous experience, and although I was only in the meeting briefly, it seemed worth suggesting.
They tried it, and it reduced the error rate from 9% to 3%. To me, this is a perfect example of everything you should do. First, you should document that. Have that as an item. Second, you should remember the impact. Don't just say, "I had this idea," say it reduced the error rate from 9% to 3%.
3. No one will advocate for you like you will
Use numbers, document what you do, and remember that no one is going to do it for you. Do not expect that because you work hard, people will recognize it.
People will broadly have a general impression, and in super-small companies, that may be enough. A general impression may be all that matters in a really small company. But in anything bigger, even if your manager thinks you're the greatest engineer that has ever happened to your company, they need metrics to make your case for a promotion or anything else.
If you don't give that to them, they will not be able to match what you want even if they tried.
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?
I think that the periods in my career that have been the most productive - I've gone more by what interests me.
My answer here is again divided into those two phases.
1. Learning and Implementation Phases
A) Learning Phase
During the learning phase, nearly everything I did was based on interest. For example, when NLP was becoming a bigger challenge in the machine-learning world, CNNs made a huge breakthrough in image recognition and were achieving great results in pattern recognition. Language understanding was still way behind, and that was an area I was interested in, so I decided to spend a lot of time on it.
I think that during the learning phase of your career, you don't need to be that strategic. You should just chase whatever interests you and explore as much as possible.
However, this comes back to what kind of career as an engineer you want. I think broadly, engineers go down four different tracks:
→ Core IC engineers who stay dedicated to engineering and code a lot, even at high levels.
→ Engineers who shift into a role where their value comes from multiplying themselves, like architecting large-scale projects and leading 20-30 engineers.
→ Something closer to a manager.
→ A full-on manager who is only doing people management.
If you want to be the first type, it's a very specific personality. Everyone likes to think of themselves as that type, but there are certain qualities, like an engineering talent, attention to detail, and an obsession with becoming an expert in one thing, that you need to honestly assess if you have. In those cases, your learning phase should be more structured.
B) Implementation Phase
In the implementation phase, I think you need to be more strategic. I've started planning and learning more strategically, thinking about what Google is focusing on, like generative AI. I’m interested in it as well, but if I'm being completely honest, there are other things I'm interested in too. I'm choosing this because I think it's going to boost my career.
So during the first phase, chase what interests you and decide what type of engineer you are. If you're going to be a core engineer, you can go really specific, but be careful not to choose something that's going to become obsolete. It's better to go a little broad, especially because in that first phase of your career, you're still learning.
In the second phase of your career, you start to take bets. You start to trust yourself and your ability to say which way the wind is blowing, and you take bets on what you learn according to what will improve your career.
2. Approach to Upskilling
I personally like to do side projects - there's a business that I've set up, and for that, I learn what I need to learn to make that business grow.
What that does is it creates a learning system that works for me, which is that I want to learn exactly as much as I need to solve my problem and then solve it. When I get stuck, I learn a little bit more. My learning tends to be very targeted.
At Google, we were building a solution in the retrieval augmented generation space. The system fetched data to use within an LLM to answer user questions.
However, the latency was high because the data retrieval layer, also using an LLM, was very slow. I researched and found that state-of-the-art solutions use vector databases. Luckily, my previous experience with NLP had taught me about embeddings and word vectors, so I learned enough to solve the problem.
3. Learning Resources
In the above case, it was a Medium article. I read the Medium article on vector databases, it recommended a few types, I went and tried that tutorial.
Occasionally, when a topic is complex enough, like generative AI. I did take one course and walked through a tutorial where the instructor created an LLM from scratch. But this is like a 45-minute video, and that's it. There is some base that I build, but after that, it's straight to the problem. Now, I will say that a lot of people I know don't do it this way. There are a lot of more diligent people - they read the documentation completely, they understand the problem, and then they implement it. Frankly, those people are incredible. If you are like that, then that is a great approach.
Be honest with yourself about whether you really are that person or not. I think a lot of people think they're that kind of person, that they want to know everything.
But when I actually see them in practice, they start reading or start doing a course that's like two months long, and then they never finish it, and then the whole project gets abandoned.
I would say 80% to 95% of people fall into that category. Try to avoid this.
Qualities of 10x engineers
Natural talent is definitely one factor that separates the great engineers, I'll give you that. Some people just naturally pick up on technical stuff faster than others. But here's the thing - you can't just rely on raw talent alone. It'll only take you so far before you hit a ceiling. I know for a fact some engineers will never progress beyond a certain level because of this.
"But you know what’s the biggest differentiator? Continuous learning."
Great engineers understand this basic truth - the second you stop actively learning and expanding your knowledge, you stop growing as an engineer. Period. It's that simple but also that crucial.
Great engineers have also figured out what type of learner they are.
Do podcasts work best for truly absorbing info? Or do they kill it with online courses? Or do they need to really dive deep into documentation? They know what learning styles click for them.
They're also self-aware about whether they need to understand every single little detail, or if they can operate more at a higher, bigger picture level. There's no right or wrong approach, they just know themselves.
What advice would you give someone to become a 10x engineer?
1. Focus on your strengths
It's really important to learn where your true strengths and interests lie and focus on those areas. A great research engineer is probably not going to be great at systems engineering, for example. Don't try to be something you're not suited for.
"Here's the key - you can be extremely technically skilled, but if you continuously make poor choices about what to specialize in or get stuck on outdated technologies, no one will see you as a valuable engineer. The intangibles like intelligent decision-making on where to invest your expertise are critical. You have to stay relevant."
2. Never stop learning
Never stop learning - podcasts, courses, reading docs, whatever works for how you best absorb information.
3. Figure out what kind of learner you are
Figure out if you're someone who learns by just going surface level and getting the gist, or if you really need to go hardcore into the nitty gritty details by reading manuals and such.
For me personally, I've realized I'm okay without always knowing the low-level specifics of how everything works. But I know other engineers who need to understand it all at the absolute lowest levels. And that's an amazing type of engineer for sure.
4. Find out what role fits you
In the end, it really circles back to knowing yourself - what type of engineering role fits your brain and working style best?
Those are probably the three biggest points - talent, learning style, and self-awareness.
How do you think companies can retain these engineers?
So this is one area where the FAANG companies have nailed it. I didn't fully appreciate how well they do this until I joined one. At pretty much every other company I worked at previously, once an engineer reached a certain senior level, they started getting forced into a lot of management responsibilities and non-engineering work.
You become an Associate Software Engineer, Senior Software Engineer, Staff Software Engineer, and so on. But somewhere around that Staff level, a lot of companies make you start taking on larger teams, continuously growing the size you manage. Your actual engineering work gets diluted by all the people management tasks.
But the FAANG companies are incredible at identifying the engineers who just want to keep leveling up in their deep technical craft. They let those engineers climb the ladder, taking on harder and harder technical problems, while still giving them leadership-level compensation and benefits. An engineer at the very highest levels like L7, L8, and L9 gets paid the same or more than equivalent managers.
Now, here's the caveat - not every company actually needs engineers at that world-class depth. If you're just building out a basic mobile app without crazy latency, scale, or performance constraints, you don't really need an engineer who can optimize packet sizes by 10% through intense low-level work. There's no value in that for the product.
So first, companies have to recognize - do we truly need these 'great engineers' who live and breathe the most technically complex challenges. The reality is, while every engineer likes to think they fit that mold, those engineers are actually quite rare. They exist, but their talents aren't as broadly needed.
Joining FAANG
Do you think all FAANG engineers are 10x engineers?
At Google, I haven't come across a single bad engineer. The lower bar for engineering caliber is extremely high. Some phenomenal engineers didn't make it through the Google interview process for any number of reasons - maybe they got an unlucky question or had an off day. But it's incredibly hard for someone truly subpar to slip through the multiple rigorous interview rounds.
Google is clearly okay with having some false negatives in their hiring, as long as they avoid false positives and maintain that high engineering bar. So while not every FAANG engineer is necessarily an elite 'great engineer', the baseline competence level is very high across the board. That said, you also find them at smaller cutting-edge companies. Incredible engineering talent is everywhere nowadays.
So in summary - not every FAANG engineer is going to be a world-class 'great engineer'. But the baseline is very high, and you're unlikely to find any truly bad engineers there due to their rigorous hiring practices. The best engineers are at FAANG companies and top startups. But there's no single place that has a monopoly on great talent.
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?
1. On resume
I think, frankly, first of all, it's about getting your resume selected. If you know someone who has worked with Google, getting a reference is huge. But also, even if you don't, just having a resume that is going to get selected is a big deal. I think that involves building cool projects, writing a really good resume, and having people who know about these things.
And by the way, people who know about these things are not people like me. They are recruiters.
"Everyone thinks you talk to an engineer to know how to get hired at Google. It's not like that. It's about how to get to the interviews. You should talk to recruiters because they're the ones who get selected for that first step. Listen to recruiters, don't listen to engineers."
2. On interviews
The next phase is probably the most documented thing on the planet. It is almost like there must be a million courses and books on cracking the coding interview. For L3s and L4s, it's almost entirely about how you code. For L5 and L6, a lot of it is how you design systems and stuff like that.
If you haven't really, truly designed large-scale systems, you have very little chance of getting through that interview at the L5 or L6 level. I would say a good interviewer can spot someone who's just learned a course and not really built anything substantial.
I think that the system design part of it is something that you should spend a lot of time on. The coding - just do tons of LeetCode and you'll be fine.
3. Looking beyond FAANG
My ultimate advice is to focus on doing great work, not on joining FAANG. Because there are great engineers outside of the FAANG bubble too. And frankly, FAANG, for some engineers, may actually be a step down in their career.
I think if you prove yourself valuable, I have seen engineers at really small companies make salaries that are just as high or even higher than Google's because they become completely invaluable. They might have just built the company's whole system.
I promise you will never be that valuable at Google. Like, I think of myself as a good engineer, but it would make no difference if I left.
Ultimately, salary and a great career are about how valuable you are and what you're bringing to the table. So I don't think you should focus just on FAANG. Plus, if you start a great career, FAANG will naturally become an option. You will get those opportunities for sure.
Negotiating salaries in Tech
Don't overthink salary negotiations, especially at big companies like Google. Your initial negotiation might matter for a couple of years, but after that, it's all about your performance.
"If someone joins at a lower salary than you but consistently outperforms you, they'll end up making more money."
When negotiating salary, three things matter - leverage, negotiation skills, and perceived ROI for the company. Leverage, like having a competing offer, is the most effective. Negotiation skills matter somewhat, but not as much as people think. And demonstrating your value to the company has limited effectiveness at big companies where no one is irreplaceable, but can work well at smaller companies.
1. On research
First, do your research. Especially if it's a FAANG company, every single thing is documented. Know exactly how much they pay for your level in your location, on your team, everything. Sites like Levels.fyi and Glassdoor have it all covered. So you have no excuse for ignorance when it comes to salary expectations for your band. Use that information as a starting point. If you see that what they offered you is in the bottom part of the range, that's a way to make your case.
2. On discussing numbers
Next, a lot of people say don't make the opening offer. Frankly, with FAANG companies, this doesn't really come into play because they will almost always send you an offer first. But at a lot of other places, they'll ask you what you're expecting. As far as possible, don't answer that. If you're forced to, here's how to handle it:
The answer I've used in the past is something like, "I am still doing my research about this role and exploring my options, so I wouldn't feel comfortable setting an expectation on salary at the moment. If you have a number in mind, I'd be happy to hear it and discuss it further." Basically, you're saying you're not ready to give a starting point.
Why is this important?
If you provide a number, you've more or less provided a ceiling for the negotiation. Like if you say 10 lakhs, why would any company pay more than what you asked for?
Now, if you are forced to come up with a number, here's what I recommend. A lot of people make the mistake of giving a range. They think if they say 10 to 15 lakhs, people are going to hear 12.5. But in reality, if you give a range, the only thing they're going to hear is the lower end. Just say a single number.
4. Have clarity on your experience
When you pick that number, do your research about what's reasonable. If it's a FAANG company, it's super easy to find this info. If it's a smaller company, at least understand what the ballpark is for your years of experience. A rough guideline is:
→ 0-3 years: Software Engineer 1
→ 3-6 years: Software Engineer 2
→ 6-10 years: Senior Software Engineer
→ 10-15 years: Staff Software Engineer
After that, the levels differ more between companies. But those are good ballparks for the first 15 years of your career.
My overall advice on negotiation? Try not to give the first number, but if you have to, do your research. But ultimately, don't stress too much about it. Doing great work is what matters most. In engineering, perhaps more than most fields, you'll get what you deserve throughout your career, if not immediately.
Assessing Job Offers: Beyond Salary
How do you assess multiple job offers beyond just the CTC?
1. Learning
In the first phase of my career, I prioritized learning above everything else. Every single choice I made was based on where I thought I would learn the most.
There were three times during that period when I actually chose offers that were lower in salary because I thought I would learn more at those places. In one case, it was 20% lower, and in another case, it was about 30% lower.
But you know what? In every single one of those cases, my salary ended up doubling about two years later anyway. So it made no difference in the long run. Learning is the biggest thing, especially early in your career.
2. Growth
The second factor that matters throughout your career is growth. Whether you're in the early learning stage of your career or the later implementation stage, growth is always the second biggest consideration.
3. Passion
And then third is how much you love what you do. Are you passionate about what the company does? Talk to people who actually work there. Are they happy as engineers? There can be massive cultural differences even within FAANG companies.
In some companies, like Amazon and Facebook, there can be quite significant differences based on the specific team as well. That's not as true for Apple and Google, I would say, especially not for Google. But for Facebook, I've heard completely different stories from people in different parts of the company. So it's really important to try to talk to as many people as possible to get a sense of the culture and the day-to-day experience.
4. Work-life balance
The last set of factors are things like work-life balance, perks, how convenient the location is for you, and other personal considerations like that.
But if we're talking purely from a career perspective, I think learning, growth, and passion for the work are the top three things to consider beyond just salary.
Of course, everyone's priorities are different, but that's how I would think about it based on my own experience and what I've seen work well for others.
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?
When it comes to choosing between a promotion vs a new job, most of the factors I mentioned earlier still apply. But promotions are an interesting case, especially if you're at a company where promotions are respected and well-understood in the industry.
For example, if I know someone at a FAANG company has been promoted from, let's say, SDE 1 to SDE 2 to Senior SDE, I know a lot about what it takes to achieve that. The specific levels matter too. Getting to Principal Engineer at Amazon or Staff Engineer at Google - I know what those milestones represent.
Each of these promotions is really understood by the industry and by the people in it. So if you're in a position where you're close to a promotion, I would say stay and get it. There's almost never a case where you should walk away when you're on the cusp of a promotion.
The only exceptions would be if there are some unique circumstances. Like if you're really unhappy in your current role, or you need to move for personal reasons, or you have an opportunity to join the next OpenAI or something incredible like that. But except for those kinds of situations, I think walking away when you're close to a promotion is a mistake.
Here's why: Your career progression, as shown by your title changes, will stay on your resume forever. Jumping from company to company and going from, say, SDE 2 to SDE 2 tells me something. It tells me that you probably did well enough in interviews. It tells me that you've done decently and gotten okay ratings.
But actually getting promoted - that's a big deal. I know exactly what the bar is for those promotions, and a lot of other people in the industry do too. It carries a lot of weight and says a lot about your capabilities and your trajectory.
"I'd say the promotion should take precedence in most cases. Stick it out, get that recognition and that stamp of approval, and then you can always consider other opportunities with that enhanced credential under your belt."
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 seen burnout in others and have come close to it myself at times, but I may not be the best person to answer this because I don't take my job too seriously. People who put a lot of pressure on themselves and lose perspective that it's just a product are more vulnerable to burnout.
Qualities that make a good engineer, like conscientiousness and ownership, can also make you more prone to burnout if taken too far. I've seen this more among women engineers, possibly due to biases and stereotypes they've had to overcome.
Burnout happens when you feel like what you're doing is difficult and not going well, and when things are going wrong. Every good engineer has caused a screw-up at some point. Some people, including myself, don't get too stressed about it. You need to build that resilience and perspective.
Burnout can also happen when you're working hard because you're conscientious, but you don't believe in what you're doing. I've worked long hours without burnout when I'm excited about the work.
"Remember not to take things too seriously - you're not performing liver surgery. And sometimes, burnout is a signal that you're not working on something worthwhile.
In those cases, consider making a change - move to a different company, team, or role.
2. Maintaining work-life balance
For me, work-life balance is less about how much time you get and more about how completely you disconnect. I recognize that my advice may come from a place of privilege in terms of where I work.
A) Off the job
Sleep is super important to me. I sleep 8 hours a night and don't compromise on that, no matter what. I've even turned down meetings with senior people if they conflict with my sleep schedule.
I don't pick up my phone in the morning until I've done my morning workout, written my to-do list for the day, showered, and I'm ready for the day. Only then do I let the work noise in. I wake up with an old-fashioned alarm clock and have protected "me time" before diving into work. It doesn't have to be something hardcore like the gym - it could be a walk or reading. The key is having a routine that's completely yours, unaffected by the outside world.
B) On the job
At work, I set times when no one can schedule meetings with me, so I can focus on deep work. And when work is over, I don't open my laptop and no one can contact me, except for rare on-call duties.
And finally, whether at work or outside of it, truly disconnect during social interactions. Be fully present in those moments.
