So many great answers here and in linked threads! 

Given the myriad dimensions of complexity in operating successfully at Staff, I like to think about these 4 key pillars: **project attributes, time horizon, personal traits, and workplace fertility** and the defining characteristics of each.

1. **Project attributes**: The attributes of a Staff-level project.
   1. **Impact** (highest weight): 
      1. Move key business or organizational metrics
      2. Unlock new revenue streams, or drives stability improvements at scale
   2. **Scope**:
      1. Changes affect 2+ teams or multiple systems/domains across functions
   3. **Complexity** (variable):
      1. Technical or organizational ambiguity and non-trivial decision paths

      *Impact leads. Scope follows. Complexity adds nuance when impact & scope are strong.*
2. **Time horizon**: Strategic ownership typically spanning 2–3 years.
   1. Steward long‑arc projects, roadmaps, and platform evolution
   2. Go beyond quarterly deliverables to multi‑year outcomes
3. **Personal Traits & Behaviors**: Your skills and operating style.
   1. **Ownership**: Drive work end‑to‑end, proactively find and solve hidden problems
   2. **Technical Vision & Stewardship**: Craft architectural north stars, align technical direction with business
   3. **Influence**: Secures buy‑in across functions without direct authority
   4. **Resourcefulness**: Navigate constraints, creatively unblock teams
   5. **Mentoring & Coaching**: Develop peers via feedback, brown‑bags, pair‑programming, and best practices
   6. **Business Acumen**: Anticipate product needs, tie projects to cost savings or revenue uplift
   7. **Storytelling**: Translate complex ideas into compelling narratives for diverse audiences—internally and externally
   8. **Communication** *(cross‑cutting)*: Scale insights, manage up/down/laterally, keep stakeholders aligned
4. **Workplace fertility**: Does your environment make space for Staff-level growth? Are leaders creating and protecting opportunities for technical leadership to emerge?

   *Without the right environment—including a culture of sponsorship—even strong engineers can plateau.*
   1. **Clear Vision & Goals**: Well‑defined organizational priorities to guide high‑impact work
   2. **Big Opportunities**: Significant, unsolved strategic challenges that need Staff ownership
   3. **Business Need**: A gap or pain point that only a Staff Engineer can fill effectively
   4. **Sponsorship Culture**: A track record of leaders who actively grow and advocate for Staff-level talent, including manager and skip-level support

      *Red flags:* No executive support for engineering strategy, no clear business priorities, narrow role definitions, or “just ship code” cultures.

I find this lens helpful as a simplified, yet holistic guide to excel at Staff level. Would love to know people's thoughts!

Mentor Coach for SWEs | Former Staff Software engineer

Shine Garg

I recommend focusing more on your previous work experience for two reasons:

1. More impactful work.
2. Your FE depth &gt;&gt; fullstack breadth.

> - Is it okay to talk about a favorite project from a previous company during behavioral interviews, even if it’s from over a year ago?

Yes, this is fine, esp. if you want to talk about an in-depth impactful project over a long time horizon. 

But you can also bring up smaller examples from your current job as well (for suitable questions) in the context of feedback, conflict resolution, etc to avoid raising eyebrows by not referring to your current experience at all.

> - Is there a “time limit” for how far back I can go when giving examples?

I like to stay within 5 years because that's about as far back as I can remember the details vividly. I think it's a bigger red flag to start with an example and then add that you don't remember it clearly :). I have seen my coaching clients bring up older examples when it's apt and they remember all the details.

> - And does it ever make sense to talk about recent backend work when applying for frontend roles?

Yes, this would be fine, esp. to augment your deep FE experience with some shallow BE knowledge and show your e2e understanding. But I'd keep the focus on FE since that's what you're interviewing for and appear to be more interested in pursuing.

What you're facing is not very uncommon. Having a robust hash map of behavioral interview signals to your stories and preparing ahead of time are recommended to avoid being caught off guard and making suboptimal decisions thinking on your feet.

As someone who's both thought about *and* implemented it :), I have this to say:

- What keeps most people from actually exiting is the prospect of losing their (big) paychecks since very few professions pay as much as tech. So the process is as much inner work and mental preparation as it is tactically identifying what to do next.
- The next hurdle is the saturated gig economy. Pre-pandemic, more than one generation never questioned why we work so much. But pandemic forced everyone to slow down and many people realized the freedom in being their own boss and setting their own schedule.
  - But to actually do it, you have to spend a lot of time on networking, marketing, and sales for your venture, which many hate. 
  - So, again, the actual work lies in preparing yourself to play these roles and learn their ropes. 
  - Being *very* good at your chosen profession is also important to have a differentiator and beat competition.
- The last step of course is to identify what to actually do. For me, I followed the aspect of my job that I felt passionate about and gave me the most satisfaction—mentoring engineers effectively as that was not happening for most people. 
  - Once you're OK with the first two points, looking within is what I recommend to identify your next career.

I hope this helps.

In terms of functional areas, I'd definitely learn distributed systems and AI and ML, esp. given that you're on the backend. 

To understand software e2e (without being a fullstack engineer), I'd also know a bit about big data processing and Typescript/JS.

In terms of programming languages, Python is here to stay and it makes a very good coding language for interviews.

Stack Overflow's annual developer surveys are great way to keep a pulse on trends: <https://survey.stackoverflow.co/2024/> and adjust accordingly.

I'd also read the front page of Hackernews.

Above all, I recommend making it a point to invest in yourself *consistently*. Half an hour every day after work or a few hours every weekend. You'd be amazed at how quickly it compounds and gives you an edge!

Like Alex said, internship &lt;&lt;&lt; Amazon as you don't know if it'll convert to an offer. But Amazon's culture is also notorious for PIP. You don't want to renege your internship offer only to be in trouble at Amazon! (The intent is not to scare you but lay out all the possibilities for a more informed decision.)

I'd think about where you have the best chances to succeed long term and go with that. If you manage to fit in both and get a full time offer after the internship, you'll be in a better position to decide.

If Amazon doesn't budge, is April the soonest you're available to work at either place? If not, would it make sense to ask Amazon to have you start sooner (in lieu of forgoing the internship altogether—and as a bargaining chip for reneging on your internship offer and choosing Amazon behind the scenes).

Another option to consider is picking up a formal mentee or informally helping your coworkers in a variety of ways. 

One low commitment way to do this is help them with ad hoc tech troubleshooting in areas you know well. It works well both ways because they find someone reliable to go to if they get stuck (and pick up new skills along the way) and you get to have a sense of fulfillment (and become a better teacher along the way).

Regardless of whether my projects were mission-oriented or not, one stand out aspect of my long tenure was the fulfillment I got from the mentorship my coworkers got from me! 

It sounds like you need *conversations* with Senior+ engineers about *practical* system design. 

You have covered a lot of standard study material. Where study material typically shines is telling you where technology X is applicable, for example where message queues or NoSQL would be applicable. 

What doesn't cover so well is where X would *not* be a good fit or the tradeoffs of using X vs Y when there's "no right answer." These practical considerations are hard to cover in educational materials and it's also hard for this coverage to be exhaustive.

It also sounds like lack of practical experience is at play here, to some extent, for example ambiguity on the appropriate level of separation of concerns in microservices. BTW, this is totally normal because complex, real life system design experience is both hard to gain and the opportunities arise later in career.

So, I'd encourage you to chat with someone with practical system design experience, be it from your work or outside community.

Let me know if you have any follow up questions!

Sure. I assume once you apply, a recruiter will reach out to you. I'd ask then and if you need more prep based on their answers, I'd schedule the interviews a few weeks out.

If you happen to use Confluence internally, they should have templates already. 

