I'd start by asking yourself *why* you want to work more:

- Is there a **hidden belief** that you're not as good as others?
- Are you trying to take **pressure** off yourself by giving yourself more time?
- Do you just **love your job** and want to contribute as much as possible?

Whatever the answer is, look for the *right* strategy. 

- If it's a limiting belief, work to address that first. 
- If it's the pressure, work on understanding your manager's and team's expectations. Is the pressure real or in your head?
- If you just love doing work, then it's up to you how much of your personal time you want to give to your job.

But, remember that **working longer ≠ more productivity** or higher confidence. It isn't a sustainable long-term strategy. At best, it's a short-term patch.

### My experience

I've been guilty of using this myself. In most cases, I regretted it because I was mentally trading - my time and freedom for some prize I wanted in return (promotion, raise, etc.). In most cases, I didn't get that prize.

The few times that I didn't regret it when I just wanted to help out my team before a big project launch. I didn't expect anything in return. I just wanted to be a good colleague.

Whatever you decide, good luck!

Senior Engineer @ Amazon, Founder @ Roman Yusufov Coaching

Roman Yusufov

This is a case where it's even more important to build a brag sheet and document your accomplishments. In the absence of a title to reflect your scope of work, you need to have solid metrics to back up what you did. \
\
This may require a more involved discussion with recruiters down the line, but I would prioritize skills and growth, especially as an entry-level engineer. It's much easier to "catch up" at your next company if you have the skills without the level than having the level without the skills.

Since you're a Senior Engineer, I'm going to suggest something a little different:

***Start with the business needs first.***

Here are a few questions you can ask:

- What is the impact of the technical debt on the business?
- How does it affect the ability to deliver new features?
- What direction does the business see for this product (in the current iteration)?

In my experience, there are a few scenarios you might find:

- The product is stable but hard to expand.
- The product takes a lot of effort to keep stable.
- The product is on fire.

### The product is stable but hard to expand

This means that new features take a long time to build and deliver. Quantify the value of this to the business (dev hours, lost $$, etc). Look for the largest bottlenecks (most modified areas in the code) and propose a project to improve them. Tie the business value to this project. Talk to your manager/lead, prepare an estimate of work and volunteer to lead the project.

### The product takes a lot of effort to keep stable

In this case, you're handling lots of customer issues. A big chunk of development effort goes towards fixing bugs (which means $$). This is unsustainable in the long term.

I'd recommend a two-pronged approach:

- Start by contributing toward making the product better. This means fixing bugs and being a team player. But, don't stay here for too long...
- Look for patterns when you work on bugs. Identify ways to fix things systemically.

Your goal as a senior engineer is to force-multiply and make things easier for others. So, focus your effort on where you can deliver the most impact.

### The product is on fire

I've worked on a project like this before. The technical debt and bug backlog were impossible to overcome. Counterintuitively, in these cases, you want to *stop* spending all your time on fixing bugs. If you don't do this, you'll never dig your way out.

As a senior engineer, your goal is to communicate this technical reality to your manager and business team.

In our case, we ended up mass-closing all older tickets. For newer tickets, we categorized them by impact and started addressing the root cause. If this meant rewriting a particularly buggy module, that's what we did.

Doing this will help you stabilize the product quickly so that you can move on to the above approaches.

In all of these cases, your goal isn't to rewrite everything wholesale. But, you also don't want to just chug along one ticket at a time. Rather, focus your time on impact and business value.

I know it's an old thread, but I wanted to add another perspective:

**Writing**

- Writing is a form of communication. The biggest mistake people make is not tailoring their communication to the audience. The way you communicate to a junior, your manager and a PM will be vastly different. This includes any writing that will be consumed by these groups.
- How do you build this skill? Ask. Ask your target audience what they care about. Make a list of guidelines. Then do your writing. Ask for feedback and iterate.
- If you're doing technical writing, it helps to think about layers of abstraction. The single biggest mistake engineers make is diving too deep into details too early. So, for a technical design, you might have a high-level summary, followed by high-level design and low-level design.

**Clean code structure**

