Talk to people.

Make it a career-long habit to talk to *at least* two new people every week. Talk to Product Managers, Designers, Customer Support, Finance, Marketing, Sales, even (gasp) Legal.

In each meeting, ask them what problem they're solving and what their biggest challenge is.

Every business is designed to solve some problem. As a Sr. SDE, you only get to see a thin slice of the Problem Space. By talking to diverse people in your company you will build a more complete picture of the Problem Space. You will be able to *see* bigger problems.

And when the time comes to tackle these bigger problems, you'll already have relationships with the right set of people to tackle large projects.

As a remote engineer, you are not as far behind as you may think. Most engineers don't even think about talking to the marketing team. And if they did, they are often in a different office or location, so it'll be a remote meeting anyways.

Good luck!

Coaching Managers & Senior ICs | Ex-Meta, Amazon

Gilad Naor

Your first question is on pace and the second is on Impact. That's the wrong order.

Start with Impact and the pace will work out. Once you develop a good grasp of what work is valuable, be ruthless in prioritizing it. The engineers who are great at this have consistently high ratings, great WLB, and thrive for years on end. I'm talking IC4 and I'm talking IC8+.

The way to understand what work is valuable is the same way you learn the e2e infra. And it's not in any Wiki.

To understand the infra and to understand Impact, start by talking to people. Schedule some time with another human, chart out what you currently understand about the infra, then ask them to tell you all the ways in which you are wrong. Put 15m on your manager's manager's manager's calendar and ask them what success looks like for them. Or share what you're working on and ask them what an outstanding (GE+) outcome looks like from their point-of-view.

Finally, Boz has a great onboarding algorithm: <https://boz.com/articles/career-cold-start>

Wear hats. That's the secret to reviewing code.

The mistake that new engineers make is that they just read the code and throw on comments. Don't do that. Have a plan and a structure to how you review code.

When you read the code, wear a single hat at a time. Every hat is a single question that you bring into the review. Like the hacker's black hat of how to exploit the code.

Here are some other "hats" or questions:

- Does the code do what it says it does?
- Will this code be easy to maintain in a year? (Readability, single-responsibility, testability, etc.)
- If I wanted to break the code, how would I do it? (Edge cases, scalability, poison pills, etc.)

There are other angles, such as privacy, security, integrity, etc. But these are the basics.

Pick one hat, do a pass.

Then pick another hat and repeat.

You shared the "table of contents" version, so it's hard to know without the details.

Here's some advice:

- What, specifically, was *hard* about this situation? If there was no challenge, then it's not an interesting story.
- Once you identify the challenge, you can build your story-telling around this challenge.
- Collect "supporting evidence" for the challenge. Was your coworker more senior than you? Were you emotionally invested in your approach? Were they? How long did it take you to get to a conclusion? What specific steps did you take to make an informed decision? What was the Impact?
- Finish off with your learning. You mention that their approach made more sense. In what way? Why didn't it make sense to you initially? How are you a stronger engineer today as a result of this experience?

Your worry that the story is too simple and ends too cleanly isn't an issue if there was a real challenge.

The absolute worst thing that you can do is choose someone else's story. As an interviewer, I care much more about your answers to the follow-up questions than to the "tell me about a time..." question.

Good luck!

You should 100% choose fast-promotions as the objective-function for your career (based on four short paragraphs.)

You're just doing it for the wrong reason. Your manager is also wrong.

The advice "focus on growth and the promotions will come" is wrong for several reasons:

1. Promotions take a lot of work. Not on your end. There's a lot of paperwork and meetings and process to follow. If you focus on growth, promotions will *sometimes* follow.
2. Growth is too vague. You can grow in many directions. Companies don't appreciate and value all types of growth equally.

So here's my advice.

Flip your manager's advice around: "focus on promotions and the (right) growth will come."

To have a great career with 7-figure income, you *have* to specialize.

Just not in the way that you mean.

Let's take Meta's [IC7+ engineering archetypes](https://newsletter.pragmaticengineer.com/p/facebook-2):

- Generalist
- Specialist
- Coding Machine
- Tech Lead
- Fixer
- Systems Thinker
- Product Hybrid

According to [levels.fyi](https://www.levels.fyi/companies/facebook/salaries/software-engineer?country=254), these engineers make $1.34M per year on average.

The existence of the whole "archetype" concept itself is a clear hint that specialization matters. It's just not specialization in a certain technical stack. That thinking will point you in the wrong direction.

**You should specialize by how you deliver Impact.**

And this depends 100% on your strengths.

Your strengths are what you are good at, *and* what fills you with energy (as opposed to drain you).

So my advice?

Figure out what type of work you love doing. Then specialize in how to leverage this type of work to deliver outsized Impact.

Burnout is not about doing too much of something.

Burnout is about not doing enough of what empowers you.

If your goal is to avoid burnout, you should track what activities empower you versus what drains you.

Start simple. Pick one area of your life and track just this empowering/draining dynamic for a few weeks. Build your intuition first.

Once you can clearly feel the difference between what gives you energy and what steals it, you'll naturally start gravitating toward the empowering activities.

Track just one thing at a time. Do just one thing at a time. Multi-tasking is the silent productivity killer.