I also found [Inverted Pyramid: Writing for Comprehension ](https://www.nngroup.com/articles/inverted-pyramid/)useful.

Here are a couple of samples to look through for more ideas and comprehensiveness:

1. <https://rfd.shared.oxide.computer/rfd/0053>

2. <https://rfd.shared.oxide.computer/rfd/0110>

What you can also do is browse the internal RFCs and tech docs to find the good ones and think about what they do well. It's also fair game to reach out the authors and ask about their process.

This is something you get better at through practice.

Do you have an onboarding buddy there or another engineer that's also L5 or above? I'd build a relationship with them and leverage them to get a high-level view of the system and all the tooling etc that powers your specific team's features. 

It's totally fair to ask to set up time with them for an initial meet & greet + a get a high-level diagram of the entire system along with the plumbing tooling. At the end of the meeting, you can them if they'd be open to future meetings/questions, and you can use that to ask targeted questions later on. 

In my repeated experience, this approach is much more efficient than trying to figure it out on your own (and building up anxiety over low output along the way).

I'd also take extra time in evenings and weekends to ramp up on these peripheral tools and systems to get up and running quickly. I am not a proponent of bad WLB, but sometimes it's just the need of the hour, esp. when performance at new job is at stake.

I'd read <https://docs.oracle.com/javase/tutorial/essential/concurrency/>. 

I also highly recommend Joshua Bloc's Effective Java to build rock solid knowledge of the JVM internals

Building up on Elliot's answer...

Have you tried asking these questions to the recruiter? Recruiters want you to succeed at interviews, they are happy to prepare you for the best possible outcome. 

You can ask things like how many rounds of interviews, how many interviews in each round, what's the phone screen like, what's the onsite like, etc. 

You can also ask about the nature and level of difficulty of the coding and system design rounds—will there be LeetCode problems or other coding problems, if LC, then will it be easy/medium/hard. 

These are all fair questions to ask for targeted prep and nest chances of success.

It occurred to me to add a few more points here:

- Since your role must have coding to keep you happy, the TPdM option I mentioned before will make you a very strong contributor because the engineering team will be able to rely on you as a technical PdM as well as make code contributions from time to time.
- Another option would be to seek a Senior+ IC role at a large US-based company that has offices in India. FAANGMULA or adjacent companies tend to have a stronger culture of—and acceptance for—people staying on the IC path in the later years of their careers compared to startups where people can be younger and ambitious about climbing the corporate ladder.
  - You do *not* have to fit the bill of being a "star developer criteria with good ratings, promotions etc" to chart out this path for yourself. 
  - These companies definitely have many spots for reliable Senior+ engineers to make solid contributions and maintain a healthy WLB at the same time, like Alex said.
- In terms of what to learn, I'd say stay on top of most things frontend: both technologies and architectures, and form your opinions about them. I'd also learn how to mentor, and build interpersonal and leadership skills to elevate yourself to a mature and loved engineer others enjoy working with and learning from.

One factor you can consider is the history and track record of the field/program itself. AI is relatively new and very rapidly evolving, so many AI companies don't have a definitive future just yet. Yet others will be obsolete as AI tech evolves. AI is also here to stay, fueling innovation for new companies for time to come.

From what you wrote, the scholarship program seems to be well-established and a have track record of giving the recipients an edge. Unless you can apply again and have a great chance of being selected, this opportunity sounds more unique to me.

> My main concern is the risk of not finding a comparable job after the scholarship

If by "comparable job" you mean the AI company, there's also a possibility of finding something even better! I'd also take into account the skills you'll learn at the scholarship and how they'll strengthen your prospects down the line as opposed to evaluating your options based on where you stand today.

Basically, I'm recommending you see the scholarship as the start of a journey and leave the destination open. :)

I was hired at Staff (and that was first time with the Staff title). I didn't negotiate the title though—multiple companies leveled me at Staff after I interviewed with them. They were at a similar size and stage as my previous organization where I had the Senior title. 

To me, the fact that I secured multiple offers at Staff was proof that I was under-leveled at my last org. :) (Meta was also interviewing me for E6 but I cut the loop short after I accepted an offer.)

The first few months were very busy, with a combination of understanding the landscape and proving myself along the lines you mentioned. But it wasn't a problem as I had extensive experience at Senior, designing and delivering a large platform that cut horizontally across my entire previous org.

A few months into joining though, there was a reorg and I found myself reporting to a Director of Engineering (who was later promoted to Sr. Director while I was still reporting to him). His expectations for Staff turned out to be quite different from the previous manager I'd briefly reported to! 

So, we had some strategic conversations and the company sponsored coaching for me to work on the feedback. Since none of the feedback was about technical competency, I was able to turn things around within a few months—and even got the next raise.

This aside, I managed to be at the right place at the time in my Staff role, given the systems I got to build and the impact I had. Looking back, taking up this role was the *single biggest growth spurt in my entire career*!

If you're considering accepting another offer at Staff, I'm happy to chat about the specifics!

Another option I'd like to recommend in Technical Product Management (also known as Engineering Product Management). These folks typically sit in the Platform orgs at tech companies or are very valuable to deep tech companies. 

In Platform orgs, they talk to internal customers to help the Platform team build the right internal tools. For deep tech companies, they talk to other tech companies to source engineering requirements. 

In my observation, this role can be a great confluence of your engineering skills and product acumen, esp. if you feel passionate about building the right thing. It's also more grounded in technology than a typical Product Manager role.

Yes, email scraping would be the stickiest point that'd keep me from using this app (not saying this to discourage you but to highlight the extreme trust issue involved here). (Also, while GMail is ubiquitous, people use other email services as well.) 

