- Your goal to writing documentation is to suppliment the reader's development in the code. There are mainly 2 reasons I write documentation. First is to explain the context and/or line of thought that lead me to the code (if I feel like the past context is important for understanding the code in the present). Second is to provide a high level summary of what the code does if I feel like the code will take too much time to read & scroll through.
- My hot take is that if someone is trying hard to document as much as they can: that's not a documentation issue. That's a skill issue with the developer being bad at writing code.

Engineer @ Robinhood

Jonathan C

I've written thousands of lines of code of payments related code for a high-traffic financial company (with a few attempts earlier in my career to actively "document" code) and the best way I found to document my code was to:

1. Write better code. Good code is easy to read. If engineers can read the code, why document it? Good code is self documenting.
2. Write better commit comments. A good commit message and a good PR review gives me all of the context I need on who wrote the commit's code, what were they thinking, and who reviewed it. Traditional documentation doesn't really do that for me.

What generally needs documention for me though is the high-level of a feature or a product. High level behavior is less susceptible to change and is harder to understand (since it's built from many layers of code), so documentation is more valuable here (it grows stale slower & the information exposed is time-intensive to get). A good eng design doc will do the job here: bonus points if an engineer links the design doc in every commit/PR to implement that design doc.

- Employment gap is OK: just expect recruiters to ask & have a reasonable answer prepared.
- With the game your main intention is likely just doing random stuff (like the accelerator) and seeing what sticks. Building without a clear intention to learn (especially when you're early in your career and you're not getting traction in it) will unfortunately have the same result as doing nothing. I recommend this [masterclass](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/) on side projects on how to better approach side projects.

I think you misunderstood my post: the top priority is **your company's satisfaction with you.** Since your clients have money (which your company needs) and signed a legally binding contract, they are the main metric in which your company's satisfaction is measured around. Their time is worth money that your company needs. So that trickles then to your only priority to serving clients.

Your satisfaction is unfortunately effectively non-existent on the company's totem pole of priorities (this will be the same for any company). If you want the company's view of the business to align with your engineering view of the business, you first need to prove that you are one of the company's most efficient engineers. Most ideas and viewpoints are reasonable, but there's too many where there's not enough time to reasonably act upon them. So to guide their decision on what to follow, people implicitly will bias towards how they perceive the value of the person providing those ideas of viewpoints. Jamie Oliver says a lot of things about cooking, but people generally listen to Gordon Ramsey over Jamie because Jamie is just saying random nonsense and Gordon Ramsey is legitimately a good chef.

The downside of working with clients is that you're operating on their whims and you can't predict those whims. You could spend time trying to figure out how to make your code flexible for every client, but you're effectively playing roulette with your time (if you guess wrong, your business value/time ratio is 0 for your efforts).

If you want to increase the yield of your time, you can:

- Get better at writing code faster and better. This will lower the time investment needed to add quality to your code.
- Understand what clients who frequently make feature requests & how valuable there are. From that list, identify the top 3 clients with the largest contracts. See if there's any repeated themes around their requests & build your code so that it can be more flexibly changed for those themes. This reduces the chances of you yielding 0 business value with your polish time since you're guessing blindly less.

**Time is the part of the equation you're missing**. You only have a fixed amount of time in your day-to-day work & the clients likely have a hard timeline for needing your company's software. Clients won't budge because they have money and signed a legally binding contract. So their needs are top priority, while your desire for higher quality is very low on the company's priority list. Likewise, the company will want your time spent for them to reflect this (they're the ones paying you after all).

E7s+ solve broad problems that cover the scope of a significant portion of the company and/or a significant number of people (usually both).

I would put it like this:

- E5s generally own projects.
- E6s generally own a team (it's more complex than just helping E5s, but that's another discussion).
- E7s own org-level problems (defining an org as at least 2 teams/collectives of people). Often, a lot of these org-level problems are not scoped to their reporting structure & are happening outside of the org of their reporting structure.

For the E7 I mention, they just simply saw a gap around the company lacking a cross-platform framework that could run the shared code locally on device. So they built one. This problem is E7 because:

- Technical depth is really high. Cross platform frameworks are not easy to build, yet one was built from scratch despite existing solutions (meaning they were technical enough to identify what wouldn't work for existing solutions + align others on this).
- The solution had a positive impact on all Android and iOS engineers (which is 2 collectives of \~70-80 engineers).

That's more like influencing & people don't generally care about that. People at work care about 2 things for someone:

- Does this individual have a personality I'm comfortable working with?
- Is the person sufficiently compotent in my day-to-day interactions?

The nature of how most relationships are built are through 1:1 interactions. A company is a collection of people in the end, so the more number of good relationships you have the more potential you have to influence over the broader company.

I've tried to jump straight to staff+ behaviors earlier in my career, but I was never able to accomplish anything meaningful in my career. I didn't have the strong technical fundamentals that clearly set me apart from my peers (making it harder for me to drive action just by myself & making it harder for engineers to implicitly trust me), and I didn't have an understanding of the foundations of a good relationship (making it frustrating when people were okay with things that I was pushing, but they never really did much else).

If you want to take the most consistent next steps in your career:

- Get good at your current job. Make it clear that some aspect of your technical skills outstrips your peers (coding speed, code quality, company-level technical domain knowledge, general technical expertise).
- Be kind and helpful to other people (both technical and non-technical. Good relationships are built from consistent stream of positive interactions, and beinging helpful and kind are the most straightforward ways to set relationships up on a positive note (especially when you don't know who you're going to frequently interact with in the future).

If you job hop, you need to build relationships all over again (regardless of level). Relationships generally take years: I'd say best case, it takes a 1-2 years to build the relationships. And there's influencing impact over those relationships, which takes another 1-2 years. So that brings the range to 2 years minimum best case. If you try to jump the gun and try to influence without any strong relationships, people will just ignore you best case or try to get you fired worst case.

It's very hard to master the complexities of relationships without a strong foundation of technical (mainly coding) and non-technical (mainly driving xfn discussions to getting people to agree on something). If your goal is to be the "staff" (in quotes because in the end a title is just an arbritrary string) engineer that's balancing technical, business, and people needs, focus on the perfecting the basics first. I wouldn't trust a chef who can't consistently boil an egg to consistently cook a Beef Wellington, and I wouldn't trust someone trying to be a tech lead when they're struggling to push out code on time.

It's a level higher than that for Staff. You don't own the project: you own the team (a collection of people and projects). If your teammate gets stuck, it should be on them to get themselves unstuck. You are there to guide them how to get unstuck more efficiently in the long run. You can help them get unstuck here and there witthout too much scrutiny, but if you do it too much that wouldn't reflect well on you (this is okay as a senior though).

I got pretty close, so I think I can give a viewpoint on the hurdle(s). The main one for me is letting go if being directly responsible. As a senior engineer, I saw a lot of growth and realized impact when I was directly leading projects. But the dynamic (espically for what management wants) is shifting more towards having others lead/own projects and how I'm able to support them.

This is unfortunately the point in my career where I can no longer "solo carry" my growth: I'm dependent on others, and I have no direct control over others. Unlike my manager, I do not have a title that implicitly has the power of "do what I say or you're fired". Instead, I've been shifting towards:

- Building relationships
- Understanding the relationships I have with others surrounding my work
- Being able to evaluate the strengths and weaknesses of people (especially engineers)

Relationships take a long time, so these skills around them do as well. It's very hard to speed run these skills: if you're trying to force yourself as a lead, people will often have some frustration because you're trying too hard to be at a skill level you're not (and it's fairly obvious too). There are so many variables out of control, but there are variables that can be somewhat controlled to reduce the time.

1. Tenure in the company/team (ideally both). The longer your tenure is, the more time you've had to understand the people, the culture, and the technology. If your tenure is longer than everyone else around you, people will implicitly bias to you as a "subject matter expert".
2. Ownership. Long tenure does mean you have more opportunities to understand the company more than others, but you still have to put in effort to pursue those opportunities. Proactively looking to own things (be the "go to" person) will put you in a position to understanding systems more deeply (if you don't understand it well enough, people will stop going to you. Not a good thing for a "go to" person).
3. Individual skill. You cannot grow if you're the bottleneck of the team (in terms of average baseline of code quality and speed). If you are the top in a few categories, people will see/assume that you're skilled and implicit will gravitate towards you.

An E7 iOS engineer in Robinhood built a cross-platform frontend framework that saw widespread adoption & has quite a few senior+ engineers supporting it. They did this as a side project too.

In the end, being a software engineer is just a job. We put in X time for Y value (usually money). Every job is like this. And the company is effectively a collection of people working for the same job, so the same equation applies at a company level.

Good craftmanship does matter. But our time is limited & time's value changes based on the current context. Better craftmanship itself doesn't provide value: yes you could spend time to make something better, but how much time? Would the company be fine with 2 extra weeks of polish for a 1-off client if the client will likely terminate the contract if deadlines aren't met? What if that contract is the difference between 1-2 years of runaway and collapsing as a company? Does writing good code trump the importance of the company not dying? If the company collapses, you're out of a job.

The ease of information lures developers with its high celing of craftsmanship, but often is a siren luring your career to death by drowing it in a sea of "just a little bit better". Craftmanship matters, but sometimes. Writing better code for something that is continously changed will benefit you over time, but if the code is never changed what's the point? If it works in its current state, then it requires 0 effort to be maintain (bringing it's value/time ratio to infinite since time is 0). If you start putting effort into polishing this, time is now greater than 0 and the value/time ratio is lower (so now you're technically losing the company money).

If your ratio is too low, the company will simply terminate you. Yes, your code could be the best out of everyone else's and could have way most test coverage. But if everyone else is shipping for many more clients than you & those clients are happy despite the worse engineering quality, then who's technically providing the least value?

The recruiting process will be fairly indifferent towards your entrepeneur attempts (especially given startup culture is very common in tech), so they'll just write off your solo experience in most outcomes (unless your attempts get a good amount of traction before you pull the plug). If you have the financial safety net & you're really passionate about the idea, just go for it.

A startup grows because it's getting closer to product market fit. At the earlier stages, having a good product market fit is heavily tied to the quality of the product & its ability to effectively fill a problem space. So I'd anchor your questions on getting conviction on if the product is good. Questions like:

- What does the roadmap look like in the next year or two look like?
- Is there a process (or a sense of urgency) for responding to customer feedback?

Would be a good starting point around thinking what questions to ask.

Yes, they are free to ask those questions. Likewise, you are free to answer them by not giving them an answer. You can tell them they can let the results of your interview speak for itself & you can provide references if it's needed.

At the minimum, expect your manager to give you guidance. Their goal is to support you: if you make it clear that you want to progress to mid-level (bonus points if you make it a recurring topic), they will set the expectations for you and help you more accurately track your progress. Meta's a fairly perf-heavy company, so the processes are mature for a decent baseline of support to be given.

Additionally: if you're able to find a mentor to help your growth that helps too. If you find a mentor that "clicks" (you understand their frame of mind and it's for you to pull action items from their mind), that can help provide further clarity on your growth and the expectations for your performance.

I'm pretty sure you have to re-interview to get converted to full-time & it's the same process as any outside applicant for Meta (I've heard it's the same at Google too). Moving to MPK likely won't increase your chance of getting hired full time unfortunately. The increase of visibility of being in MPK might help skew perception a bit more favorably to extend your contract, but that's fairly dependent on your social skills.

Also MPK is kind of boring: there's really not much in the area besides the Meta office, Stanford, and rich people homes all surrounded by tons of suburban sprawl. If you're only moving because you're contracting at Meta, you're going to be highly dissappointed. 

If your goal is to just get in Meta full -time, you should start just prepping for the interview & use your inside look at Meta to get a better understanding of interview expectations. If your goal more broad where you're trying to find any fulltime opportunity in the Bay Area, SF is better for networking with a broader net.

My general baseline is keep things simple:

- Avoid technical terms
- Avoid long sentences
- Avoid speaking for too long
- Prefer words that the average 10 year old can understand
- Identify and remove details that don't matter
- Have a clear line of thinking
- Bonus points for nice pictures or diagrams

No 2 people will have the same understanding, the line of thought, domain knowledge, familiarity with the English language. The simple something is, the less time it will take to understand. The less time is takes to get value from something, the more people will engage with that something.

This is especially true for executives/upper management since they have much less time than an average employee. And unfortunately, they have the most say over an individual's career despite their much more limited view (which is due to the scarcity of their time): they will often make decisions from a few glances over what you've done.

- What are the factors to look into?
  - Do you enjoy being close & deep into the technical systems or do you enjoy the challenge of maximizing teamwork in a team?
- How fast or difficult is career growth in both the paths?
  - Manager is generally easier since your impact is loosely associated with how many people you report to. However, the less reports you have the more easy it is for 1 unhappy report (or a few) to get you fired (I have seen this happen before). So easier later, but much harder earlier (due to the risk & the initial hurdle of having a completely different job).
- How do the work-life balance and day-to-day life look like in both these paths?
  - As a senior IC, I spent a good amount of time writing and reviewing code and technical systems & a lot of my thinking is directly tied to my understanding of the system. From what I see from my managers, they're more often meeting with other people to talk about how the projects are doing, how are the people doing, and making sure everyone is playing nice.
- Does having managerial experience help here or being strong senior/staff IC help here better?
  - It depends on what your plan for running the startup is: is it going to a smaller, more specialized shop or do you want to have a company that will be the next big company?
  - There's so many variables to consider with a startup and so many directions to consider with your life that are always changing, but experience gained through time will always give you clarity. Just focus on your job right now and let your day-to-day experiences guide you to learning what your path forward is.

Evaluate your options with the following ratio: **(Money + Personal Value) / Time**.

- If there's 2 options that pay exactly the same: the one that requires less hours is better and the one that requires more hours is worse.
- We will also include the time you spend trying to right the right opportunity.
  - If you spend too much time finding a slightly better opportunity (like one in your target country, one with more money, or both), time will increase more than money or personal value (so this means your current position is net negative)

Not every option will be perfect (you will never get perfect options as a SDE1 unless you're one of the non-Phd new grads who got into Anthropic or OpenAI). As a result, you'd need to weight each option individually and understand what it gives you. Run your options (including the option to interview more to get more offers) through this equation, and see if there's one that stands out over the other.

- If so: pick that option.
- If not: evaluate what you value more.
  - Do you value money in the short term more?
  - Or do you value potential growth, immigrating to your target country, interesting products, and other non-money things more?

  Add weights to the equation (like **(Money + 2 \*Personal Value) / Time** if you value moving to your target country more) and run your options through the equation again.

Hope this helps!

Anxiety and nervousness comes from ambiguity. Your world is ambiguous because you know you have an upcoming interview, but you don't know what to expect from it. If you reduce this ambiguity, you will be less anxious and nervous when it comes to prepare.

Try doing the following:

- Ask the recruiter what to expect from the technical interview
  - Ask the recruiter if the technical interview is going to be a DSA interview or more of a practical coding challenge (that involves languages/tools that the job requirement asks of you)
    - If the interview is confirmed to be a DS&A interview, ask the recruiter if they can recommend specific DS&A topics you should focus your prep on.
- Once you have information from the recruiter, schedule the interview for the 22nd to give yourself the most amount of time to prep.
- Prep for the technical interview based on the recruiter's response.
  - If it's a DS&A interview, focus prep on the appropriate topics (if the recruiters gives you any). If the recruiter gives you no topics, then focus on general DS&A prep.
  - If it's a practical coding challenge, focus on building a simple toy project or two using relevant skills (the recruiter will usually tell you what they want to use).
- Prep until end of day Oct 20th.
- Do no studying Oct 21st. Take a break, go outside, and get a good 8+ hours of sleep. This is so that you won't be too anxious from having to prep the day right before the interview.

As a junior engineer working their first time job in the big company, it's natural to get overwhelmed by all the different technical and non-technical aspects of growth since there's so many things to do. But in the end, your work and behaviors are tied to the code. If you aren't good at writing code, you won't be good at everything else dependent on being able to write code.

So the solution is simple: just write more code. As you write more code and put up for diffs, you'll more frequently interact with the systems that manage your code (code reviews, CI, deployment, QA, etc.). The systems will naturally push against your code being landed, and this will often be a tiring process. So you'll slowly learn and understand how these systems work and adjust your code to make sure it gets through the system faster.

As a first step, try writing diffs with as little reasonable code as possible. Challenge yourself on getting personal bests on the turnaround time between putting these small diffs ups and getting them landed. Try to make sure that you have focus time (to put some arbitrary number on it, let's say 20 hours/week) focused on just on doing this.\
\
Hope this helps!

2 project leads/DRIs doesn't really work. With 2 people, there's a decision to be made on who to go to and people like thinking less about decisions. It'll make things confusing and add another layer in discussions on who's doing what (which often leads to confusion on who's doing what). One of you will rise (which is your teammate due to their longer tenure and domain knowledge) to be the lead. You're treating it like a competition but you have less resources (trust, tenure) so you're fighting a losing battle. Even though you're both E5s, not all E5s are created equal. Similar to the Olympic finalists: they're all skilled, but in the end someone walks out with a gold medal.

If you're mainly worried that you're dinged on direction but haven't talked to your manager yet about it: let's just start with that. If you're more worried about it, talk to your manager more. Focus the discussions on the impact you're having and the impact your manager expects from an E5: make sure that you're both aligned on your performance.

If you're also worried that your ideas are getting sniped by your teammate  & they're getting credit, then you might be talking in too private of a medium. The more public something is, the less chance there is of foul play. Start the convos in some project/team workplace and let the convo evolve from there: that way, your ideas are more public and documented so that it can be directly tied to you. It's much harder to snipe something when there's written proof it belongs to someone else.

Hope this helps! Feel free to ping me in Slack or schedule some time with me if you want to dig more into this: you aren't the first FAANG-y E5 to run into these issues, and you won't be the last.

Here's my thoughts:

- The resume format makes things a bit too squished for me to read but there's a good amount of whitespace. Most recruiters would just bin the resume off that: if it's not readable, then likely it's not worth reading. You should try to flatten your resume down to 1 column: the 2 columns is taking up a good amount of space & the left one is squishing the text of the right one.
- A lot of your resume feels like you're just saying impact numbers but there's no clear link between the action and the number. It's the same vibe as "Increasing company revenue by 50% by regularly attending meetings": it's not clear what the link between the two is and it feels like you're just saying random stuff.
- Publications and awards don't really mean anything & just takes up space (unless you are a specialist and those publications and awards are specific to that domain).

I'd also recommend checking out [this course](https://www.jointaro.com/course/get-more-interviews-write-a-stellar-resume-as-a-software-engineer/) to get more detailed advice on how to set up your resume for success.

No. The feedback itself is too complex for an AI to validate it: you're going to have to talk to a real human if you want good feedback.

The main thing for me is the candidate has a clear line thought: am I able to follow along with where they're going? Or are they more often than not rambling and/or typing random stuff.

Failing to get interviews is nearly always a resume problem. Can you share a resume (feel free to anonymize)?

This is pretty common feedback for the following 2 buckets:

- Mid level engineers in FAANG trying to go for senior promotion (I have a mentee in this bucket and this is one of the first topics we went over)
- First time senior engineers at FAANG

(It seems like you fall in a mix of the 2 buckets)

When it comes to independence as a feedback, it generally means your manager doesn't feel like you did enough in terms of overall velocity of output or ownership.

Overall velocity is relatively easy to fix: just grind out more code in your day to day. If you grind out more code, you'll understand the processes, culture, and expectations around code review. The faster you understand the system, the easier it is to get through it. It's just a simple thing that many developers overlooks (because it's too simple), but it works.

Ownership is much harder to fix: reading your post over, I'm feeling a mix of behavior gaps and perception issues. I'd boil it down to a single theme of: **your manager thinks that someone else is owning the work for the more sensitive parts of the projects and they think there's no excuse on why you're not owning that work.** During these meetings you're having for these XFN issues or with your TL:

- (More often than not) Are you the one owning setting up the meeting, coordinate the discussions, establishing action items, taking notes, sharing notes, posting updates, and chasing down people?

- Are people going to your TL first and then eventually you get looped in once the discussion has narrowed down?

The TL gets mentioned a lot in your post, so it's a fair assumption on my part is that your TL likely doing too much lifting and that's what your manager sees. That's a similar vibe that I'm getting since for this post, since one theme in your post is a bit thin: **what did you (just and only you) actually do about the problems that came up?** Mid level engineers call out problems and roll the tide of someome else fixing it. Senior engineers call out the problem, call out the solution, and do whatever they can to achieve the solution.

For now, I'd try to talk to your manager and narrow down the gaps they observe & see if they feel your TL is carrying you for most of your interactions with them. That should be a pretty good starting point to trend towards a "Meets". If you feel a deeper dive is needed or want to dive into getting "Exceeds" (I talked about this in the recent Bay Area meetup, so this is still fresh on my mind), feel free to message me on Slack or put an hour on my calendar.

There's a lot going into the mind of interviewers, but this is what usually goes on in mine for the 2 cases.

- **Weak no**: candidate's strengths and candidate's weaknesses are roughly equal. Round down to no because I didn't have strong enough reads on the candidate's strengths to be convinced they can code indepedently.
- **Weak yes**: candidate's strengths and candidate's weakness are roughly the same. Round up to yes because there is some mix of strengths that convinces me that candidate has good enough fundamentals around coding, but just didn't quite get this particular problem.

If there's an office you have to show up to, honestly just eat lunch or dinner with people. Even if you eat with the same people, people will naturally change teams so that'll spread out the teams you talk to. The people I normally eat lunch with went from 2 unique orgs to 4 unique orgs within less than a year.

On average, connections on LinkedIn are about as useful as Theranos's blood testing machines. Just connect with them for an extra connection and move on.

If a tree falls in a forest and no one is there to hear it, does it make a sound?

According to managers, the answer is **no**.

Logging whenever something starts interacting with your project or starts interacting with specific functionality within that project will allow you to get tangible numbers on what your project is doing (recording the "sound" of your project). If there's not a way to quantiatively describe the value of something, the value is generally perceived to be 0 (no one can hear the sound, therefore there is no sound).

I'd also see if you can negotiate your severance: the more money you can get, the more you can focus on your family.

If hours are being tracked through tickets, what's stopping you from overstating the time you've spent by an hour or two?

Hi OP: can you share an anonymized resume?

Raises are only based on:

- If you got promoted
- Your rating at the winter perf cycle
- If your comp is below the average for your level (evaluate yearly at winter perf cycle)
- If you have a competing offer for more money

Check out this [previous question ](https://www.jointaro.com/question/Tno7LGeINpsTPrljUTTT/how-to-navigate-the-difficult-sde-2-to-sde-3-promotion/)about SDEII =&gt; SDEIII at Amazon!

Although not a direct 1:1 correlation to Amazon, but I got my senior level promotion at Robinhood when my teammates were nearly all mid-level engineers during the stringiest year Robinhood had for promos (we did 2 mass layoffs that year).

The reason why I felt like I got the promo was:

1. My manager believed in me. If your manager doesn't believe in you, it's nearly impossible to get promoted to senior. Your manager is the one who is putting you up for your promo: you can't get promo'd if they never put you up for promo.
2. I contributed more than my peers by multiples (at least 1.5x more lines of code merged in). As a result, I was given opportunities first because I was more efficient. It also helped that I barely took any PTO during that time, so opportunities naturally came to me while my peers were OOO.
3. I took on things that no one else was taking up. The main example is I took a large detour once to led a high-priority SEV no one was able to successfuly debug after months (we even had a staff engineer leading the SEV, and they weren't able to root cause). I both established structure on how we'd proceed with closing out the SEV and eventually being able to root cause it 2 days after taking over as the owner. This stood out because no mid-level engineer had closed out a SEV of that complexity (so this greatly stood out on my perf packet).

The time I'm actually focused spans from 30 seconds to 30 minutes and I spend at least 20% of my time at work doing nothing productive. I'm pretty sure I spend a lot more time browsing the internet and walking around than my peers.

The way that's worked for me is:

- Understanding what time intervals will curve out to a consistent level of productivity: for me, this ended up being 1 week intervals (75% of the time) and 1 day intervals (25% of the time).
- Planning goals I know I can reasonbly hit around those intervals. If the goal is high priority or I'll forget it, I'll block off an event on my gcal for the day/week for it.

I have yet to hear anything about me needing to sit in my chair longer. All that matters is that I do my work and I have a reasonable turnaround when I'm needed for random pings. My raw output (commits merged, commits reviewed, LOC merged, LOC reviewed) is signficantly higher than the company average, so that's usually enough to silence anyone from even thinking about asking.

tl;dr do whatever works for you as long as you can do your work at a pace comfortably for yourself and your peers

Regardless of the subject in question, there's always someone selling some metaphorical shovel for some gold rush. But if we take a more high-level interpretation of the phrase, we can see it as: for every job, there's always someone selling tools to achieve that job. I think all parties involved have that understanding in some shape or form.

So the question they really have is likely moreso around if the quality of membership is greater than the yearly subscription cost. So the doubts that need to cleared up can be narrowed down to:

1. What value can Taro tangibly provide?
2. Is this value worth the $400/year?

For the first, it'd likely help the most if you provide your own experiences growing through Taro (a faster promo to SDEII might be a good artifact).

For the second, that's up to them to define their definition of value. But we can start this definition with a more standard financial sense: assuming Taro can get me promoted faster, is a faster promo worth $400/year? Given most software companies have pay increases each band for a couple thousand dollars, getting a promo + raise a cycle early can put that couple thousand in your pocket a bit earlier.

Try to bias towards one building something that you personally believe in and want to succeed: I joined Robinhood since I thought building a financial app with good UI/UX, engineering was a good idea.

- Join a FAANG company. Or join a unicorn startup that hires mostly FAANG (so when the company IPOs, there's a non-trivial chance the IPO is multiple times your sign-on price).
- Pick a team that is mission critical to the business. This reduces the chance of you being impacted from your team/org being targetted for headcount reduction.
- Be more efficient than your peers at shipping code/features/projects etc. since management roughly correlates bigger numbers with more impact.
- Stay in the same company/team for a long period of time so that you're seen as an anchor of stability/consistency.
- Be helpful to everyone interacting with your domain so that more people are willing to go to you for help and more flexible when it comes to working to you.

For every Mr. Beast, there's 10000 influencers who are at best teatering on the brink of piling on debt.

Many of these engineering influencers have very large moats and support networks, so they are able to aggressively pursue these pivots. I'd recommend you crunch the numbers on your current situation, how much runway you want to give yourself, and your risk tolerance and make the choice from there.

(Will be annotating the titles associated with each level # for folks who don't know Meta's leveling system)

Honestly, just grind more code (either by working more efficiently or working more hours).

1. The faster you ship, the more projects you can take.
2. The more projects you can take, the more opportunties you have for E5 impact.

This will give you the potential for E5 (senior) impact, but not guarantee it. E5 behaviors is a step up from E3 (junior) and E4 (mid-level), so you can't brute force to 100% of the way there. You need someone (manager, skip-level manager, tech lead) to help you along the way by giving you the appropriate feedback and by serving as a vouch (you need at least 1 E5+ to strongly vouch for you to be considered for E5 promo).

For a side project:

- Build a real time online marketplace for popular MMPORG, supporting X thousand daily transactors.
- Monetized website with Google ads, allowing website to profit Y dollars yearly (after server costs)

For an internship:

- Built X feature that rolled out to XXX thousand users, increasing Y key metric by Z %
- Worked with design and product to clarify requirements & update designs to reduce engineer lift by a week
- Worked with a data analyst to define a logging spec for the feature, allowing us to properly capture metrics

Since he's pretty junior as an engineer and has likely not being coding during the career gap, it will impact them signficantly. The gap itself is fine (can easily say career/mental health/whatever break) if anyone asks, but the time in that gap that was spent spinning is wasted. If they want to maximize their chances, they need to sink in time now and start writing code.

I read through the resume and viewed the side project that had a link: there's unfortunately not much substance I can find on the resume.

- The resume is just a salad of words and it's very hard to understand what they did.
- The side project didn't even load immediately for me and I had no idea what it even does.

The root cause of the problem is clear: **your friend isn't writing enough code**. I'll break this down into some themes:

- The volume of code is low. Your friend is likely just spending more time spinning in circles than they are coding. They need more side projects.
- The quality of code is low. Any projects linked need to at least have the happy flows working. The side project linked pretty much never really loaded for me.
- The value of code is low. Being a software engineer is not special from any other profession: you get paid to do things that provide value to a business. Your friend's resume is more focused on the technologies and not the problem the work is solving.

I'd recommend the following to them:

- Spend some time focusing on building a side project that actually works. If they're just farming the project to pad the resume, it's really obvious. Make sure it's a project that they feel can be used by other people: they should then ship this project out to the public & get feedback on what to fix and what features to add.
- <https://www.jointaro.com/course/get-more-interviews-write-a-stellar-resume-as-a-software-engineer/ats-obsession/>

Your first goal isn't the numbers: your goal is to build something people can comfortably use. If you build something good, the numbers will come naturally. What you're building effectively doesn't exist yet, so marketing is not a priority over building. Just focus on building something first.

Got it.

- Pause interviewing. If you're not getting any conversions now, not interviewing is not going to change that state.
- Pick 1 project that you feel like you're able to consistently work on the most and stick with it.
- Prioritize shipping something out for real people to use. The less you need to do to get here, the better.
- Respond to any feedback you get from initial users and push out updates.

Are you currently employed or not? That narrows down the details of your interviewing goals: is it to get a first job or a better job?

Here's what I would say to me after I just graduated & spent a few months trying to find my first job:

Build more side projects that

- Require the product/codebase to be iterated on over a long period of time
- Ship to actual users

Software engineering is fairly pragmatic with judging graduates on what they shipped to real users. Yes internships are the main way, but there's nothing stopping you from building something and getting it out to real users (especially in this day and age it's really easy to learn how to build and deploy software). Leetcode is still building something, but no one really cares about the code that never ships to prod.

At some point of time invested, more time spent applying for jobs is wasted if you can neither get interviews nor pass interviews from these additional applications. Writing more code (especially side project code that you're trying to ship to real users) will generally improve coding skills for both interviews and both on the job, so focus on that for a bit before applying for jobs.

You can't get the perfect opportunties that alumni from other colleges are more easily able to get, but you can create your own opportunties. If you can't code your way into your first job, then it's 100% just a skill issue.

The behavior of the Android E5 is catching my eye (naturally given how the story is structured), but I don't think their behaviors are necessarily "toxic" given the view presented. My view is that the Android E5 is trying to focus on growing the "direction" axis and they're not able to keep up with driving the team forward while doing core implementation work.

A lot of the intent & behaviors are just speculation, but you need to dig deeper to see the reason why this situation and people are playing out the way it is. I think the path forward is simple: **you need to start talking to people.** I don't mean like in a project or an ad-hoc meeting setting (as an E5, I assume you already have those behaviors): you need to talk to people 1:1 through recurring 1:1s. This will help you understand the people around you and allow for more nuanced, intimate conversions to grow your view of the world around you. This will also allow for you to extend a helping hand to folks without putting them in a position where they might feel publically shamed.

Proposing projects for the team is only 1 part of growing as a senior engineer: you also need understand the people around you. While the people issues may seem like dysfunction, this is an opportunity to rise above and be the one supporting and carrying the team. Build that understanding your team and learn what they're capable of, what they enjoy doing, how they generally react to certain conversations, and how they generally behave. As this understanding gets stronger, you will better learn how to path around projects by being able to proactively support teammates so that the frequency and the magnitude of these issues is minimized.

Hope this helps!

Stripe offers 1 year grants so the risk resets every year. However, if the Stripe IPO is successful and the share price is much higher than the price you started at, you will only reap the benefits for 1 year.

Your goal is to reduce the amount of time it takes for your coworkers to understand you. If the frequency in which they ask you to reclarify what you just stated goes down, you are succeeding. I strongly recommend taking [this course end-to-end](https://www.jointaro.com/course/effective-communication-for-engineers/) more granulary understand what a good communication as an engineer looks like (although this focuses more on the interpersonal part).

We can take communication as a starting point as an example.

- Organize your thoughts into bullet points and paragraphs.
- Every time you write something, do another pass to see if you can lower the total word count before hitting submit.
- Bias towards using simple words.

ChatGPT is the perfect tool for improving what you type: I highly recommend using ChatGPT on what you write ("Hey GPT can you organize this text and reduce the word count?"). We can have a metric here of how many changes ChatGPT has. The less changes GPT makes, the better your communication is. I highly recommend treating your communication on Taro's Q&A the same as communicating as work so that you'll be better prepared for higher-stakes situation at work.

You're trying to pigeon-hole the behaviors into the specific projects, which feels like you're focusing more on gaming the process over building long term behaviors. **Within your day-to-day, you need to demonstrate these behaviors regardless of how big/small/promo-worthy the issue is at hand is.** True growth manifests from your view of the world changing to reflect a broader view: gaming the career matrix might make getting the promo easier, but it often leads to you not having the right fundamental understanding of your environment to sustain your promo.

If your goal is to prepare for senior level FAANG interviews, we can treat this question like an answer to a behaviorial interview.

While the projects do seem to have the technically complexity to be senior, there's 2 questions I'd have:

- Most of the implementation for these projects (where the technical complexity is) seems to be done by you and only you. Is your team involved at all during any part of the implementation process?
- What does the technical complexity of coordinating with other teams for this project looks like? Will it take a lot of code/time for them? Are there signficant risks of this migration going poorly?

My high level read of this question is:

- Your focus is too much on yourself being the "hero" by consuming most of the implementation. There's very little around the system (people and technical) around the projects besides mainly "oh they'll use the project when I'm done". A senior engineer needs to show they can be a team player besides individually consuming a bunch of implementation, while mid-level engineers generally are more individualistic.
- You're a bit rambly without any clear organization of your thoughts, so it's hard to follow the question. Efficient communication (organizing your thoughts, using simple and concise terminology) is a key trait expected from a senior engineer. More words usually doesn't mean more overall value communicated & people often have an unspoken cutline around communication where they just stop listening to you (bringing what you said down to 0).

Like I mentioned in a [previous Q&A](https://www.jointaro.com/question/JUphqWJJyljb7BghnmxG/onboarding-successfully-to-a-new-semi-chaotic-engineering-org/), it's very easy to tell the difference between a mid-level who's trying too hard and a true senior engineer. You're trying a lot and doing a lot, but you're focusing too much on your own individual output. For senior engineers for FAANG, they're able to support teammates on projects in a way that's not completely taking over their work. My recommendation is to focus on growing these behaviors.

- **Communication**. Simply down your thoughts and the words you use and look to provide some level of organization to them. This [Q&A](https://www.jointaro.com/question/QDLV5owweJveRLlspOdc/how-to-make-communication-succinct-and-more-impactful/) is pretty helpful for providing some general tips.
- **Enabling the team**. Taking over the work of your peers doesn't count here: you need to show that you can work with a team and be the primary person that unblocks them. Focus on non-technical behaviors for this: creating clear requirements/design docs, leading project meetings to track status and check in on blockers, and coordinate the launch process are common ways to achieve this.

Hope this helps set up the baseline for senior-level at FAANG!

I use a wooden kitchen chair that my family's had for 20+ years.

Got it: that means that usually your resume is not impressing the hiring manager/recruiter. I'd recommend checking out [the resume part of the interviewing course](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/polish-your-resume/) and also checking out the course overall. If you can share your resume (feel free to DM me on Slack if you wish to remain anonymous in this thread), that'd help us debug faster. I did review resumes for intern + new grad applications for Robinhood & I was the one tossing 99% of resumes, so I do have experience with the filtering process.

Where in the funnel are you having the most trouble proceeding through (resume screen, recruiter screen, phone screen, onsite)?

- What is this nature of this reporting structure? Is this something that your manager set up? 
- Were expectations of this reporting structure made clear to you by someone?
- Has it been clearly communicated to these 2 engineers their performance is trending downwards?
- Do you have recurring 1:1s with these engineers to communicate expectations and give feedback?

For a junior level engineer, your goals should be focused on code quality and volume. As time goes on, it needs to be clear that:

- It's taking you less time to put up code for review
- You are adopting the best practices of the codebase
- You are more comfortable making more complicated code changes

Tying this into a 2 week, 1 month, and 3 month onboarding milestones:

- 2 weeks: first PR up for review
- 1 month: 1 PR merged and at least 2 PRs up for review
- 3 month: 15 PRs merged

With each milestone gradually having different goals & increasing numbers, there is a clear story that needs to happen of you getting more comfortable with the codebase in order to meet these behavior changes and numbers goals. Numbers may not be exact at measuring progress, but it provides something quantifiable that we can easily measure.

At the junior to mid-level range, the best way to future proof yourself for work is to write more code at work.

Work code is the code that's most reflective of what code you write within most of your hours spent as a software engineer. Someone is measuring the effect of your work code: if your code is "better" than your peers (by speed, quality, impact, or all of the above), you will be rewarded more (more money, less likelihood of being cut). The more code you write, the faster you will hit the inflection point where you don't need to write as much code to understand how the world around you work. The less code you need to write to provide value, the more time you can spend on higher-level behaviors that will further future proof your career (evaluating business constraints, leading without authority, xfn communication).

Side projects and system design will help you learn and grow more as a software engineer, but lack the nuances of business constraints that shape and influences our decisions as engineers. To reference Harry Potter in book 5: there's a difference between reading about the Defence Against the Dark Arts and having Lord Voldemort throwing Unforgivable Curses at your general direction. One of things is theoretically happening in real life in a controlled enviroment, and the other is actually real life with tight constraints around the decisions you make.

Like Alex said: 20 hours is impossible nowadays (it might have been doable duruing the pandemic), but it's possible to work 30-40 hours (leaning to 30) if you know what you're doing. I've been doing this quite a bit recently since I've been a bit burnt out, but it requires very strong foundations for:

- **Reputation**: you need a track record that immediately convinces people you know what you're doing.
- **Influence**: you need to be able to use your reputation to get teammates to do work for you & you need to know where the bar is for that work. You also need to be able to advocate for yourself to be involved in the most impactful projects.
- **Technical fundamentals**: you need to have strong technical fundamentals you can rely on to get code out faster and better than the company average.
- **Prioritization**: you need to know what work is valuable for your team/org and what work matches expectations of your level.

The higher the level, the more each category is structinized. At senior level and beyond, you need to be on point with all of these categories. All it takes is a bit of doubt to cause everything to fall down.

My guess is that it's so they can track their intake and better estimate how much bandwidth it's roughly taking from the team. This will be helpful in their planning process since if it's taking too much time, they'll likely invest bandwidth to making the process more efficient for both parties (them and the team making the changes).

It depends. There's a few other variables in play too:

- How much scope/person does the team have on a yearly basis?
- What is the relationship between management and the ICs? Is management already committed to promoting and growing specifix individuals?

Each of these variables can drastically change the path to Staff for each option. To show how these variables can remove the path to Staff in each scenario.

1. The team of extremely talented engineers could be mostly senior and staff. The team is top heavy & scope likely flows to the staff engineers first, then the experienced senior engineers, then the new senior engineer (you). You are fighting for scope more than actively working & can end up with a low rating due to a lack of work to prove impact.
2. A team of decent (but hardworking talent) might be easier to stand out, but there could already be senior engineer who's worked with management on working towards their staff promotion. Scope can be limited, so scope will be given to them first. You need to wait 6 months after this individual's staff promotion (promotion budgets are limited and staff promos cost $$$). After their promo, there is not enough scope to support another staff promo. Scope flows to the staff engineer first (to prioritize maximizing their value), and then to you with the staff-level scope removed.

This is diverging significantly from your original question, but the better variable to consider imo is "what will my responsibilities look like if I were to join the team"? If the baseline of scope that you start with isn't the higher end of senior, you'll likely need to take more time to prove your worth to get that scope. If you're joining as a new senior eng at FAANG from another company & not internal transfering to another team, you'll need to incur \~1 year of overhead to build up relationships between management, your team, and your xfn stakeholders before there's clear conviction that you can start working to Staff. But if you're given a stronger baseline of scope off the bat or bringing in reputation over as an internal transfer, the overhead will be significantly lower.

M1 = line manager (a manager that engineers directly report to)

So what you're running into is social capital: which in the broadest definition is the trust and expectations your colleagues will have in you. Social capital generally works the same way as normal capital (money): if your social captial is positive you can spend/use without issue, but if you're negative you'll compound debt (and likely can't get out of being in the "red").

What likely happened in this scenario is that you tried to spending first (which pushes you into debt) before checking if you had the capital. In this case, you should've made sure that your code had a stellar reputation and that your skip manager was clearly aware of this (akin to checking your balance first, and to spending that confirmed balance). **Once you have the balance checked and confirmed, then you can spend it.**

A lot of engineers earlier in their career often feel the pressure to voice their opinions as they get more proficient as an engineer to grow more senior. But what they often overlook is that opinions aren't meritocratic in a vaccum: who is behind the opinion and what is that person's background is weighed as well. Following through with an opinion takes time and effort and the opinion could potentially be wrong or not be an effective use of time, so we often find ourselves subconciously judging both the opinion and the person who says it.

For this specific scenario, you should take this as a learning opportunity. Look to resolve the gaps that your skip manager called out, and look to understand why your manager has these standards. Incoporate these learnings into your code, and get to the point where it's clear without a doubt that your code quality is the clearly around the best for the team/company.

For a broader lesson overall: don't spend what you don't have. Reputation always comes first before influence, so focus on building reputation if you want things done your way.

I once lead 3 multi-month projects concurrently and shipped all of them. This may sound impressive, but I frankly didn't do that much as lead besides being proactive on a few decisions.

- For project A (\~2 months feature project), I had a pretty clear idea of how I wanted it designed but knew that polishing up the design takes too much time. When the project started, I gave technical ownership to a teammate and gave them my farily terrible initial design to improve. This allowed me to focus on non-technical parts of the project (logging, xfn) and coding up the Android portion of the project.
- For project B (\~5 month feature project), I knew this was a critical and massively complex project. When my skip manager put this project on my plate and asked me who I wanted on it, I immediately stacked the project with the senior-most engineers. I knew that I wouldn't be able to efficiently juggle the xfn and technical specing across multiple projects, so I wanted engineers who could proactively fill the gaps I can't fill.
- For project C (\~9 months infra project), I broke it down into milestones that we could easily drop and re-pick up. I also knew that feature work takes priority for my org, so I always worked with my managers on how we could sequence the projects. This project shipped late with 0 issues, but the 2 feature projects didn't ship late (so management was still happy).

For mid levels growing into a lead (my past self included), they often fall into a trap that to prove themselves as a lead that they need to do more. In reality, leads are simply held responsible for the outcome of the project: it doesn't matter how much or how little you did as long as you directly influenced the outcome. The most important outcome is: did the project ship sucessfully? As a lead, it's up to you to decide what success looks like. Success is a scale not a fixed target: you set the bar of what success looks like. If you try to treat it like a fixed target of doing everything perfectly (in terms of quality, speed, how much you did), everyone loses and all the projects will blow up in your face.

These are the guidelines I followed that I felt like helped me succeed at leading 3 projects concurrently.

- Prioritize the sequencing of each project based on impact (value/time) and time sensitivity. Work with your manager to figure this out and clearly communicate this ordering to xfn stakeholders. I like using weeks as a unit for how I'll use my time.
- The human mind is single threaded and in reality can focus on only 1 thing. Parallelizing simply means that you've broken down your work enough where your single thread is switching back and forth between projects. If your work isn't broken down enough, you need to spend more mental resources to switch between projects (switching more means that more time is lost to context switching overhead).
- Your time is valuable as a lead, but that doesn't mean you need to do everything. Proactively delegate to others so that you have more time available for you to use however you see fit.

Hope this helps!

Once I hit senior, the amount I cared about learning outside of what's needed for the job went to 0. It'll be nice to be on top of the current meta of software, but most of these learnings provide me 0 value within my day-to-day job. My day job provides me the most monetary value in life, so I will only learn something new if there's a clear business use case within my day job. Outside of that, I don't care about learning to keep on top of everything: there's simply too much to keep up with.

Just stop talking to them about it and tell them only when you're successfully hitting those aspirations. If they're not as receptive to them now that you're an adult, this will likely not change. But what can change is the time and effort you put into yourself and your aspirations.

Take some PTO (more than 1 week) and disconnect from social media (including Blind) while you're out. There's a lot going on in tech, so it's easy to get overwhelmed if you're constantly plugged in.

I can't speak directly about Meta, but I do come from a company that hires heavily from Meta (so I'll give my experiences at Robinhood).

- Deliverables and milestones are set at a project level: it's up to the project's eng lead on how they set these up to make sure things are delivered.
- Project update meetings are also driven by the project's eng lead: it's up to them to decide the frequency.
- Teams will usually have a weekly/biweekly team meeting for teammates to give project updates.
- Sprint planning is not a thing, but quarterly/yearly/half planning usually happens at a team/org level. This is driven by managers mostly with the input of tech leads (if there are senior enough engineers to fill that role). 

While not agile in what'd we see in more traditional companies, it does share the same high-level framework around planning and executing projects. It's just that for these "top" tech companies more value is put on engineers to be owners beyond coding: there's a lot more freedom with how engineers choose to deliver, but there's more pressure on engineers to own the broader delivery of the project beyond coding.

Generally, people of certain levels will group around certain behaviors. Junior and mid-level behavior is generally very individualistic, focusing on the raw impact of code or tasks. When it comes to senior, the main jump that needs to happen is providing value to people around you beyond your individual output. The most standard path for this is serving as a project/tech lead: providing value through a mix of program management, designing architecture, and individual coding output. If your name is the first one people associate with projects, then that'll be a clear indicator that you're progressing towards senior.

As a recently-promo'd senior engineer and someone who's roughly your age, your manager would be a great starting point to figuring out what your path is to senior engineer. Work with them to figure out what deliverables and behaviors would they expect from a senior engineer and see if they can share some stories about their path to senior engineer.

The question about competing offers and the list of questions are pretty standard: the ones about hobbies is kind of a bit odd though (I wouldn't fill that one out). The recruiter is likely using the questionaire to determine:

- If you fit the criteria for the role (location, interest in company, etc.). If you don't, it's better for both parties to not proceed before the company involves another human.
- How much the recruiter should push the company to speed up/slow down the interview. If you say you have a competing offer with a deadline, they'll move a lot quicker. If you are in the process with other companies, I'd decline to name any companies unless they're name brands. Everyone has interviewed/will interview for a big company, but smaller companies are usually fighting for a smaller pool of talent (so it's a bit more invasive for those companies).

Google let me skip their phone screen every time I interviewed with them: I had neither referrals nor leverage during each attempt.

I think you're jumping the gun here. If you haven't ever been at a FAANG or an FAANG-equivalent, your first priority should be getting a offer not nickpicking to figure out the best offer. The benefits at these companies are signficantly better than nearly all other companies, so I'd be happy with any first-time FAANG offer since it's usually a full upgrade relative to non-competitive companies.

Even though I'm serving as TL at a top tech company now, what a lot of people don't see is:

- I retained Kindergarten.
- I got Bs and Cs until college (with some Ds sprinkled here and there). This is a lot worse growing up in a majority Asian community that excelled hard at academics.
- My main childhood hobby of choice was playing Maplestory, while most of my childhood peers were playing instruments or doing prep classes.
- I went to a mediocre college and graduated a quarter late.
- I didn't get a return offer for my internship.
- I took 5 months to find my first job as a contractor.
- I spent \~4 years of my career stuck as a junior engineer.

Tbh I don't anyone expected me to get this far in high school and I'm pretty sure my parents were hard dissapointed in me until my mid 20s.

A lot of it just comes being comfortable with the progress you're making. That doesn't mean you shouldn't be envious of other's progress: you should just accept those feelings, but not let them be the primary thought in your mind. Past progress isn't an indicator of current or future progress: you can't change the past but you can always work harder for a better future one step at a time. Doesn't matter if your steps are smaller than someone else's: just focus on taking on a step.

For fundamentals, I'd describe the core as understanding the common constructs of writing and organize the code. Programming itself only has a fixed number of permutations to do things and often times constructs across languages do the same time but the syntax is different (a for loop in Ruby has different syntax than a for loop in Java, but we'd still expect them to behave the same way). Understanding what these common constructs are means that your time learning something new will be more focused around the specific information you need vs. having to read some documentation end-to-end and having to parse through a bunch of fluff.

The personal example I keep giving on Taro for fundamentals is that I'm an Android engineer, and I haven't touched backend code in years. But I've been able to provide design feedback occassionally for the backend simply because I imagine the backend codebase to be architected similarly to the Android codebase. I don't know the exact tools and technology for the backend, but I can identify certain pieces of functionality and assume there's something that has to be able to behave in a very specific way to accomplish that functionality. So I'd hear the word "Kafka" a bunch in these reviews: I've never used Kafka ever, but I do know that something effectively needs to be an event bus for services.

You could try reverse-role modeling: you have worked with engineers that are E6, but have clear behavior gaps that negatively impacted the project. Try doing the opposite of what they're doing. For example: when it comes to deliverables you own, make sure to provide a test plan and be available to provide some amount of general maintenance support.

If you want a good example of a E6 role model that you could emulate: there was an E6 iOS engineer on a project I was on that spanned a few orgs. For one of the major features in this project, they effectively did all of the iOS and the backend work concurrently (Android had 2 senior engineers and they were barely able to keep up with this 1 iOS engineer). This engineer was so individually productive that they lowered the number of people (which indirectly lowered the number of dependencies) needed for the project.

Pulling from my own experiences growing as senior: your growth will learn towards scaling your influence. There's a two ways you can do this:

- Increase the impact of your team. At a team size of 3, this likely will be a mix of increasing the number of people on the team and increasing the impact per team member.
- Function at your skip-level. This means that you're supporting your sibling teams, so you'll have a higher number of people dependent on you.

It's unclear which path you'll end up leaning towards (given how it's dependent in individual, team, and company context), but there's clear starting point: **your team has minimal work**. You need to dig into this: why is there only small projects? Is it because the team doesn't have enough headcount? Is it because the goal(s) of your team is unclear? If you are the senior most engineer on your team and your manager is new: this is a great opportunity for you to step up and work with your new manager to figure out how to set the team up for success. Provide your insights (and potential suggestions) to your manager on how the team could be set up to deliver more (changing the team direction, suggesting projects, pushing for more headcount, etc.). If you don't have enough context on the bigger picture, try scheduling some recurring 1:1s with your skip manager and get their thoughts on your team's future. If you're able to set your current team up for success, that will open the doors you need to take on the scope/influence to grow as a senior engineer.

Hope this helps!

At some point, I played maplestory during my lunch breaks and started signing off at 2-3 PM on Fridays when I had no deadlines.

I wouldn't stress about it too much: you're a new hire who's still getting ramped up. It takes a while to get the ball rolling at senior level: there's a mix of the team/company having the right projects and having the time to build trust between you and the team. If you're worried, just work with your manager on clarifying senior level expectations and syncing with them to see how you're trending. At the 3-6 month mark is when I'd say your manager will start getting clearer reads on your performance and can provide the appopriate feedback.

Unfortunately, the only way to force this to happen now is if you have a competing offer at the next level from a company with similar pay bands. Else, like Ryan said: you'd have to push your manager to promo and max your comp increase in annual review.

Thanks! If you're trending towards Below Expectations but have not gotten the rating, there is still time. The moment you are handed a PIP, you are effectively out of time.

The first step is talk to your manager around what behavior gaps they're observing: get in writing what are their expectations for behaviors for a mid-level engineer and what behaviors have they observed from you in past/current projects. Then work with them to figure out for the future projects you'll be given, what are the behaviors and artifacts they expect for Consisently Meets Expectations. Every week or two, sync with your manager on how you're trending and course adjust on their feedback.

For mid levels struggling it's usually a mix of:

- You're not showing enough independence when it comes to execution: it's clear that your teammates or manager are carrying you end-to-end for your work (they're breaking down your tasks, handling xfn alignment for your work, setting timelines for your deliverables).
- Your execution of code is perceived to be slower (diffs/half is low) or low quality (big diffs, low quality diff summaries, no/minimal test plan) compared to the general mid-level or junior baseline.

If you'd like more tailored action items, feel free to share more specifics on what your manager is saying (either on here or just DM me on Slack).

Can you break down what those rating abbreviations mean? I haven't seen's those abbrevations used ever for Meta perf system & I don't think most people not familiar with Meta's perf system would be able to guess.

Given that you're able to focus down on 1 specific piece of the ticket, maybe you should just break down your tickets further? The smaller something, the easier it is to focus on it.

While certificates provide value in theory, in reality the people who frequently try to get cetificates are often doing so last ditch effort to highlight their skills as an engineer. Software as a field values practicality and the knowledge  gained from certificates often focuses on presenting infomation in a generic manner (since it can't capture all the nuances of context). A lot of folks call it a day after getting a cetificate, which is why they find themselves struggling to get any opportunties from them: there's no clear sense of what are they doing with that information. If you want to pursus certificates & ensure you get the most value, try using that information in a practical manner (either by using it in a side project or using it at work).

That's a bit of a broad statement, which makes it harder to narrow down on what projects that you'd be most successful/interested in building (from a tech stack and general interest perspective).

A side project I'd want though is a old school Maplestory server (any version up until v83 works) that can run on Macs (without needing virtualization software and I can just straight up run the Maplestory Mac client and have everything run). I'd also like the code to be 100% open sourced to set a baseline of how future servers should be built.

As an individual, you can:

- Write code faster
- Write code better (smaller diffs, more test coverage)
- Review more diffs
- Push out refactoring diffs to reduce or reorganize code
- Propose features
- Propose frameworks for all features (this one is a bit harder to do)
- Improve your ability to work with non-eng stakeholders by proactively reaching out to them more frequently

If you don't feel like you have much individual control over your work, talk to your manager about what projects you want to take on and what behaviors you want to build/improve. Your manager is responsible for supporting you & has the best view on the team's work, so they're always a good first person to start the conversation with.

If you're currently doing react + typescript at work, I'd just put up more pull requests or review more pull requests. A lot of my learnings on how to use a language/tool have been through putting up more pull requests, which naturally increases the scenarios which:

- I need to think about how to leverage the thing to make my code better
- I need to learn part of the thing to make my code work

If not, I'd recommend focusing ok a single side project & consistently iterating on it.

My view on how I would approach those questions are:

1. Design the interface: figure out what methods should be exposed and what input/output should be for each method.
2. Tracking state. Is there state that needs to be maintained and how should this state mutate?
3. Edge cases. What edge cases will the class encounter? Should we no-op or throw an exception if they're encountered?
4. Validation. How can I prove my code works (always start with unit tests)? Can I come up with a suite of test cases that will cover all possible behaviors?

You can cross-reference this list with how you approached the problem and see what does/doesn't overlap: if there's no overlap, then that might be an area you can look to cover the next time you get one of these interviews.

If you're dealing with smaller companies, you can always ask them for some high-level feedback. Usually, they're more generous with feedback compared to larger companies (whose processes are a lot more formal).

Have you talked to your manager about this? Just be direct about the impact the other engineer's behaviors has on you, but at the same time try to emphathize with their attempts to grow their careers (this is so that you don't appear fully bus throw-y). If your manager has repeatedly brought this up to the other engineer and there's no behavior change, I'll look to start documenting their behaviors you observed and if there's anyone else on the team that will support your claims.

Have you tried asking ChatGPT? If not:

Building projects is a great way to learn Kubernetes and Docker. Consider creating a multi-container application using Docker, then orchestrate it with Kubernetes. Some ideas include:

1\. **Microservices Application:** Develop a simple microservices-based application with different services running in separate containers. Dockerize each service and use Kubernetes for orchestration.

2\. **DevOps Dashboard:** Build a dashboard to monitor and manage your Docker containers and Kubernetes clusters. Use tools like Prometheus and Grafana for monitoring.

3\. **Continuous Deployment Pipeline:** Create a CI/CD pipeline that automates building Docker images, pushing them to a registry, and deploying them to Kubernetes clusters. You can use Jenkins, GitLab CI, or another CI/CD tool.

4\. **Scalable Web App:** Develop a web application and set up auto-scaling using Kubernetes. Experiment with load balancing and scaling policies to handle varying workloads.

5\. **Stateful Application:** Learn about StatefulSets in Kubernetes by deploying a stateful application, like a database, and manage its persistent data storage.

6\. **Health Checks and Self-healing:** Implement health checks in your application and configure Kubernetes to perform rolling updates and automatic healing based on these checks.

7\. **Service Mesh Integration:** Explore service mesh technologies like Istio or Linkerd. Implement features like traffic splitting, load balancing, and security policies.

8\. **Monitoring and Logging Stack:** Set up a comprehensive monitoring and logging solution using tools such as Prometheus, Fluentd, and Elasticsearch. Monitor resource usage, application performance, and log data.

9\. **Multi-Cluster Deployment:** Deploy your application across multiple Kubernetes clusters. Explore strategies for load balancing, data synchronization, and resilience in a multi-cluster setup.

10\. **Security Practices:** Focus on securing your Docker containers and Kubernetes clusters. Implement RBAC (Role-Based Access Control), network policies, and image scanning for vulnerabilities.

Remember to document your progress, challenges, and solutions. This will not only help you solidify your understanding but also serve as a valuable reference for others.

The show hits many/nearly all of the common tropes of the Silicon Valley, but takes them to the extreme for the sake of satire. There are many examples in real life that could naturally fit in the show like the rise (and fall) of WeWork. That being said, overall I feel like people in the Bay Area (and other major tech hubs in the US) have a higher baseline on average of trying/caring/competence, but not to the point where it's clear being here will supercharge your career.

I would take the downlevel. \
\
Fighting a PIP is stressful and finding another job in this current job climate will be equally stressful at best. Taking a downlevel will lower your compensation and you will have to fight to get promoted back to a senior engineer, but you don't have to worry about the company actively trying to get rid of you. Lower expectations will mean that it's easier (in terms of impact and time needed to create it) to meet the "do not fire" bar. Especially if you have responsibilities outside of work, you won't have the time to simply "grind" until your baseline is at the expectations for senior level. Use the extra time and mental space from the downlevel on your personal life, without the stresses of impending doom at work.\
\
If you want to stretch yourself to see if you can meet senior level: feel free to put up to an hour on my calendar & we can look to dig into nuances of the feedback.

No. The simplest example from my experiences that tear this down is to attempt coding a fix for a critical outage (bonus points for a heavy regulated industry). Like Harry Potter once said in book 5, there's a huge difference between reading about Defense Against the Dark Arts theory and an angry Lord Voldemort spamming "AVADA KEDAVRA" at you.

For the features/implementation that you're struggling on, *are they needed*? Startups often fall in the trap that they need to build something big and complicated to get footing in the market, but what they've built ends up being something that no one really wants to use. As a result, the yield (value/time) of these efforts is close to 0 as they spent a bunch of time building effectively nothing. If the things that you're struggling to build is draining your time and energy, do they really need to be implemented to validate some part of the company's hypothesis? Are there other lower effort ways to achieve this validation?

If so, I'd just get the company to pay a consultant who specializes in those domains that you're struggling with to write the code for you & help do a knowledge handoff for those domains. As a small startup, your goal is to ship out a product/service as quickly as possible. If your efficiency is reaching 0 during this journey, the company effectively lost a third of its resources. Putting a consultant in will temporarily bring the company back to three productive headcount: in additional to the consultant being individually productive, they'll at least provide some form of a baseline that you can rebuild your momentum back on.

(location and exact time TBD)

I'm pretty active in the Taro community and I'd love to meetup with folks to better learn about life as a SWE in Singapore! I'd also be happy to share out how SWE life in the Silicon Valley is like & my experiences growing up in the Silicon Valley.