- A lot of this comes from experience. But a good place to start is looking at where *you* get hung up when looking at someone else's code. What are the areas that cause the most confusion? 
- Then, do your research on best practices. Ask more experienced engineers or look around online for ways to address these areas. Then implement them.
- Ask for feedback. CRs are a great way to learn to write clean code. Try to tag people on the team whose coding skills you respect.
- Lastly, there'll be a good amount of trial and error. There are techniques I used as a new grad engineer that I wouldn't bother with as a senior engineer. Simplicity always beats complexity.

**Showing off your work**

- The best way is to take the focus off yourself. Make it about the impact and results. What is the impact of your work that someone else cares about?
- For example, if you want your manager to pay attention, find out what makes them look good and what they report to their manager. Then look for how your work affects that metric and give them an easy way to tie your work to that metric. Your name will naturally come up.
- Within the team, participate and/or create processes for everyone to showcase their work. Many teams do sprint demos just for this purpose. Again, make this about the team, not showing off *your* work. 

**Right amount of testing**

- I agree with Alex's answer. The amount doesn't matter as much as the goal. Numbers like code coverage aren't that meaningful. It's about the combination of different testing methodologies (like unit tests, integration tests, load tests, and regression tests) and how they validate important dimensions of the software.
- At the launch of new software you should have coverage in all of these areas. How involved each area is depends on the system under test. Testability can also drive the design of software. It's much easier to test smaller components with clear interfaces than large complex systems.
- This also depends on the size of the company and business goals. The "move fast and break shit" mentality of startups will reflect differently in testing than the "maintain customer trust" mentality of established companies.

I spent four years as a Bar Raiser. The basic idea is that Amazon is a *huge* company with many teams and interviewers with varying experience. But, the company has a goal of constantly raising the bar on the quality of its employees. So, in principle, if you look at the employee pool for each job family 10 years apart you should see a significant increase in the quality.

Interviews are the gate-keeping process that lets new engineers into this pool. So it's important that someone is enforcing the quality of hiring decisions. That's where the Bar Raisers come in.

**Mindset**

We undergo six months of training that helps us get really calibrated on what a bar-raising candidate looks like. This means not only interviewing engineers but also across other job families. A big part is understanding the Amazon Leadership Principles and how they're applied across the different levels at the company. For example, an L6 engineer and an L6 PM should exhibit similar leadership skills. Bar Raisers can spot these even in different contexts.

**Responsibilities**

In practice, Bar Raisers run the loops at Amazon in partnership with HR and the Hiring Manager. They help make sure the right competencies are being covered by the interviewers, that there's no overlap across interviews and the right data is being collected to make a good hiring decision.

They also lead the debrief process where all the interview notes are reviewed and a hiring decision is made. They don't *make* the hiring decision but instead, make sure that data is interpreted correctly and everyone else arrives at the right hiring decision. In rare cases, they can exercise a special veto power to make sure that a bad candidate isn't hired.

**Candidate perspective**

From your perspective as a candidate, it actually doesn't matter if your interviewer is a Bar Raiser. Bar Raisers are just really good interviewers. They know how to ask better questions and create a better candidate experience. If you want to learn about my experience as a candidate you can read [this LinkedIn post I wrote](https://www.linkedin.com/posts/ryusufov_before-my-amazon-interview-my-anxiety-got-activity-7232416255658315776-9kSH?utm_source=share&utm_medium=member_desktop). 

Contrary to popular belief, Bar Raise interviews aren't *harder*. If anything, you should have a better interview experience and have a smoother process.

I get your frustration and wanting help in making a decision. But, I don't think someone else can tell you what to do. That'd be like someone else telling you who to date.

Instead, I recommend figuring out what's the best fit for you.

The first step is to understand what **you need**.

There are *competing priorities* like compensation, stability, growth and many others. So, do a simple exercise:

- Write down one-word answers for all the things that are important to you about your career (aim for &gt;5 but write as many as you can come up with). I listed some examples above.
- Order them by priority. If you had to choose, which ones would rank higher?
- Trim the list to top 5

Now that you know your top 5 priorities, evaluate your options against them. Write down the option that's the best fit. 

If there isn't an obvious choice, ask yourself: "What does my gut say?"

The key is to articulate to yourself why you're making a decision. Then, if something comes up in the future (like a layoff), you don't have to second-guess yourself. Instead, you can use the new information to make a better decision next time.