When it comes to GMail though, you *could* try to use Google Apps Script that provides a [native integration](https://developers.google.com/apps-script/reference/gmail) with GMail. But you'll likely still need to wrap this up in your app, which takes us back to the original problem.

*The key finer point I want to make is this*:

Regardless of the tech and trust solution, you're converting highly unstructured data to structured data and applying heuristics to predict the stage of any particular interview. The stakes are quite high—mis-prediction can mess up the interview pipeline for a given company very badly!

So, I recommend that you show a snapshot of the email(s) that you processed to infer the interview stage in the UI, and give the user an easy way to correct the prediction made by your system.

Also, I know this is quite ambitious already, but a neat extension would be some scraping basic facts about the company and culture and presenting it to the user—homework that savvy candidates do manually today and hopefully take notes on as part of their interview prep. It can become rather time-consuming.

I'll be curious to know how this pans out!

There were periods of time in my Staff engineer role when my work day got extremely fragmented. Here's how I used 10-15 min blocks:

1. Read some code that was recently merged.
2. Familiarize myself with new Datadog dashboards to learn more about my own systems or adjacent ones.
3. Read TDDs/ADRs from adjacent teams that asked for my inputs or to learn about other systems at the company.
4. Catch up on eng-excellence type channels and read an article or two shared there.
5. Catch up on shipped type channels and take stock of the newly shipped features.
6. Respond to backlogged DM's with coworkers discussing topics of interests outside of the immediate workstreams.

You will notice that, in none of these tasks, I was actively accomplishing a parallel/competing task. OTOH, I was using this time to squash other myriad misc tasks that would otherwise keep me from focusing on my primary tasks. 

These tasks are "small" in nature, so they keep you from getting sucked too deep and losing track of your original task. Left unattended, these tasks pile up and create backlogged requests from others/anxiety/FOMO, all of which are detrimental to mental health—and erode the feeling of being "in control" of your surroundings.

As an entry-level SDE, your list of misc tasks will look very different, but the above list should give you an idea of what it should look like for you.

A few other finer points in what you wrote:

1. You mentioned "silly mistakes." Can they be avoided using a linter, etc?
2. Also, are you in the habit of doing a static walkthrough of the final version of your code before putting up your PRs? Doing this does take an extra 10-15 mins (or more depending on the size of the changeset), but it has almost always helped me catch typos, unfit variable names, incomplete comments, etc. that reviewers would otherwise comment on (and I'd feel bad about). Sometimes, static code walkthrough has helped me catch minor bugs that I'd missed in both logic and unit tests! *I can't emphasize the ROI on static code walkthrough enough.*
3. When multi-tasking, switching between multiple codebases is almost never a good idea as there's just too much context to carry in your head. Mistakes are inevitable. It also breaks your flow very badly if the different codebases are in different languages!

Hope this helps.

FWIW, I have used Java for interviews throughout my career and it served me well. 

I somewhat disagree with the notion of learning a language only for interviews—it's hard to know the language really well that way. 

At Senior levels in particular, sometimes interviewers do want to know your proficiency level in a specific language, esp. if it's directly used in the team. If you happen to run into an interviewer that is passionate about programming languages in general, they might get into the weeds of the language. It happened to me when a 20-year Java veteran grilled me on all sorts of Java internals that I thankfully knew and did quite well. 

If this were to happen, then coding in a language you learned just for interviews and using a different language for proficiency discussions can be a very big red flag.

Been meaning to follow up. It sounds like you need a combination of ruthless prioritization + delegation. That's hard to do through writing back and forth. But a lot of success I have had with my clients is by making an exhaustive list of everything they do and taking stock of the strengths and opportunity areas of their team members.

The exhaustive list will help you identify tasks that you can drop altogether, lightening your load. Knowing the strengths and opportunity areas of your team members will help you identify the tasks you may be able to delegate to them, thereby up-skilling them and lightening your workload.

FWIW, I do this routinely in my one-person venture right now and it's a high ROI activity. It's enabled me to build the right automations and drop/streamline by SOPs so that I can scale myself.

Good luck!

Second Rahul's point about Pulse. Culture Amp is another tool that measures the health of an organization through periodic surveys.

I've also said this elsewhere: the book, [Accelerate](https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339), is a great read on this topic from the lens of an engineering org. But just because this book exists, it doesn't mean that all engineering leadership buys into its research.

Also tangentially related: <https://www.jointaro.com/question/mTLUTf0BdeTht1WnYcjK/how-you-justify-an-engineering-team-is-strong-team/>

I want to provide a different perspective here. 

What are your medium and long term career plans after you switch to SWE? And what kinds of companies do you see yourself working at?

A focused SWE role is certainly more challenging than a DE role. But the challenge also multiplies many times over as you progress in your career, making it hard to be a competent, well-respected senior engineer. See my answer [here](https://www.jointaro.com/question/6HNrCxk6zVkbkE0JZgIk/what-counts-as-specialization/) on the pros and cons of specializing.

(The intent of my answer is not to deter you from switching to SWE but to encourage you to have a medium term plan post-switch first and use that as a guide for your next steps.)

One more thing about DE in particular: 

Having worked with many DEs very closely, their software engineering skills and knowledge of best practices tend to be softer than typical SWEs. Part of the reason behind that is DE is a newer field, the barrier of entry is lower, and one can get very far by using the relevant services offered by the public cloud like AWS as lego blocks to get the job done. Scripting things together is usually enough for plumbing.

But this is changing. With ever-increasing reliance on data processing for everything, the two fields are merging—increasingly, DEs have to write microservices and build the same SDLC components as SWEs. This is often called Data Platform (as opposed to Data Pipelines). So that's another role you can potentially consider to sit between SWE and DE and carve out your niche using the best of both worlds.

My friends in India have shared this as well and this imbalance in quite frustrating for the workforce there.

Is it possible for you to find a few hours in the mid-afternoon? I hear that things start to quiet down around 2-3 pm India time and don't pick up until 9-10 pm again. 

(Admittedly, this friend is not a developer and she's not raising a family either, so her way of carving out time for herself may not work for you.)

You should be able to take some TPM courses from MOOC sites like Udemy, etc. [This](https://www.cnbc.com/2020/07/13/google-announces-certificates-in-data-project-management-and-ux.html) (old) link might also link out to some options. Also check-out <https://www.pmi.org> 

One more piece of advice: have you tried to look at a few TPM job descriptions to glean the common nouns and verbs in the expectations? This exercise is usually quite helpful because it can enable you to come up with a list of signals that interviewers look for. Along with some tactical prep, these signals can help you construct strong stories for behavioral interviews as well, making you a stronger candidate.

> Does this apply to areas beyond languages and frameworks?

Yes! Some example areas of specialization can be Data Engineering, Machine Learning, Data Analytics, Frontend, Infrastructure, DevOps, Security, Mobile development, etc. 

Other types specialization can be in deep tech like storage technologies, networking, GPU optimization, etc. These are less common and typically happen at companies developing the next generation of databases, data warehouses, etc. Think Snowflake, Databricks, or even specialized divisions at companies like Meta, Google, Nvidia, et al.

These specializations also have varying degrees of coding skills required (something to consider based on your interest and intuitiveness).

Yet others are language and framework specific, like you mentioned.

**There are primarily two ways in which engineers come to specialize**:

1. Their first/second job is in one of these fields.
2. They choose to transition to one of these fields intentionally after being a backend engineer (most typically, although they can transition from Frontend or Fullstack as well). 

When engineers start out in their careers, they typically begin in backend, frontend, fullstack (or increasingly mobile too) because these areas have the most demand, but they are also vast, and nearly impossible to build mastery in. I say this from experience, having been a backend engineer for 16+ years! :)

This brings us to **the pros of specializing**: your chances of mastering one area are much higher than being a competent Jack of All Trades (backend engineers are also called "generalists"). Specialization focuses your efforts, builds up your expertise over time, and positions you well to excel at your job. Expertise keeps imposter syndrome away, and often earns you respect at the workplace because you become a unique value-add compared to a generalist that can be replaced more easily. 

**The cons of specializing** are that it restricts your surface area—you'll be able to apply for specific jobs only and work in teams that need fewer people. For example, a Security team is usually much smaller than the number of backend engineers a company hires. But I don't see this as a major problem because these specialized roles will be increasingly in demand (even though their nature will change with the advent of AI, for example).

It's usually a good idea to begin with a generalist role and learn the ropes of software development in general before going into a specialized role. So you are doing it right in your current role by "focusing on deepening my expertise in API integrations and developing end-to-end developer tools"! :)

Feel free to ask follow up questions.

The dimensions to think along here are: 1) **learning** 2) **future prospects** and 3) **compensation**. But not necessarily in this order though as you may have your own priorities.

**Learning**: You'll likely wear many more hats at the startup than at FAANG. See my detailed answer on this [here](https://www.jointaro.com/question/EUkTg3bHTYcmCOUbiasT/how-does-learning-and-more-scope-in-startups-translate-to-career-success/).

**Future prospects**: You'll likely be better positioned for your next role given the breadth and depth you'll gain at the startup. Even if you're in a fullstack role, you'll likely need to dabble in multiple areas to get your task done and maintain your system.

- By better positioned, I mean showing up as a more seasoned engineer at the role after that. But it may not translate into the next title up. For example, another startup or mid-size company might be willing to level you at Staff, but FAANG or another bigger company might offer only Senior. 
- If you don't work at scale at the startup, that might be a detriment in interviewing next time around. Some bigger/ambitious companies value prior scalability experience. 

**Compensation**: Given that startup equity is uncertain (and pre-IPO equity is more uncertain than acquisition equity), this is something you'd have to consider for yourself. I generally see the startup equity as "bonus," so I mostly factor cash comp in my decision.

I know many people who have built an entire career working at startups and many others who bounce from FAANG to FAANG. Yet others have had mixed careers. So, there's no right or wrong answer here.

If you're having a really hard time deciding, consider this: the FAANG job will always be there whereas the startup may be a less frequent opportunity given the combination of their domain, your role, and the company stage.

Hope this helps.

First off, I am glad you're easing into things given your recent experiences!

It's unclear to me if you're contracting already or considering contracting until you land a full-time job.

If you're already contracting, I'd explore FTE roles there along with your interest in working at that place as an FTE. Switching to an FTE position will give you more runway to prepare for your next role that truly interests you. If there's no chance/interest to convert to an FTE at this place, then IMO, you should do just enough work to stay in that position but spend the bulk of your time preparing to land an FTE position.

If you're not contracting yet, I'd def take up a contract job to both be employed and fill the resume gap. Don't feel obligated to stay there for too long if you find a compelling FTE position shortly after you begin your contract. Here's why—your contract employer won't consider your contract length if your position is unexpectedly eliminated for any reason. So why should you? It's OK to want to leave when a good FTE role comes your way. If they like you very much, they can always offer you an FTE position! And it'll be great to have that choice.

> **What is the best approach so that I can effectively land a FAANGMULA / startup company without completely burning myself out and diving into the next job?**

Any new job will take more time and energy initially, so your preparation is likely to take a back seat temporarily. After you're ramped up, you'll need to set clear boundaries on your time to continue to prioritize your preparation. 

This also brings up the point: to contract on not also depends on how far along you are in your preparation. If you're generally prepared and tend to interview well, then a short contract gig might be a distraction. But if you have a lot of preparation ahead of you, then contracting is a good idea.

People are more likely to write a review when they have something negative to say, esp. when it comes to employee reviews. Writing negative comments helps them get things off their chest, which makes them feel better, and that's pretty much the only thing they can go short of pursuing their case with HR, etc. So, there should be no surprise that when there's a large number of reviews, they lean negative.

When faced with a wall of negative reviews about a potential employer, I like to glean the general trend and make a note of the situations that are more likely play out negatively than others. But I don't take each negative review as a possibility that can play out for me—if I did that, then I'm afraid most companies would be eliminated as all of them have at least some negative reviews.

Your experience at any given company is highly dependent on your little corner there—your manager, your teammates, the nature of projects, their significance to the company, how the work plays to your strengths, and finally, your leadership (skip-level and above, if you're Senior+). I like to say that no one can predict your experience until you get there and work for 3-6 months at least.

Tying all of this together, I'd:

1. Glean the general trend from the negative reviews to see if there are any dealbreakers for you.
2. Try to talk to your immediate manager and team members to glean what's likely to play out for you. If those conversations instill confidence in you, I'd say go for it. But I'd be wary if what you read in the reviews surfaces in these conversations.

Hope this helps. Feel free to ask follow up questions.

> What strategies can I use to develop domain-specific skills (e.g., compilers) that aren't directly related to my current job responsibilities?

I'd first narrow down the areas of your interest and their longevity. IMO, databases, file systems, networking, and observability will always be in demand.

Then, I'd read research papers in that area. Most of the state-of-the-art software systems used in the industry today are based on research papers that are easily available online. Reading the relevant papers in sequence, starting with the oldest, will really help you understand the first-principles and build a strong foundation in that area. Taro has a research paper reading group. One mighty list is available [here](https://github.com/keyvanakbary/learning-notes/blob/master/books/an-elegant-puzzle.md#useful-papers).

Looking up conference talks and blog articles is also a good strategy.

If you feel so driven, you can also try to implement a small portion of the paper yourself to gain a deeper understanding of the problem and appreciate the complexity involved.

Over time, you will know the under-the-hood workings of industry-standard software in your area. At that point, you can try to apply for a job (at your company using strategies shared by Rahul or elsewhere) on a core team. You may also be able to get referrals if you show up at a few conferences and chat with the speakers/attendees to build your network. IMO, this is a viable strategy to switch to a core domain without having to do a PhD, etc. Your software experience will also give you an edge over someone who's purely an academic.

The book, [Accelerate](https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339/ref=sr_1_1?crid=190BKWW6S2KTC&dib=eyJ2IjoiMSJ9.g9EhxSy88dnr8S4Qorwi4Fm2STUH_pjBeZ_57r2v0NleJRqBNLF8goKBhx9ghQENB7bJqzKP9Gti7AhxQgSAPt1Zfzkb3gTnSasmm_BDmuN0EQ74gDCcr-h9B7ZKVylfJxoCzpZymm3ZaK6WNwbeHvib3diVbvF969oZhg5GZkI3_8TUIK85ysciWSO5LcEha-0LDy7_YLlXnHHHvs6hQupWYcPQ82T7zWXR1sm7A20.8mDcjbbF11bobGh5YrCmU4HGeXEaLRsUA4T0uL3ux1g&dib_tag=se&keywords=accelerate+book&qid=1730748280&sprefix=accelerate+%2Caps%2C173&sr=8-1), has research-backed answers to this very deep question.

I'd read [Gang of Four](https://www.amazon.com/gp/product/0201633612/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0201633612&linkCode=as2&tag=martinfowlerc-20) or, the more readable version, [Head First Design Patterns](https://www.amazon.com/Head-First-Design-Patterns-Object-Oriented/dp/149207800X/ref=sr_1_1?crid=TTEUIIFG45ST&dib=eyJ2IjoiMSJ9.KueZMlNMlxnKpiJVz_jRt_7FXsYyv2hmjQCQVyWBTC3wu1dByB-SftufAQQn5tPpriDeiF7h8V8-P94Rh3auaP7kdinZlMPeCRYTFhgS51DZ4adEgSH-r-_4FDr7aj35ANj0bcvk044txb2EbTG81D4XoeoMy5aBo1SuTbgENRxDu2BUkWe9_s2BTzTq4ZYKj9MklcLAMQR0HvC0LGkDPbjHloGta6d7p7ObI8Cbgmg.RPFQCpypBSl8O5muezZk3ZrFlUa_0t3ISWZB-DjHN5s&dib_tag=se&keywords=head+first+design+patterns&qid=1730747560&sprefix=head+first+design+%2Caps%2C210&sr=8-1).

I'd also look at your current APIs and object models and try to reason about why they are the way they are. Thinking about the pros and cons of the current choices and running some thought-experiments on how the alternatives would fare can be very fruitful exercises. If you have a trusted buddy at work that's more senior/tenured, having a discussion with them can be more additive than doing this by yourself.

I generally think that these interview questions give better signal than L4/L5 sys design questions as most engineers won't get to design a system at that level until later in their career. More often, they will work on a part of a large WIP system and will need to add/modify APIs or write new features. Honing your API design and object-modeling skills has more immediate returns on your day job as well, so it's worth investing in them.

> It's okay to include a note about what you were working on during this time.

I want to build further on this. I advise many of my clients to keep a running work log where they record what they do, where they get stuck, and their wins. They also record when they help another person/team.

Two standups/day is a lot, and seems like a strategy to micromanage (IMO!), but I hope your work log can save you some anxiety. You can always pick up 1-2 things from it to give an update on.

If you really have no update in a stand up, you could just say "No updates on top of what I already shared—still working on X." But I wouldn't make this the norm day after day.

Like Rahul said, you can also pay attention to what others are saying, and if everyone is anxious over this frequency, a conversation needs to be had with the manager. Maybe an idea to float is sync stand-ups in the morning and async updates at the end of the day on Slack?

Totally agree that at the end of the day, it's the perf review that matters. But stand up updates can make or break people's opinions on their teammates' work, which can be detrimental in peer reviews in the end. Sharing steady progress on your work is your best bet to continue to "look good."

I'm assuming you're asking if you'll have opportunity to switch to management after 6 months through a trial EM program. 

IMO, this is best discussed with the recruiter—ideally before you start the interview loop or even during. Usually, these programs are run at the eng org level. 

No sweat if you didn't discuss with the recruiter. The best way now is to look through Confluence/Notion to see if such a program exists. You can also look at the eng career ladder for the management track. If you haven't discussed this with anyone at your workplace yet, then I would wait for the right time to bring it up in an actual conversation. 

That right time might be after you've worked there for a bit and proven yourself. A career chat will inevitably come up at some point, so you can do a temperature check then.

The advantage of such training programs is that your IC spot is usually safe while you try out management. If a formal program is not in place, you can try to work out an informal arrangement with your manager down the line. 

Either way, I personally like the safety of testing out the water in this manner, so I encourage you to find out about it in due time and try to make it work at your current workplace.

> especially now that I have kids. I believe the UK offers them a better education and overall quality of life.

Does the quality of life for your children include how much money you leave for them later? If the answer is a firm yes, then I'd try to maximize my income (and therefore my savings).

But if the answer is no or yes-and-no, then I'd prioritize their quality of life in childhood and teenage—and the opportunities that'd create for them down the line. 

This said, you do need to make sure that you earn enough to raise your family and retire yourself with dignity regardless of where you choose to live. It's also a good idea to be close to aging parents when they need you. But IMO that alone shouldn't be the deciding factor, esp. when you have a commitment to your next generation as well. 

I'm surprised your org doesn't give you guidance on how to fill these out. In my experience, these guidelines are around how to align your goals with your org's goals and your org's leadership goals.

In the absence of guidance, here's what I'd do:

1. Look at your career ladder and identify goals that will help you meet/exceed at your current level first. If that's already the case, then identify goals you need to hit to get to the next level.
2. Identify how these goals can be written in WorkDay. It'd be better if the KPIs/OKRs of your goals can be aligned with that you org and its leadership.
3. Even in a regular perf review, you're asked about 1-2 things you'd do differently/better in the next half. I'd make these your personal goals in WD. I'd also limit the personal goals to 1-2 max.

The big difference between project deep dive interviews for Senior vs Staff is the **scope** of the project, it's **complexity**, the **impact** it had, and the **skills** it took to drive the project to successful completion.

**Scope**: Projects that span multiple teams (and sometimes even multiple orgs) are strong candidates to talk about.

**Complexity**: Did you design and implement the most complex parts of the project? If yes, it's a good example. It's an indication that the team can look up to you for technical leadership.

**Impact**: This is best measured in $ earned/saved or speedup in engineering velocity or other measurable process improvements.

**Skills**: The skills necessary to operate successfully at the Staff+ level are heavily weighted toward relational and leadership, in additional to technical. 

Hopefully this gives you a good rubric to evaluate which of your past projects would be best to highlight. That, coupled with the other pointers on behavioral interview prep here, should put you in a strong position. Good luck!

Feel free to ask follow up questions. :)

Okay, I see. Well, I hate to break it to you that not everyone will reply just because you've talked to them in the past. :) I have coworkers in my list that I worked with for a long time, and they don't always reply.

Whether someone replies or not has a lot to do with *their* timing. If they're in a job they don't like or don't think highly of, they might be hesitant to reconnect with you, esp. if you *appear* to be more successful than them. They might have other things going on in their life, depending on the timing of your message. The 'no response' situation is rarely personal to you.

I have written to both kinds of connections—deeper and as well as casual acquaintances. In some ways, casual acquaintances think twice before not replying because that might be their only chance to make a good first impression and start forming a relationship!

You do have a valid point in that as you scroll through your connection list, you can't quickly differentiate between the two types of connections. But I'd say that that's a missing feature in LinkedIn! I haven't used Facebook in years, but back when I used to, it let us organize friends in different lists. LinkedIn doesn't have such a feature.

I would like to have this feature in LinkedIn. But, personally, it doesn't deter me from connecting with folks I haven't spoken to. To me, the benefits have far outweighed the downsides.

Overwhelm comes due to two primary reasons:

1. Overreaching in how much you can reasonably do or setting unrealistic expectations of yourself.
2. Telling yourself negative stories about the potential outcomes if you drop the things you won't get to.

Which one is true in your case, and why? 

Here are some things to consider when you feel overwhelmed:

1. Are you being reasonable with your velocity? 
2. Are you setting impossibly high expectations of yourself such that no achievement ever matches what "could be possible?" Our goal should be to set achievable targets while challenging ourselves reasonably. 
3. Are your catastrophic fantasies about the dropped stuff actually true?

On any team, the path to becoming a better engineer starts with doing a good job on your assigned tasks. Some questions to ask yourself are:

1. Do I know the coding language well?
2. Do I know my tools well, like IDE, terminal, etc?
3. Do I know the dependent libraries and services well?
4. Do I know the "peripheral systems" well? This everything that makes your specific service work.

As far as motivation is concerned, I talked about its connection with career and higher aspirations in this thread: <https://www.jointaro.com/question/Zl5nKMUanIKHEtJBEaZY/weekly-side-projectstart-up-accountability-thread/>

Feel free to ask follow up questions!

I can see how going to meetups like these can seem like a "low value" activity. After all, networking is that important activity that yields results much later, so it's easy to deprioritize it over more urgent tasks that bring instant gratification/results.

In addition to networking (that's covered extensively in the other answers), the other benefit I value is: **information is the new currency**. How often do you find yourself in a setting where a diverse group of individuals comes together to talk about their companies, jobs, and day to day work? I learn so much about what's happening in the industry, the various companies, and the challenges that the workforce is facing from these conversations!

Overtime, these interactions build up your mental model. Exposure helps you make better decisions. Broad exposure also makes you an interesting person to talk to, thereby opening up more opportunities for you. 

Not all of these things will happen at once. But they do add up overtime and influence your way of thinking and relating to the world in the long term. I have come to see these events as a contraption—one thing led to another led to another and eventually I arrived at the place I am at now in life :)

Hopefully this answer is not too philosophical :)