It's more about the feeling rather than the number. Do you feel mostly ready? Can you answer most of the practice questions (technical and non-technical) even if you're not fully comfortable answering them? 

There's usually a big difference between "hell no, I'm not ready" and "maybe I'm ready". If you're in the latter bucket, start interviewing. In the worst case, you'll learn you're not as ready as you thought. But, most likely, you'll find things that you haven't thought about in your prep.

One example for me was that when I had my Amazon phone screen, I also had a PayPal phone screen earlier in the week. I didn't pass the PayPal one. I realized that was because I had too much stuff going on that day and I was out of energy by the time I got to the interview. So, I was able to tweak things for the Amazon interview and make it to the next round.

I would avoid or minimize anything that makes you feel groggy or sleepy or stimulates your nervous system (i.e. sugar and caffeine). 

Instead focus on small, balanced meals. Here are some guidelines:

1. **Eat whole foods** - think foods that come directly from nature (e.g. apples or fish) rather than made to resemble those (e.g. candy apples and fish crackers).
2. **Avoid processed foods** - most things you buy at the store are processed (e.g. bread or sliced meats or apple pies).
3. **Drink more water** - the recommendation is 9-13 cups a day. Drinking water also helps temper hunger.
4. **Eat "balanced plate" meals** - 1/4 plate lean (non-fatty) protein, 1/4 plate is clean carbs, 1/2 plate raw or lightly cooked green veggies and 1 tablespoon of healthy fats (olive oil, nuts, avocado). This is much easier when cooking for yourself. But when you have to eat out, try to match this formula.
5. **Avoid high GI carbs** - the glycemic index shows how quickly carbs convert into sugars. It's also an indicator of how quickly they are digested. High-GI foods digest quickly and give you a quick energy spike followed by a crash. Bread, white rice, potatoes, pasta and desserts all have this effect. But oatmeal, sweet potatoes, brown rice, quinoa and other grains fall lower on the GI scale. So if you want sustainable energy, opt for low-GI foods. They also happen to be the less processed ones.
6. **Don't eat away your emotions** - this isn't a dietary tip per se but many people fall victim to emotional eating. The most common is boredom. But it could also be frustration, fatigue or disappointment. When you want to reach for food, ask yourself if you're actually hungry. If not, get up and go for a walk instead. Getting some movement in is great for releasing emotions. 

Is your directive to use GenAI more or to improve efficiency overall? A lot of companies get over-excited about GenAI as the end-all solution to their problems. But, it's important to use the right tool for the job.

I would start by focusing on the problems. What friction do the company and its developers currently have? What are the highest-impact areas for improvement?

Then, find the best way to make those improvements. Maybe it's a process update, maybe it's building automation tools and maybe it's something else. GenAI may be helpful in some cases but not others.

If you wait until you're 100% ready for interviews, you'll never interview. I recommend aiming for 70-80%.

Most people think of a job search as a two-step process:

1. Preparation
2. Take and pass interviews

But #2 should be a part of #1. There's only so much prep you can do on your own. Practice makes perfect. So use interviews to perfect your interviewing skills. Go from "I need to pass this interview" to "I'm going to learn and grow from my interview."

Here are some other things to keep in mind:

- Interviews aren’t a test and you’re not a student. They're not pass/fail.
- Treat interviews like you’re working with a colleague.
- Be collaborative. Don’t try to impress.
- Assume the interviewer is on your side.
- You can’t pass all interviews (even if you’re really smart).
- Doing your best = #winning

Make doing interviews less meaningful. It's like going to the gym. One workout (good or bad) won't make or break your long-term goals. The less significant interviews feel the easier it is to do more of them. This decreases the pressure and increases your chances of success.

From recent conversations I've had with other engineers, this seems like the new reality of the tech industry. Being good enough is no longer enough. You have to meet quotas and jump through other hoops.

It sounds like you're already doing the right things that are within your control. So, I would encourage you to explore the following questions:

1. Why is getting a promotion so important to you?
2. What will having this promotion enable you to have or do?
3. How can you start doing some of these things today?

It's important to allow your emotions to come up (whether it's disappointment, anger or something else) and have healthy ways of processing them. Answering the questions above will help you identify your unmet needs and look for ways to address them.