Have you identified what domain you want to work in? Narrowing down between HealthTech, FinTech, Crypto, SaaS, eCommerce, etc. might be very valuable in identifying the right opportunities as well as ensuring career longevity.

Another dimension to consider is the field you want to cultivate expertise in: BE, FE, Mobile, Data, Fullstack, AI/ML, etc. 

Yet another dimension is narrowing down the tech stack, which you touched upon in your question.

While jumping across domains, fields, and tech stacks gives you exposure and increases your ability to learn quickly, it also keeps you from cultivating deep expertise in any one area. It can be detrimental to not identify your niche, esp. as you get more senior, and it can also lead to imposter syndrome because you can end up feeling like you "don't know anything well". People who have deeper expertise in something are also generally perceived as more valuable by their employers, esp. if they are also senior.

Once you have these dimensions identified for yourself, narrowing down companies becomes easier. Look at the various conferences to see who's speaking or tabling or sponsoring. Find out what companies are getting funding. These are good starting points. 

Re. job search, as other responders said, you still need to caste a wide net in this job market. But identifying your dimensions of interest and taking stock of what you want to build on in your existing expertise will give you further direction. It can also come in handy when you get multiple offers and need to identify the most compelling ones.

Happy to answer any questions you might have.

Great answers already!

I do have a question though: what do you hope/want to do with a "concentrated" connection list that you won't be able to be do if it's "diluted"?

There are some great answers already! 

Building on Charlie's answer, I'd give serious thought to the practical applications of anything new you learn. 

- Where might it be useful and why? 
- Why doesn't anything else solve that problem (at all or with ease)? 
- What design decisions in the new technology are central to the role it's expected to play?
- What might be some other alternative design choices?
- What are the downsides of the various design choices possible—those that were made as well as those that were not?

This is help you learn the technology faster as well as retain it. It's easy to forget the theory of something, even if you practice the code. It's much harder to forget it when you compile the new learning in your existing mental model.

Focusing on the practical applications will also enable you to put the technology to use when appropriate. Isn't that the whole point of learning something new?

Things to consider: What size is your company? How big is this Director's org? Is the arrangement temporary or permanent? Are you going to be the most senior engineer in their org? Is the Director hands-on or mostly focussed on business strategy and execution?

The following answer is general; I'll be happy to refine it based on your specific situation.

Yes, a fair bit changes!

A Director will have lot less time for you in many ways: to onboard you, to assign you work, to keep tabs on what and how you're doing, and to give you advice and advocate for you. At the same time, their view of the org and problems to be solved with me much larger than a typical Engineering Manager or Senior EM.

So, you'll need to deliver value more independently. You'll need to communicate differently—in a way they can understand and get interested in. There's a lot to say here, but **communicating the what and why would be much more important than the how**.