**My experience**

When I was up my Senior Engineer promo a few years ago and didn't get it for Nth time, I was pissed. When I reflected on why, I realized that I felt my effort wasn't recognized, that I was falling behind salary-wise and I was tired of my current work but kept sticking around so I could cross the finish line. What helped me was three things:

- My manager told me how much he appreciated my work and that it wasn't about my effort.
- He also got me a 10% raise (equivalent to a promo) even without the promo.
- Switching teams where I could work on something new that rekindled my passion

Kudos to you for seeing the "rat race." Many engineers in FAANG reach a point where they realize that more money and titles won't make them happy. It's a luxury not everyone gets. For most of our careers (and lives) we're trained to pursue the next shiny thing (promotion, pay bump, etc.) but it reaches a point of diminishing returns. We're lucky enough in FAANG to reach this point before the end of our careers.

I would take some time to reflect on your life and career values. Things like what type of work you want to do, what impact you want to have, and what qualitative aspects you need (freedom, work/life balance, etc). 

Write them down and prioritize them. Then, evaluate your options from this lens. The right option will become obvious pretty quickly.

The best way to answer this question is to look at job postings. They should have specific requirements for each role. As Alex said, there's variance *across* FAANG companies and even in roles *within* each company. 

**My experience**

As someone who's interviewed 100s of candidates at Amazon, I can share my perspective for Amazon specifically. These guidelines should extend to other FAANG companies as well.

Rather than thinking about skills and stacks, it's more helpful to think about roles. Historically, Amazon only had one general software engineer role. However, over time it's evolved into separate roles:

- Software Development Engineer (SDE)
- Front End Engineer (FEE)
- Software Development Engineer in Test (SDET)
- ML Engineer (MLE)
- and others I may not be aware of

**General SDE roles**

In the *general SDE role*, the **tech stack and language don't matter**. Even if you're hired for a specific team, there's mobility within the company. If you come in on a team using Java and then transition to a team using Ruby, you still have to be able to perform.

So, the interview focus is on fundamentals. Do you know how to code in any modern language? Do you understand important design patterns (like OOP)? Can you problem-solve? Do you understand system design and *some* specific technologies?

Here's an from an [example SDE posting](https://www.amazon.jobs/en/jobs/2739168/software-development-engineer-aws-console-mobile-platform): 

> Experience programming with at least one software programming language. 

Having said that, there might be specific teams that look for specific skills. For example, when the Alexa team was hiring for their device team, they looked for SDEs with hardware experience. But these are the exception, not the rule.

**Specialized roles**

In *specialized* roles, the **tech stack and language do matter**. This should be fairly obvious since the job responsibilities are different. For example, as a FEE, you're more likely to be working in frontend languages and frameworks like JS, Node, React etc. 

Here's an excerpt from an [example FEE posting](https://www.amazon.jobs/en/jobs/2692736/front-end-engineer-amazon):

> Experience using JavaScript frameworks such as angular and react

For the Microsoft roles you mentioned, I'd be curious if the pay was related to the language or the team/role that uses that language. 

One solution that hasn't been mentioned is to *ask for* higher-impact work. This may sound simple but you can't get something if you didn't ask for it.

What might this look like in practice?

First, **talk to your manager** about wanting higher-impact projects. But, more importantly, be specific and tie them to your strengths. So, if you're an expert at fine-tuning high-throughput databases, you would ask to be included when your expertise is needed.

If your manager isn't able to just give you this work, go to the next step.

Secondly, **get involved in projects earlier**. Start participating and contributing to more projects earlier in the development phase when possible. You could ask to sit it on a product requirement meeting or a design review.

The intent is to learn more about the product and contribute where you can. But, the more you do this, the more visibility you have. When it's time to distribute the work, you're more likely to get it if you're already familiar with the project and contributed earlier in the process.

Lead with **curiosity**. Honing the skill of identifying shortcomings in systems comes from experience. It's not necessarily about going and analyzing every system your team owns. 

Instead, start by *doing*. Write code. Attend design reviews. Look for areas where you are struggling or have questions. 

The mindset of a Senior Engineer isn't necessarily about finding flaws. It's about thinking systemically. 