The Director will have a lot less time to "listen" and troubleshoot things for you. So, any interpersonal issues, stalled projects, differences in opinions, etc. will need to be handled by you. **Bring the problems + how you solved them to the Director, and not just the problems.** 

**Build a support system aside from him but within the company that can act as a sounding board and guide you, if needed.**

If you're going to be the only most senior engineer under them or one of the most senior engineers, consider it fair game that **they will look to you to solve technical challenges and for advice on technical matters in their *entire* org**. This usually comes with rapid context switching, exposure to technical breadth, and interpersonal skills to advocate for the solutions you deem right—now we're getting into Staff territory without the official title plus a lot of influence without authority.

I don't mean to scare you because this is everything that *can* happen but won't necessarily happen all at once or ever. :) I'd meet with them earnestly to clarify their expectations of you along the lines mentioned in my answer.

Remember, these transitions can open up huge opportunities for you, esp. since you're already senior! Good luck, and feel free to ask follow up questions. I am excited at this expansion of your horizon!

This is vulnerable and it's extra hard in this job market. Thank you for opening up.

First, there's nothing wrong with looking for a chill company and doing enough to earn your keep. You're ahead of those who don't want to do even that much and just want a paycheck somehow. Hopefully this gives you some confidence.

What is your plan to avoid getting into a perf-related layoff again? I think reflecting on this is as important as choosing what offer to accept.

I'd start by identifying the recurring patterns in your bad perf reviews. What are your peers and managers saying about you in those reviews? 

In your own assessment of your work, where do you see gaps between how you operate vs. how an average performer on the team operates? Have you thought of enlisting a buddy on your team who is 1-2 steps ahead of you and can provide you with feedback and measurable interventions? 

You're being prudent by choosing a "safe" place to land, and please don't disregard the importance of ensuring your safety there!

I personally think data engineering experience is worth having as long as it's legit DE, like Sai said.

Unlike full stack (which comprises of the vast field of backend engineering), DE is more "contained". It becomes increasingly hard to develop **breadth** in BE as you progress in your career because of the vastness of the field. 

DE is easier to be an expert in. :) The complexity in DE is also lower since a lot of cloud-provider services are available as "lego blocks" to orchestrate pipelines. There are fewer technical concerns such as memory management, threading, etc. 

DE is here to stay and it's actively evolving. A lot of DE engineers today are not necessarily well-versed in strong "software engineering" skills, so you can bring a lot of technical excellence to the DE team. 

Together with DE and ML, you develop a rare understanding of software engineering *and how software at the company-level works*—I have personally benefitted from being in this position!

If you try out DE only for a while, you won't be siloed away from SE. Depending on the lay of the land at your workplace, you might position yourself as an asset! Going forward, you'll likely have a choice to interview for either role and regardless of which you take, you will have a clear edge over those who know only one or the other.

Check out <https://www.deeplearning.ai> as well.

Are you talking about your LinkedIn profile or posts?

The responses seem to be in the context of posts, but your examples appear more relevant to the profile. :)

I wouldn't add them to the profile, the same way I wouldn't add them to the resume. They're OK in posts, esp. when not spammy to add visual elements in the absence of being able to format text otherwise.

On your resume, you could say: "Co-led the migration of X to achieve Y", like Alex suggested, or even "Significant contributor to..."

In the actual interview, I'd focus on the pieces you designed, the migration plan you created, *and the impact it delivered toward the larger project*. I think it's less relevant whether you were the tech lead or the right hand of the tech lead. 

What's much more relevant is the **business importance** and **technical complexity** of the pieces you owned and how they helped the larger project move along. 

"The larger project needed X because...

It required many design decisions, a migration plan, and a series of steps were necessary to achieve it. The team composition was Y (split of senior/junior engineers).

I helped the tech lead design the new replacement in A, B, C ways. Get into the weeds of A, B, C to illustrate why they were important to the design. If the TL missed them or there was a difference in opinion between the two of you and your approach was better, highlight that. If the TL delegated it to you or you were more familiar with those parts, highlight that."

Follow the same script to describe your contributions to the migration plan and the smaller projects you led. Bonus points if you can put some numbers on these: $ impact on the business because of revenue or engineering time saved or future product potential unlocked, N gigs of data moved, %age efficiency achieved, whatever."

Give specific examples of how you mentored the junior engineers. What behavior were they exhibiting before vs after your mentorship? 

You can also give examples of how the TL and the other senior engineers relied on you and why.

If you helped resolve any conflicts along the way or facilitated stalled conversations/progress, highlight that.

Thinking along these lines should help you craft a compelling narrative. Feel free to follow up with more questions.

A few other angles to consider are:

1. **What skills do you want to develop?** If you plan to continue working in this domain, what team would be best positioned to help you gain domain and business knowledge that will make you an expert in this field over time?
2. **What's on-call like (or WLB)?** For example, the accounting or integrations teams *might* have a busier pager than 1, 3, and 5.
3. **How do you want to spend your work day?** What percentages of time do you want to spend to solve deep technical problems, mentor others, give a direction to the team, etc? Getting clear on this pie chart can make the identification easier.

If all the choices score close to each other, a good front-line manager (Rahul's answer) and healthy team dynamics (Alex's input) are excellent tie-breakers!

This is an incredible question!

Today, you're making decisions in software design, tomorrow they will be about large system architectures, and some day perhaps business decisions. Not to mention the countless life decisions we need to make along the way. 

Making decisions that are *almost* always 'right' is a key skill and it can play a big role in determining our life trajectory. It comes with experience, but you can fast track it by asking on forums like these.

On the **tactical front**, I'd identify the desired outcome and use that to reverse-engineer the properties of the desired system.

For example, for the database schema, write the down the queries you need to run and let that inform the schema. 

For websocket libraries, identify your current and projected need for latency/throughput and devex to make a list of the properties the library must have. Then it becomes a matter of sifting through the docs to identify the right candidates quickly.

This approach will keep you from going down rabbit holes to identify the "best" candidates that might have features you don't care for.

The **deeper answer** is to have an easier relationship with "best." :) 

By nature, all software requirements are not understood ahead of time. So, we will be wrong from time to time—and it's not a personal failure or lack of diligence. Researching too deeply comes with the additional cost of indecision and burnout, and yields diminishing returns with time spent. 

Working backwards from the identified properties will enable you to balance "best" with "good enough" or "right for now" and make progress quickly while feeling reasonably confident about your choice.

Does this answer your questions?

In terms of accountability, these approaches can really help you stay committed:

1. How will pulling off this app make you feel about yourself?
2. How does it align with your career aspirations or higher aspirations on how you want to live your life and the impact you want to make.
   1. If you can envision this and stay focused on the outcome, it does wonders for commitment.
3. How will it change the story you tell about your life to yourself and others?

Nearly every commitment in my life has its roots deep in one of these questions.

Back in the day, I wanted to build an app that would tell me the carbon footprint of a given choice. My original idea was to do it for my food choices, but it can also be done for flights or if you drive a gas car or even for things like time spent on ChatGPT or mining bitcoins.

Yes, I'd google some articles on its usefulness and look through a few templates until you find the one you like.

If your manager doesn't have experience doing this, then I'd say it's a great opportunity to collaborate with them and "teach" them. This will also give you a flavor of what it's like to work with them early on. 

(Them seeing you as a collaborator is an important step toward partnering with your leadership regardless of the organizational "power" structures. Done well, it can position you as a strong collaborator and partner to the leaders down the line.)

The Manager's Path also has some great information on becoming an effective mentor and tech lead. I recommend reading the first few chapters of the book, but here's a [summary](https://www.runn.io/blog/the-managers-path-summary#chapter-3) I found.

Does this answer your questions?

So sorry to hear about your layoff. It's a terrible experience to go through.

Taro has a ton of content to navigate these challenges. But if you're looking for personalized guidance, you can set up a free discovery call with me. I offer job search coaching as well.

Rahul's point about translating physical notes into digital is very important for consolidation! 

(This is part of why I rarely take physical notes. :) )

I do keep post-its around for visual cues to change some persistent behavior though. For example, one of my notes said "Yes, and" for a while until I learned to pose counter-arguments that way. Visual cues like these are *very* effective!

Some time ago, I had this use case where I had to read a bunch of books and take notes. I got the books on Kindle/Apple Books and used the iPad pencil to write to make sure everything could be digital and in one place. I found it very helpful. 

I also find Speech to Text very useful on iPad. Often times, I'll speak what's on my mind and it's transcribed.

1. I wasn't interested in going back to big tech :). Like I said above, I terminated my loop with Meta even though they were considering me for E6 (or potentially E7 based on my interview performance). I could've shaved off 2-3 years to get to Staff at another mid-level company by leaving the startup or the fintech sooner. But this is how it worked out due to a variety of reasons and I understand and value the contribution of that phase to my career and life.
2. I don't think I can predict my career progression at any other place. AFAIK, none of the folks I started my career with at Microsoft are Staff now. Most of them are still ICs though. Of course, it's possible that they didn't try at all. See more on my take on this below.
3. The only job I ever applied for was the startup! I had been looking for the right opportunity outside Microsoft for a while, so I went through a phase of mass applying and this startup worked out. 

   All my other positions were either though campus placements or recruiter DMs on LinkedIn, including my most recent Staff role and all the other offers I had in that round. I wasn't even active on LinkedIn until recently; I'd only filled out my profile to a reasonable degree. Very fortunately, I have had more recruiters reach out than I could entertain for most of my career. Of course, the market is very different right now.
4. The startup went though a series of acquisitions unless the last company that acquired it got the short end of the stick and basically killed the product. But the primary revenue earning product did live to its late teens. Pretty incredible!

**My perspective on predicting career progression**:

This might be a hot take, but my long experience has showed me that our dynamic work environment makes it so that success in one environment doesn't guarantee success universally. 

It's possible to do very well with your skillset in one team (with a specific manager and team mates and culture) and struggle on a different team within the same company! Even a manager change on a team you're successful on can drastically change things.

Added to this is the fact that different companies treat career trajectories different and value progression differently. There are also D&I aspects at play when it comes to who is set up to progress quickly and who isn't.

Does this answer your questions? Anything you'd like to add?

PS: Thank you for your patience in getting this follow-up. :)

Here are some tips that have served me well:

**To assimilate and retain what I just read**: Pausing after reading and taking time to remember what you just read. Revisiting the material in your mind reveals gaps in your understanding as well as memory. Re-reading those parts improves understanding and retention of the whole picture.

**Pattern matching**: What else do you know that looks/works like this? This is very helpful in learning new languages or software tools. It also helps in interview prep, esp. system design and algorithmic problems (where else this design/code pattern appears, etc). Associating new things with things we already know making assimilation and retention easier. It also improves our understanding of the world in general.

**Note taking**: Taking brief notes on books you read is a great way to jot down key takeaways and refer to them months/years later quickly! While summaries on sites like 4-minute Book Summaries or Blinkist help, I have found that my own notes work better since they are personalized to what I get out of the book. Yes, it does slow down book reading, but cost of reading the book all over again in the future would be much higher. 

**Creating visuals**: This mode can be used to retain flows of information. Think AuthN, AuthZ flows, designs of common distributed systems at scale, etc. Block diagrams are much easier to remember over mounds of text.

Identify an archive that works well and build it up over time. For me, it's my personal Google Drive. Organizing by topics and being able to search through them is very powerful.

You can also try apps that bookmark links, etc. but I do not have a favorite one.

What are your thoughts on this answer?

First, congrats on the up-level through job search! Incredible work, esp. in this job market!

I'd say the biggest mindset shift is to think in terms of the $ impact of your work. Creating a culture of engineering excellence would be second.

If your work happens to move the needle on the company's revenue goals directly, you're already in luck! If you happen to be on an internal team, like Platform, no need to sweat. In that case, identifying the work that would be the most impactful to the teams you're supporting would win. Are there software or process inefficiencies you can remove or infra/ops cost you can save?

Engineering excellence matters because small inefficiencies snowball into great slowdowns that cost millions in vendor bills and eng org's salaries. Think in terms of code review turnaround times, testing inefficiencies, developer experience, CI/CD, deployment speed, observability, etc. 

Also note that you don't need to wait to be technically excellent yourself to create a culture of engineering excellence within your team (and then your org). See a couple of my LinkedIn posts below.

I'd also look at the career ladder for Senior to make sure you understand how you'll be evaluated. Having a candid conversation with your manager about what they value and asking them to give you frequent feedback would be a great step toward building trust and showing your commitment to doing well.

Make sure you create a 30-60-90 day plan with your manager! I have done this time and again in my career, even when I was quite senior and it was *very helpful* at every stage. Besides technical work, the plan should also have names of people you should meet and the 3rd party systems and tools you should learn about. Google some templates, if you need to. 

Taro is a great place to network with other senior engineers from your company to learn about their experiences and successes. You might also want to find another senior engineer buddy from a sister team (like your manager's peer's team) to orient you to the new role.

Taro also has a lot of content on being an effective senior engineer; Rahul and Alex would be able to link the most relevant threads. :)

How does this answer sound?

LinkedIn posts:

1. [Unlocking technical excellence](https://www.linkedin.com/posts/activity-7206324319113678848-Vo0v)
2. [How to become technically strong over time](https://www.linkedin.com/posts/activity-7207049113006198784-pNCX)

Rahul has a great answer with great pointers. 

I want to underscore his point of business context: "*but you **also** you have tons of business context since you led engineering for the entire company*." Once you get a role of your liking, you'll be able to identify impactful work very quickly, which will make you a great engineer as well as an effective mentor and coach to rising engineers.

You might come across some hurdles in convincing some engineering leaders that you'd be a great SWE or TLM hire (over another tenured IC candidate) unless you've been in the code at work or outside. 

They might also wonder about your motivation to switch back to IC. This is important because Head of Engineering can mean a lot of things. If your role already maps to a Director/Sr. Director/VP, you might be asked more questions :). 

Not knowing more about your exact situation, I encourage you to *get really clear with your intent and how you'll to convince them that you'll make a strong SWE*. You might want to line up a SWE reference or two from your past IC life to vouch for you. Or perhaps the senior most IC at your current place can also be a reference.

You might know about this article already, but I want to surface it again for ideas on how to make your case for an IC role: [The Engineer/Manager Pendulum](https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/).

PS: Rands Leadership Slack is another great place to source help on this front.

PPS: If you're a non-male, [SheTO](https://www.sheto.org/) is a great network to join as there are folks in that network making a similar switch at this time.

I also found <https://www.pramp.com> to be very helpful in getting paired with people of similar experience for free, mutual mock interviews. 

I last used it in 2020. Back then, there used to be a form that asked about my experience, the kind of role I was looking for, and the area I want to interview in. IIRC, the choices were coding, system design, and behavioral interviews.

Once you select all that, you'd select a time and be paired with someone of similar experience and looking to mock interview in the same area. Both people would interview each other on the same question (that would be revealed at the start of the session) and share their feedback. I think the sessions were 90 mins long to allow enough time.

You could have your video on or not; I liked to have mine on. You could also connect with them offline if there's mutual interest.

Hope this helps.

Alex has some great answers already!

I am a living example of someone who learned more and expanded their scope tremendously at a startup, so I want to chime in as well. :)