- Improving common processes that affect productivity.
- Looking for system complexity that slows down the development of new features.
- Paying attention to the non-technical problems identified by leadership and how tech is contributing to those problems.

If you start with the problem first (team, business or customer) it's easier to identify the technical fix/solution. You have a Northstar to guide your decisions.

I think the wording of those items is a little hard to understand. Here's how I would translate these into plain language:

- What did your team and organization look like? Were you working with one team or multiple? Who did you have to influence to make progress?
- What were your contributions? What role did you play specifically? Focus on the most impactful items first. E.g. if you were the team lead, lead with that rather than the lines of code you wrote.
- How was the project delivered? Were there delays? Were there challenges you had to overcome? What was the quality of the deliverable itself? Did it trigger a bunch of high-severity events?

### A different perspective on behavioral interviews

In my experience with doing over 300 interviews at Amazon, it's inefficient to ask *open-ended questions* like "Tell me about the most challenging project you've worked on". \
\
As an interviewer, my goal was to get *specific data points*. Generic questions may or may not get the data I need.

So, good interviewers will ask more pointed questions like "Tell me about a project you had to deliver against a tight deadline" and focus on specific soft skills like "delivery" and "ownership". 

The following is the formula I recommend for behavioral questions:\
\
**Soft skills + scope + impact + relevance = yes!**

*Soft skills* - demonstrate the soft skill the interviewer is interested in. In other words: first, answer their question. Then, weave in the other aspects below.

*Scope* (used for leveling) - show that your work was at the right scope/complexity. This includes technical and non-technical complexity (e.g. dependencies, influencing decisions, etc.)

*Impact* (used for leveling) - show that your work had the right impact. This could be team, business or customer impact (e.g. a tool used by 10 developers vs a feature used by 100,000 customers)

*Relevance* - make your examples relevant to the role you're applying for. Frame your experience to showcase the value and impact you can bring to the new employer (e.g. if you've only developed mobile apps but the job is backend development, focus on transferrable skills and aspects of your projects).

We all have unique working styles and personalities. So, I'd start by looking at which of the following you struggle the most with:

- Balance
- Discipline

If you struggle with **balance,** you need better *boundaries*.

If you struggle with **discipline,** you need more *structure*.

So, what does this look like in practice?

### Ideas for better **boundaries**:

- Having clear start and end times for your workday
- Create a "transition" between work and home life. This could be brain-dumping your work tasks, doing a short meditation and taking some time to decompress.
- Keep work email off your phone and leave your laptop closed outside of working hours.
- Take frequent breaks. I like using a Pomodoro timer for a 5 minute break every 30 minutes.

### Ideas for more **structure**:

- Have a dedicated workspace. Physical separation will keep distractions away.
- Keep your phone on silent during the workday.
- Timeblock everything. Set aside time for dedicated coding work.
- Set clear priorities at the beginning of the day. Pick one or two tasks at the beginning of the day and them before everything else.

### Ideas for all working styles

These are the things that I've personally found useful:

- Dress in "work" clothes. It doesn't matter what they are but wearing different clothes to be camera-ready gets in me into work mode.
- Walks outside every day. I find feeling the sun on my shoulders to be crucial for my mood.
- Balance out the mental work with activities that feed your emotional, physical and spiritual sides. This could be going to the gym, conversation with a friend, virtual lunches or meditation. You have to be more intentional about adding these when working remotely.
- Spend time away from screens. This includes all screens - TVs, phones, etc. Create time for your mind and eyes to decompress.

At the end of the day, it comes down to feeling into what you need in the moment. Some days you may need more discipline. Other days you may need more balance. Feel into what you need and use the tips above as a guide.

Getting to SDE3 was one of the *hardest* steps of my career. It ultimately took *4 years* to get there from the time I was hired. I went through a lot of frustration because I either didn't understand the process, didn't have enough buy-in at the start of projects or had to navigate circumstances outside my control (descoped projects, canceled roadmaps, etc).

So, I wanted to share some things I learned along the way.

There are a few key things that need to align to get the SDE3 promo:

1. **Being a solid SDE2 performer.** Work with someone you trust to assess your readiness for the next level. I personally struggled here because I tried to get to SDE3 while I had significant gaps to fill at SDE2.
2. **Having a good manager.** This isn't always within your control but I believe a good manager is responsible for up to ***40% of your promotion success***. Promotions at Amazon are manager-driven. The groundwork starts long before your promotion panel. There are two parts to this:
   1. How experienced and comfortable they are with the promotion process. They have to line up the projects, get stakeholder buy-in, write the promotion doc and ultimately advocate for you in front of the review panel. I've seen multiple botched promotions where the manager was either underprepared, failed to gather the right data or wasn't confident enough when challenged by the panel.
   2. The quality of the data they're able to gather to support your promotion. Part of this comes from you. You have to provide the right quality, delivery and performance metrics of your projects. The rest comes from them gathering the right feedback from key stakeholders and their own assessment of your performance.
3. **The right scope of technical work for SDE3.** This is one of the most challenging parts. Unfortunately, there's no magic formula for this. But, there are a few things you can do to help yourself in this process. \
   \
   First, you need to understand what SDE3 scope looks like. You can do this by reviewing designs from current SDE3s, talking to more senior engineers and getting feedback from your manager. \
   \
   The next step is finding the right scope project. This is where most people struggle. Below are some ideas but by no means an exhaustive list:
   1. Finding the right project in the existing roadmap. You can work with your manager to assess the complexity of planned projects and which ones will fit the SDE3 bar.
   2. Finding projects that can be expanded in scope. The right scope can come from the way you deliver a project and not the initial set of requirements. Even with limited initial functionality, you can propose a bigger technical vision that can support the future expansion of the product. You don't have to deliver on the whole vision to get credit for the design. The key is to keep the initial deliverable simple but showcase the considerations that went into making it scalable and expandable.
   3. Look for problems with large impact that no one else is solving. I've seen Principal-level projects dealing with metrics improvements. The difference was in how they solved it. Instead of solving the problem for a single team, they solved it for the whole company.
   4. Networking with other engineers and managers. If your team doesn't have the scope you need, you want to be on the radar of other teams that may have the right scope. This requires visiblity into other teams.
   5. There's a "hidden" option that I'll discuss in the bullet point on documentation.\
      \
      Lastly, make sure to get any proposed project vetted and approved *before* you start it. This is ***crucial***. When I was still at Amazon, there was an official process for doing this (although it wasn't required). This will save you a lot of frustration dealing with last-minute disagreements about scope.
4. **Demonstrating LPs at the L6 level.** As you already know, LPs are at the center of all roles at Amazon. Having the technical skills and projects isn't enough. You need to demonstrate the key LPs required at the L6 level. This includes Think Big, Are Right a Lot, Hire and Develop the Best, and Invent and Simplify. These are the major differentiators at the L6 level but all the others are important as well.\
   \
   SDE3 is a team lead role at Amazon (although there's no official team lead role at Amazon). You have to demonstrate the ability to deliver through others, force multiply and drive influence within and outside your team.
5. **Getting buy-in from key stakeholders.** This is a "behind the scenes" thing most people don't realize. Not only do you need other SDE3s to validate the complexity of your projects but you need other key L6+ stakeholders to provide feedback that you're operating at the L6 level. I forget the exact number (Alex's statement that it's 6 people may be right).\
   \
   But, the important part is that you have to demonstrate this through your limited interactions with these people. The stakeholders include PMs, TPMs, SDMs of partner teams and senior managers. The more the better. You can't ask for this feedback directly so you have to work through your manager to solicit and process this feedback.
6. **Having the right documentation.** You need a solid portfolio of work to demonstrate your growth. This is particularly important if you've switched multiple teams and projects as you're working on your SDE3 promo. Your manager won't have visibility into your past work. They will talk to your previous SDMs (if they're still around) but it's always better to create all the necessary documentation in real time than hope you can gather it later.\
   \
   There is also an option to get promoted based on "portfolio complexity" rather than individual projects. This is what happened to me. After working on multiple projects that didn't hit the complexity bar on their own, my manager was able to make a case for promo based on my portfolio of work. I hit all the right checkboxes in at least one of my projects.

There is a lot more I could say on this topic but I will leave it here for now. If you have any questions, feel free to post a reply.