I started my career at Microsoft. All the tools I used were proprietary to Microsoft. My scope was limited to writing my code, making sure QA tested in, and "throwing it over the wall" for deployment. Occasionally, I'd monitor the deployments. A little later into my tenure there, I learned the production alerts and monitors and could troubleshoot quite well. I even got a promotion there.

Three years in, as I was interviewing for other jobs, nearly every company wanted to talk to me because I had Microsoft on my resume. This being Seattle in the early 2010's, many companies had began using the same internal tools as Microsoft to align with the skills of the available talent.

If any company used 3rd party/industry-wide/open source tools, I was clueless! I couldn't speak to the software pipeline end to end because my scope had been so limited.

Next, I went to a tiny startup of only 80 people in total (go figure!). My scope expanded like crazy—everyone did everything because that's what was needed to ship the product and generate revenue for the business.

At this startup, I also did DevOps for 1.5 years where I wrote Ansible deployments to deploy the AT&T product to 150+ bare metal servers. I did Android development. I did frontend work. I did MySQL database failovers! I worked with IT to provision new servers and set up low level networking and firewalls. I set up web servers like Apache. I interfaced with product managers and engineers on the carrier side (AT&T and Sprint) to identify the right thing to build.

I ended up staying at that startup for 5+ years because of the learning and the "tight-knit community." I am still friends with some folks I met there and we hang out regularly. Fast forward to the last few months in 2024, when I launched my coaching practice, I wrote to several people from that startup. Nearly everyone responded with whatever help they could offer!

From that startup, I went to a 500-person Fintech company. Most often, I was the only engineer in the room who could speak to the entire software pipeline end-to-end because of my exposure at the startup! When the mobile team couldn't use my service APIs, I got them unstuck quickly. When I ran into MySQL issues in my service, I sat next to the DBA to debug quickly.

I became the *de facto* tech lead of my team within weeks of joining (over folks who had had a longer career than me, or were tenured at that company)! All that reputation of cross-functional leadership in this new role paved the path for Staff engineer in my next role.

When I interviewed after that FinTech, I had multiple offers at Staff (all at startups; Meta was also interviewing me for E6 but I terminated the loop) even though I didn't have the Staff title at the fintech—and I didn't ask for it in my interviews.

My next Staff role was really where all that learning and increased scope paid off. I was one of the handful of Staff engineers (in the Staff, Principal, Fellow bucket) who played an advisory role for the entire engineering org of 400 people.

Why? Simply because I knew "how things worked in general." The exact technology or stack no longer mattered because I had gained enough exposure to internalize the shared, cyclical concepts underlying a broad range of things like AuthN, AuthZ, logging, build tools, CI/CD pipelines, you name it.

I know this came out to be a long read, but if you made it this far, I hope this story was helpful. :)

Edit: Made a few minor edits to fix grammar, etc. a few hours after posting the answer.

Is it possible that their team takes a 5 min break in between 30-min meetings? Some teams do a 25-5 and 50-10 calendar. 

Ah, Alex made some great tactical points. 

On the point of buffer, I recommend adding at least a 20% more buffer for relatively well-defined projects, and more for the nebulous ones. 

It's also better for the on-call to not be expected to do very much feature work during their on-call week. This reduces their context switch, and they can apply any free time toward improving the on-call resources like alerts and documentation. A clean hand-off to the next on-call is also highly valuable.

This is an interesting problem to have!

Since you mentioned "quick to code" and "quick fixes" a couple of times, have you tried to dig into why he wants to solve things so quickly? I am wondering if he misunderstands the incentives! 

Sometimes, people incorrectly pick up cues that skew their understanding of incentives. Is velocity highly rewarded in your team or the larger engineering culture at all costs? Do engineers tend to be fast and loose with quality and not mind accruing tech debt? Does he want to impress you with his quick turnaround time? Is he impatient in waiting for your feedback?

Some of the approaches you are applying can be more effective if you could dig into what's actually driving his behavior. This will also help you become a better mentor because you will help people uncover their unconscious habit patterns and address them in addition to providing tactical suggestions. The change you bring about will result in a lasting transformation in your mentees.

As for tactical suggestions, have you considered giving him a set of questions in writing? I'd try writing down the questions around consequences, risks, and other strategic aspects that you'd like him to consider. Ask him to write down his answers in return and have a working agreement that he wouldn't begin coding until the two of you have discussed the answers. 

Writing down his answers will force him to think more clearly than in his rushed, discursive thought. If this approach is successful, he will start seeing patterns in the questions you ask and his answers, which can teach him to think strategically through practicum. Since you're officially mentoring him, you can also ask him to find common patterns among the written notes after you've done this exercise with him a couple of times. 

Your idea to give him some well-defined problems along with a strategic task is also a good one. He will be able to scratch his coding itch and keep showing progress.

I understand your concern. Here are a few things to consider:

1. Does every direct report get the same amount of 1:1 time with the manager right now? If yes, it doesn't solve your problem but at least tells you that you're being treated equally among all their reports. :)
2. How do you want to use the additional time with them? I'd get clarity on this first. Identify your needs, how quality time to discuss those topics would actually help you, and then have a conversation with your manager focusing how the help would empower you. 
3. Lead the conversation with "I'm looking to get X from our time together. X will help me in Y way. How do you recommend we do this?" The manager might ask your more questions at this point, offer more 1:1 time, or suggest other options. I'd say be open to other options as well. At the end of the day, you are looking for Y. It doesn't sound like getting more time itself is your goal. Asking an open-ended question will probably be more productive than asking for more time upfront. You also don't want the manager to get defensive and say no (which will close the conversation preemptively!).
4. Can you make better use of the time you do have? Like have a shared document where you add your top of mind the day before and have an agreement with the manager to respond on the doc. This will give you the full 25 mins to have the conversations important to you.

Hope this helps.

Tenured Staff Software engineer

First, congrats on your promotion! 

It sounds like you are off to a good start, so I'd relax a bit and not constantly scan the horizons anticipating something bad :). This will conserve your energy toward more productive work, trust me.

Now, to your actual question. Here is my top 3 pieces of advice:

1. Trust the engineers who are following you. Let them know that you're there to help, but give them autonomy so that they can have a purpose and are motivated to achieve mastery. This will also help you scale yourself as you'll be able to pick up work they are not picking up. Be open to wear multiple hats in addition to your TL duties given that you're at a small place.
2. Do what only you can. Very soon, you will have many competing priorities and you might be inclined to do it all by working longer hours and trying to stay on top of everything. This is not scalable. Delegate the work others in your team can handle so that you can focus on impactful work for yourself and differentiate yourself. See my LinkedIn posts on delegation at the end of my response.
3. Keep learning technically and show your team that you, too, are learning with them. TL activities and the the resulting glue work can become all-consuming. But cultivating technical depth and breadth are essential in this line of work. So, schedule 2-4 hours every week to learn something new or dive deep into the technical work that your team did for the week. Internalize your learnings. Try to make some active time in the team to learn & teach/share; maybe a lunch & learn or some such forum every 2 to 4 weeks.

Some more reading resources for you down the line:

1. Camille Fournier's Manager's Path has a chapter dedicated to TLs.
2. Will Larson's book on the Elegant Puzzle of Engineering Management. The [cliff notes](https://github.com/keyvanakbary/learning-notes/blob/master/books/an-elegant-puzzle.md) on Github are a great resource.
3. Influence Without Authority by Cohen and Bradford

My LinkedIn posts on delegation:

1. [Superficial beliefs that keep us from delegating](https://www.linkedin.com/posts/activity-7212122554856062977-FDVw)
2. [Deeper beliefs that keep us from delegating](https://www.linkedin.com/posts/activity-7212122554856062977-FDVw)

Hope this helps! Feel free to ask follow-up questions.

Once engineers reach senior and staff levels, they need to decide: Do they stay as an individual contributor (IC) or switch into the management (M) track? Use this playlist to make the right decision.