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

Engineer @ Robinhood

Jonathan C

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.

From my view, there's 2 levels you can work with:

- Your skip manager. Your manager doesn't seem available to provide the support you need, so the natural step is to go to their manager. Try to put time (or regular time) on your skip manager's calendar so you can sync on the state of the/your world. You could learn that your manager is also equally overwhelmed, and there might be opportunties to support them. At the very least, you will have a connection to someone who is directly accountable for your manager.
- Your teammates. If you have consistent teammates despite the project churn, I'd look to build relationships with them. While you are the owner of larger/efforts as a tech lead, that doesn't necessarily mean you're directly executing on everything (especially when your time is limited). These teammates can support you, and it's to you to gauge what they're capable of taking off your plate. Observe these teammates & try to gauge what scope of work they're able to consistently execute on in their day to day. I usually like to gauge my teammate's capabilities by directly working with them throughout projects and tasks: this way, there's lots of opportunities to directly observe and gauge their baseline of operating. If you don't have the time to do this, I'd guage this based on their levels.

A real life example would be: I was talking to a PM in my org about how we determine what post-transfers upsells to show to users. I was trying to be high level about it to not bog them down on the lower-level details of the code, but at some point the PM straight up told me to just send them the code instead (the PM was a former engineer and has a CS degree). Since the code was just a large if-else block that felt pretty straightforward to read for anyone who's coded, I just sent them the raw code & the discussion went a lot faster. Now whenever I have to interact with this PM and the discussion is going more low level, I just start sending them code snippets in the discussion.

If I do this with the other PM of my org (who did not come from an engineering background), sending them code would simply confuse them and the discussion wouldn't go anywhere.

Listing them separately is generally what I see people do since the responsibilities and timeline of internship and full-time generally have very little overlap.

The above response was generated from ChatGPT. Given how the tool everyone's hyping to replace programmers isn't at the point where it's self-aware to generate a response saying that AI will replace all and to prepare for Terminator to become real, I think we're a bit far away from coding/programmers being replaced. Until the day AI hits sentience, if your goal is to get a higher quality programming job then you have to put in the time. If you're taking this from a more existential angle of "I'm wasting my life trying to grind for an entry level job", perhaps it might be more appropriate to treat that as a sign of burnout at the very least.

The idea that coding or programming will become obsolete is not accurate. Technology continues to advance, creating new opportunities and challenges. While some aspects of coding may become automated or simplified, the need for skilled programmers remains vital for innovation, problem-solving, and creating new applications.

Leetcode and other similar platforms help develop problem-solving skills and improve algorithmic thinking, crucial for software engineering roles. These skills go beyond just coding and are valuable in various tech-related fields.

The future of programming may witness more automation in certain tasks, but it also opens up avenues for programmers to focus on higher-level tasks, innovation, AI, machine learning, and software architecture, where human creativity and expertise are indispensable.

Continuing to learn, adapt, and acquire new skills is key in the ever-evolving tech industry, ensuring one stays competitive and relevant in the job market.

I went 2/2 for projects that better defined the direction my team and made it onto my org's 2024 roadmap. Both projects are E5+ scope (imo) and require a significant time investment. The process was really simple:

- I complained a bunch to my manager and my skip manager
- I sent out some 1 pagers proposals once I knew I had rough manager buy-in
- Months later, I saw both projects on my org's 2024 roadmap

While the process is simple, getting to that point was not.

- I have the longest tenure at Robinhood out of anyone in my org. That meant the initial baseline of implicit trust new teammates would have in me is higher.
- I'm senior level. Similar to tenure, that also increased the baseline of implicit trust people would initially have for me.
- I have strong domain knowledge: I at least roughly know how every product my org owns works. This meant that I was more capable of working backwards from product/business gaps. I knew the direction we wanted to go as an org, but also felt that there were gaps around how we were to move in that direction. So from my view, I just simply tried to fill those gaps (and didn't optimize for flashy cool kid points by being "revolutionary").
- I approached things incrementally and made sure I put the least amount of effort needed to move my suggestions forwards. A common trap more junior enginers fall into (my younger self included) is assuming there's a positive correlation between effort put in and the resulting impact. Unfortunately, life doesn't work that way: there's a certain point in which the proposal gets insta-rejected by everyone because it's taking too much of their time. My process was strategic around making sure that if a proposal got rejected, I would only lose at most a day of work. Since the time loss is low, I could easily just go back to whatever "normal" work management wants me to do and I didn't have to worry about getting dinged on perf for wasting everyone's time

I follow a rough playbook of:

- Deleting dead code
- Breaking up large modules into smaller modules
- Moving code off of older frameworks onto newer frameworks
- Splitting up code into small files/components

Usually I start my search of things to refactor at very large, legacy modules or modules under my ownership. After around a year or two of refactoring code and writing code from scratch for new products, things just clicked for me (likely from having a stronger subconcious understanding of what code did/didn't work and what patterns did I commonly have to end up refactoring).

Two things I'll call out.

1. While your resume does try to highlight the impact of the work that you've done, it's a bit of a mess to read. Some bullets points (mainly the ones that don't try to quantify impact) are just fluff, technical terms are tangled within bullet points, and there's some things that shouldn't be there (like a non-trivially sized section for hobbies). Since you can't really highlight prestige from schools or companies, recruiters will bias towards their initial impression of their resume: if their immediate thought was like mine, they'll likely bias towards passing.
2. Most of your current efforts are biased towards using what you currently have. I don't think this is working since your current experience is not strong, so the yield for trying to better sell this to recruiters is very, very low. I'd recommend shifting your focus to building a **meaningful side project** (defining meaningful as you spent a non-trivial amount of time on it with the goal of getting users). You have more control over the tools and technology you'll use and/or learn, you'll make tradeoffs and decisions that'll better reflect building real world software, and you'll build better fundamentals around ownership and iteration. Harry Potter stated that there's a difference between reading about defense against the dark arts and Voldemort spamming Avada Kedavra at you: You should apply the same mindset to software when it comes to biasing towards practice instead of theory. Do the minimum needed to send out consistent applications and focus on building a project that will better reflect practical software. If you need ideas, feel free to ask in Slack or try to emulate an existing app.

From my POV, the best way to start is to write more code. People trust based on competency, and the more direct way to prove competency is by writing code. If you're able to ship code significantly faster and better than your mid level peers, people will naturally bias towards trusting you more. The more code you write and actively think about, the more you'll passively build more muscle to write code faster and better. Once you're able to turn that into a consistent track record of delivering and shipping projects, the trust your peers have in you and your understanding of the domain will naturally grow.

Another line of thinking around the code is one of main growth vectors expected to grow to senior is being able to succinctly communicate technical concerns to stakeholders with little to no context (often, these won't even be engineers). Your understanding of the world as an engineer is built on code and the systems they support. If you have little either understanding of either and try to drive things your way, your peers will be quick to notice and they'll likely just ignore you (since they either don't trust you and/or it's frustrating that you're trying to do things when there's clearly not that level of trust). This is a very common trap many junior and mid level engineers fall into (myself included when I was more junior): don't do this. You'll likely waste your team's time and your manager will likely tell you (politely) that you don't know what you're doing and you're wasting everyone else's time (my manager had this exact convo with me when I fell into this trap). It also hurts you since that time is gone & could've gone to something that provides more consistent growth value (like improving the speed and quality of your code).

Don't try to rush things: take your time to understand the code and system you're working in. Once you have this understanding and there's clear trust in you from your peers, then start thinking about influencing the team. If you jump into influencing too soon, you'll likely end up with no results and even less time to avoid up-or-out (for the non-FB folks: mid level engineers have 3 years to get a promotion or they're fired). The only guaranteed way to make the process of building up trust and domain knowledge faster is by improving the speed you ship projects at (which circles back to writing code faster and better): I have yet to see a senior level promo in less than a year without the individual clearly being 2x-3x more efficient than every other peer at that level. Relative to their peers, these individuals have a mix of (to name a few):

- Significantly more PRs landed per half
- Faster turnaround for putting up a PR
- Needing less support to ship projects
- More projects shipped every half
- Work across more stacks than their peers
- Consistently and quickly helps other with no significant productivity loss

Should be fine: I usually sit with folks in a completely different org (I just happened to have worked on some products the org owns and have never been a part of that org officially). There has yet to be any complaints that I need to sit with my team.

At Robinhood, I serve as a SME for money movements and debit card products. How I got there was:

- I joined early(ish), allowing me to work on many, many projects across the company.
- I effectively stayed on the same team for 4 years (and counting). This allowed me to watch the codebase and the product evolve over a long period of time.
- Every engineer on frontend that could take the scope as a TL/SME either quit or got laid off. By the time headcount was secured to get a senior-enough engineer to fulfill those responsibilities, I already had the trust, experience, and title to be a TL and SME.
- I had impact across multiple stacks. As an Android engineer, my main impact is naturally on Android. But I'm also the main BFF (backend for frontend) contributor in my org, an occassional participant in backend design review, an ad-hoc data analyst sometimes for projects & SEVs, and I've code-reviewed iOS a few times (with no iOS experience).
- I answer most product and frontend engineering questions within the domains I own. I also consistently have a pretty quick turnaround for answering questions.
- My overall commit and code review count is consistenly in the top 10% of all Android engineers. I write a lot of code, review a lot of code, and I'm usually fast with my turnaround for both.

To extract some tangible advice from my experiences:

- If you stay in the same place long enough, knowledge will naturally build up and the scenarios where domain knowledge is needed will come to you.
- Often times, what's complex and/or unknown can be good growth opportunties. You'll never always know everything in every scenario, so it might be more efficient to just embrace that. Don't proactively learn everything you can, but learn thing that better allow you to address business needs.
- Unfortunately, getting good at coding is a good action item for being a SME. Writing code better and faster means you'll have more time to flexibly use. Being fast also means you can tackle more projects, and being able to successfully deliver more projects relative to your peers means you've had more experiences and more impact (and the people around you will implicitly trust you more). If you use that productivity gain to write even more code, your knowledge and intuition around the code will deepen. Deep knowledge also compounds when you apply your mental models across stacks: I haven't written traditional backend code in years, but I'm participate in backend design reviews using the same mental models I have for building Android apps.
- Be helpful to people. Supporting people who need help with something you own helps reinforce domain knowledge, provides opportunities to identify implementation and process gaps, and builds people's trust and visibility with you.

Hope this helps!

1. Execution matters more than the idea itself: even if you pick an existing idea, people will still download it if there's a clear benefit to existing solutions.
2. Off the top of my head: try building apps for a niche community (a hobby, an online community, etc.)

I wouldn't treat a side project like working in a larger company: the focus should be on the execution of the idea not the archicture. Users in the end see the product and not the effort and process that went into it. Focus on getting clarity on the idea, figuring out the minimum set of features needed to use it, and then build it as quickly as you can. If you treat this how you would approach work, you'll likely end up stuck in the forest of ambiguity and ship nothing (either from eventually get bored/burned out at the fact that you're effectively working an unpaid job and you don't even get paid for wasted time).

At my previous startup, I was in the same boat. I was constantly trying to learn and apply best practices because the codebase I was working on wasn't great and the engineers took a slower, more relaxed approach to development. Ultimately, close to zero attempts to change the culture happened and I ended up leaving for greener pastures. While my scenario might not exactly be the same as yours, hopefully bringing in some of that perspective will help paint a clearer path forward.

How I (as a tenured senior engineer) would approach a world where things aren't great is to identify the problem as **1 simple truth**. When problems are identified as a single, simple truth, it's much easier to understand them and to align on them (less is more). If you provide a list, you will overhelm others. If you jump directly to executing this list of things, you're perceived as engineering for the sake for engineering (which reduces your social capital). From your description of the response to your changes, it's clear to me that you started with the list and not a simple truth. Develop the 1-liner statement first and get alignment on that statement. When asked to clarify, state both your perceived observations and the impact together. Bucket things into higher-level problem groups: again, simple truths are much easier to be understood compared to "here's a list of everything to fix". In your situation, you can try something like "Our legacy tooling and practices is slowing development down. I have observed x, y, z themes of scenarios in which this is visible".

Once you've aligned on the simple truth, then **identify what is the single, most impactful effort you can do to mitigate the problem**. This will narrow down the surface area of your changes, lowering the changes you need to make and how many new things other engineers need to learn. You also want to treat each effort as a risk. Every effort you attempt can fail by making it appear you made the status quo worse. If you reach a point where you've made multiple changes and ended with more unsuccessful changes than successful changes (your value is negative from making things worse more than better), you'll have no social capital and will likely get PIP'd/fired soon. Comitting to one thing also establishes focus: you won't need mental overhead to juggle competing priorities.

Once you're identified what effort to focus on, you need to minimize the blast radius of developers impacted by your efforts.

- The first step here is to **act as an owner**. Do whatever it takes to make sure you don't break builds and you don't break/delete existing tooling and processes: **whatever you do, make sure the boat doesn't rock**. It's incredibly frustrating whenever workflows change while working on a timeline (the tighter timelines are, the more frustrating it'll be). Every single issue that is potentially related your efforts, you need intercept and resolve them as fast as you can. This will establish that you're proactive as an owner and that you're not a boat rocker.
- The next step is to **start with 1 person**. Ideally you want to start with who has the most trust in the company, but anyone who's willing to test your efforts will do. (Relative to more than 1 person) it's much easier to be attentive to one person and to get a commitment from management for volunteers. Your goal with this one person is to sell to them that your efforts will (without a doubt) benefit their workflow. Do as many walkthroughs as needed to teach them, write all the documentation is needed for them to reference, and address every question/comment/concern/feedback they have. If they are clearly sold on the idea of your changes and have mastered them, then you can move onto onboarding more people.

Once that individual is clearly sold on your changes, look to onboard their team. Work with this individual to help sell the team on the benefits of your changes and help onboard the team to them. As a member of the team, their team will trust what they say (and that includes their vouch for you). After some reasonable amount of time (up to your discretion), have them fill a simple survey with a single yes/no question: are these changes an improvement to your current workflow? If less than 67% of respondents say "yes", iterate on the feedback of people who said "no" until you have at least that 67% ratio.

After that, it should be a relative breeze: onboard more and more teams onto your chages and keep surveying them to make sure you maintain at least a 67% ratio for people who are happy with your changes. Once the majority of folks who benefit from the change on onboarded, work with management to put a date to delete the old stuff and to move everyone onto the new changes. At this stage, there will be little to no questions: there's clear metrics around the benefits your changes and there's people who will vouch for you. The worst scenario for people now is that they are bregrudgingly willing to migrate.

Finally, you're done! Now if people want you to keep going, pick the next most impactful change and repeat the process starting at working with 1 person.

To compress this down to make it easier to extract learnings: you are probably in the right for taking on efforts to improve tooling and infrastructure, but your gaps are around understanding the people around you and your standing with them. Given their responses to your effort, you tried to directly replace existing tools/processes without direct and thorough consulation with ICs to build clarity, empathy, and trust in your efforts. For me, your current approach would only work if you were a tenured staff+ FAANG engineer in a company with 0 ex-FAANGs (then it's inefficient for everyone/anyone to fight your efforts compared to unceremoniously complying). The key lesson is that social capital impacts your ability to execute: if your name or resume doesn't immediately demand respect, then you need to build up social capital. The larger the blast radius, the more social capital you need. To avoid efforts with larger social capital needs (like company-scoped infra migrations), break down the effort into an incremental set of small steps. The process will be slow, but that reflects on how we (as humans) are generally slow to change.

If you're getting a "Meets most" with 2 years at FB (and I'm assuming you joined at a mid level), you have 2 paths forward:

- Go for an all or nothing hero mode play for a senior promo
- Look for another job
- (With a "meets most" in this economy, there's pretty much no chance for a team switch to be approved. Especially when you only have 1 year left to get a senior promo before facebook's up-or-out removes you.)

Even if you somehow hero mode into a senior promo, you won't be able to get to and then sustain senior level with a healthy work life balance. So I can see where your manager is coming from: assuming you joined at mid level, your more efficient path is to look for another job. But if you were promoted to mid level recently, then you'll have the time and space to try to recover next performance cycle. 

Learning in an academic setting is different than learning the skills needed to succeed at the job: the former works in isolation while the latter requires working in a broader environment under some amount of time constraints.

If you want to succeed as a junior engineer from a non-traditional path, the problem you need to solve is "how I do I succeed at my job" and not "how do I succeed as a student studying computer science". Work with your manager to establish clear expectations for your current level and your next level, your timelines targeting your next level, and the growth opportunities you're interested in. If you try to approach the real world with an academic/student mindset which biases towards hoarding/collecting classes, there will be a high chance of failure (imo). You need to work with the people around you and figure out their expectations for you. Only by understanding and working to meet/exceed those expectations will you succeed.

From the outside looking in, I see 2 things:

- Your tech lead is likely frustrated that you aren't meeting his expectations and isn't doing a good job expressing it
- You're getting pulled around and no one is setting the pace for the work you own

My guess is that the E5 might have planned the project around your ability to hit their expectations for E4, and you're missing those expectations (which is frustrating him). Given the scenario you described and your behaviors in it, there's some gaps I noticed:

- You are letting others drive the navigation of the project
- There's a lot of mentions of people saying/agreeing on things, but no mentions to how it's tracked

Building on this rough view, this doesn't feel (to me) like a scenario I'd expect a E4 to struggle with (and I'm extracting my guess of the TL's behavior based on this). At E4, you need to dictate the pace of the work you own by driving decisions, timelines, trade-offs, and alignment for the work you're implementing.

Given how there's competing deliverables and a lack of alignment, there's clearly E4 scope in my eyes. I think the main behavior change that needs to happen is driving alignment. There's 2 parts to this I'd recommend you to focus on:

- Whenever teammates/xfn staleholders aren't aligned about the deliverables you own, you need to be the one who's in charge of the decision. You need to be the one getting everyone together to make a decision, identifying and looping in the right stakeholders, and creating & leading meetings to get people to talk (and making the call if things need to go that far). If your manager or TL are the ones who frequently end up leading the discussions to clarify your work, you'll likely trend away from E4.
- Document decisions. It's one thing to get people to agree on things verbally, but it's another to have proof that they did. Whenever these discussions happen, have at least 1 person taking notes (or be the one who'll volunteer to take notes). At the end of the discussion, repeat the key decisions to double check that everyone agrees to what was said. After that, publish those decisions in the project channel (the more public the better). If you don't feel people will have confidence in what you say, get your TL or EM to post for you. Since your TL is the main point of misaligment, try having them post these updates. This way if they question what you're doing/prioritizing, you can pull up a post of them publicizing the decisions that led to your current priorities.

Hope this helps!

As you get towards the more senior side of the ladder, the bias/preference for the expected impact actually leans towards problems than specific tools. Tools are simply a mechanic to solve problems, and don't provide any inherent value when used in isolation. Let's say I have 1000 hours: I could build a heavily polished AI-based dating app for cats or I could work for a fast food job for those hours. Generally, the fast food job will net me more value because the cat dating app provides no purpose or value to enough users where a growth/monetization plan can be executed.

If you feel like AI can solve the core problems you or your team face at work, then there's a clear problem space that can be addressed by becoming more of an AI engineer. Else, you're just giving into FOMO and wasting time that could be used to build up engineering fundamentals (communication, xfn leadership, domain knowledge, coding experience). Fundamentals will carry over with time, but anchoring yourself on specific tools or technology will not.

Building on top of the existing advice, I'd also recommend that you start narrowing down on where you're publishing your paper trails at. Often times, if there's no visibility (no easily accessible public artifacts like comments on tickets, design docs, documented weekly updates) on what your process/progress is, your broader stakeholders will often assume the worst case scenario that you're slow and inefficient. Try to identify how you can communicate/document your progress in a more public manner: whether it's by posting regular comments in tickets, asking more clariying questions in public channels in your company's internal messaging app, or providing more granular updates in standups. This will also benefit you individually in the long term as information you've encountered in the past will be more readily available to you (and anyone else who's interested), allowing for a quicker turnaround time when you need information from the past.

You can expect the higher/highest end of the junior band: generally, a PHD is required if you want to start out as mid level after school.

As an entry level SWE, you unfortunately have no influence: your skills and compensation are not at the point where ignoring you will clearly turn out to be a costly mistake. In this scenario, there's 2 ways I'd look to proceed:

- You need to find someone who has leverage (either by role, seniority, and tenure) and have them consistently support your concerns. While you don't have influence, you can leverage theirs. If people trust your opinions when this more influential IC backs them up, that trust will trickle back to you.
- You need to align with your manager on your concerns on the project and the risks of not addressing them. If you aren't able to consistently document your concerns with your manager, call out the risks, and document the final result of the team not addressing those concerns, your manager's view will be that your delivery is terrible.

(Assuming US) If you're getting RSUs that can be sold in a public market directly, it works like this:

- Every vest, a % of your shares are withheld for taxes (this applies to your paychecks as well). The default (and the usual minimum) I see is 22%. So if you do nothing, 22% of your compensation is likely going to taxes proactively.
- You able to change the withholding amount for your RSUs on the platform it's granted through. Keep in mind this can only be changed during certain time windows (usually right after earnings). You can bump this up to 37% (this is the maximum you'll ever have to pay in taxes).
- At the end of the year, you pay (amount of taxes the IRS expect) - (amount withheld). If you overpay, you effectively give the government a 0% interest loan for what you paid extra. If you underpay, the government is effectively giving you a 0% interest loan on what you owe. If you underpay too much, the government will charge a small interest % on top of your missing taxes.

Generally there's an unspoken limit of 16 days, but how strictly unspoken limits are enforced are highly dependent on the company culture around PTO (e.g. if everyone else is taking 20 days off a year, you should too) and your current performance in the company (if you're at least meeting expectations, PTO is less scrutinized). Your manager and your teammates would likely have a pretty good pulse on this, so I'd look to ask them to guage more specifics.

You don't really need to bother posting on linkedin unless there's clear value for your brand you're trying to build through social media. I personally post on linkedin every day trying to connect with Mr. Beast to only satirize how linkedin is mostly filled with low quality influencer content.

For my current skip, the conversation for me feels like a dynamic where they're giving me trends/direction from broader leadership while I'm providing trends/direction from the IC level (for example: my main focus with manager 1:1s has been pushing for the platformization for Robinhood's payments experience & creating the space to define what successful platformization means). I think ancedoctally for me to get into this position, I was able to provide a fairly nuanced view as an IC backed by years of domain knowledge in the company/product.

Extracting my anecdotal experiences into advice, I'd say the main thing is to look to provide your manager an on-the-ground view of what's happening. Your value as an IC is that your high level view has grounding in what's building it and who's building it (whiles managers hold more of a high level view and rarely/never have to dive deep into the weeds of coding with other people), and you should use that to support the M2 define the direction of the team (in a way that balances the health of engineering with the health of the business).

If your goal is to increase compensation and job security, the best path forwards would be to start interviewing and look to secure other offers. Within your current situation it seems like the variables you want to budge aren't budging, so if you want something to change you need another offer on the table.

No one's really that safe from layoffs in this economy, but big tech does have larger war chests. So Amazon's not that bad of an option if you just want to settle on a job that's relatively safe.

(To provide an anecdotal data point to the scenario you're running into, I got my senior level promo with a first-time manager)

Getting a new manager who's new to management leaves a fairly unclear path, especially if you're a mid level trying to grow to senior. You mention that working with these managers are often times stressful and unpleasant for you, but why is that so? Are there any common patterns around behaviors you can provide a general summary for? I would go through this exercise and then talk to your skip manager about your past experiences with first-time managers and talk to them about the common themes you're identified around why those experiences weren't great. You can also look to talk to your skip around what support is being provided for your new manager: getting a clearer view around the support system for your new manager might help give you some relief that your new manager isn't just going into management blind.

Can you look to provide some examples of scenarios in which you feel the team is not communicating better and where you feel the gaps are? While this is a not an usual problem, there's definitely a lot of contextual nuance that impacts how to approach the problem.

(I've reported to M2 twice: once as my official direct manager and once when my manager left the company and I needed a temporary manager)

From my conversations with M2s, I was able to get much a much higher level view of what the direction of the org/projects look like and what were the broader problems in the org and product. I felt like I was able to come out of those conversations with a much broader and/or deeper view of what's next, which made it easier to adjust my line of thinking for the future to match the direction of my org.

Since your current position puts you in a spot where you have to fight for E6 scope and your skip manager seems to be on board with supporting your growth to E6, reporting to your skip manager feels like a strong path forwards. This puts you in a more direct position to get a view on the org and will likely provide you opportunities to tackle org level problems.

Hope this helps!

As a junior engineer, a lot of your contributions to those documents are just going to be questions (usually along the lines of "why did we do &lt;x&gt;", "did we consider this alternative", "did we consider &lt;y&gt; alternative"). It takes years of nuanced experience to properly give feedback, so I wouldn't worry too much about providing good feedback. Focus on executing on your existing work/projects, take up increasing broader ownership, ask questions along the way: you'll gradually build up to foundations to provide more nuanced perspectives on those docs.

For design docs, what I usually look out (as a frontend engineer) for is:

- How cleanly is the doc broken down: is it clear that I can indepedently review pieces of the doc? Is it clear how the project is broken down into subdomains, milestones, etc to allow for clearer separation of concerns, parallelization of workstreams, more granular incremental rollouts?
- What schema changes are we making to APIs. Common questions I'd have is: how flexible are these changes for future products, are these changes backwards compatible, and if logic is shifted to be on the other end of the stack does that simplify the design.
- How granular is the business logic broken down. Generally, I use the design docs as a heavy reference for how I write code, so the less thinking I have to do to map the doc into code, the better.

For OKRs, it's more nuanced and vague: a lot of it comes from working backwards from what domain(s) the team owns and what problems the team is currently facing. Another part of it comes from experience on what OKRs did/didn't work previously for the team (or for previous teams engineers were on). I can give you my view to provide a starting reference for thinking about OKRs as a senior product/frontend engineer.

- A team should have between 1 and a handful of metrics they're driving to be bigger. Products generally drive users to behaviors that positively influence the business, so the team should know what causal chains they can/want to influence within the realm of the product.
- I'm not a big fan of having a flat goal as the top level goal OKRs (i.e. "10m new signups in 1 year", "+$50mil for revenue in 1 year"). Quantifiable goals are great for establishing a baseline to relatively tracking progress, but often times external factors can drive teams to be closer/further away from numerical targets (example: for 2 years, my team hit goals despite shipping very little at all). So I like structuring OKRs like "Our goal is to do &lt;x&gt;. We plan to do &lt;x&gt; through &lt;y&gt; projects, and we project &lt;z&gt; metrics to change" and pushing the team to focus on doing &lt;x&gt; as a goal. This way, the team is more focused on the goal rather than trying to think about hacking the last bit of value to hit &lt;z&gt; metrics.
- When thinking about projects or OKRs for the team, time should always be considered: more specifically, time to execute. Is the time to execute something the team is comfortable with? Are there clear bottlenecks in development present across every project? If there are clear bottlenecks, incorporate projects to tackle those bottlenecks in the OKR doc and call out how those projects will help the team in the future (depsite usually not generating any immediate ROI).

Hope this helps!

As for your concerns about your growth and your career: thess is an opportunity you're clearly excited about, there's a comp increase, and the company is able to hire tenured talent from other notable tech companies. Just take the job: what determines your career growth is less about the companies you work for, and more about the behaviors and fundamentals you develop throughout your career. If you want to make sure you'll have the support needed in the new company, work with your manager to have a clear growth plan and maybe even find a mentor who's willing to take you on.

Android Engineer @ Robinhood

Congrats on the new job! It's great that you're excited about the opportunities ahead and proactively thinking about how you'll hit the ground running. 

Unfortunately, planning too far ahead (especially without reputation or a clear structure with the team/company) won't end like you'll expect: it's very likely that you won't be able to execute on that plan at all (either due to the company putting you on previously committed priorities or because you don't have the reputation needed to get traction on suggestions). This is a wrong turn I've personally taken down and a common one I've seen among junior and mid level engineers. The more detailed you are with things without a nuanced grip of team/business context, the more likely you will fail and waste time for little yield. Things are constantly changing in any healthy team/company, and attempting to force structure into something preestablished will not work. If you fight against the natural flow, your time and energy will be spent for little value and the current will probably just plow you over (aka your manager or TL politely tell you to work on some other task/project instead). Don't get me wrong: the things you are proposing are nice and generally good things to do/have, but the question is: does the team/business actually need these things right now? And are you even the right person to solve it?

If you want make the best impressiom you can and build a healthy path for senior, the main recommendation I have is to start out by being more passive and progressing with the flow of the team/company:

- Be thorough with your onboarding tasks and projects. Ask questions around the tools and frameworks used in the company, and try to clearly understand their interfaces and why the company chose those tools/technologies.
- Oberserve the people on your team and on your projects. Who is on your team? What responsibilties do they usually fulfill? How do they behave when they're interacting with different stakeholders?
- Instead of introducing solutions and trying to find their problems, observe the problems and then fix them. If there are any technical/process gaps you've observed during your onboarding that you have the exact experience at that moment to efficiently fill them in, look to fill them. If the team has a problem with writing tests efficiently and you have experiences with a framework that solves that problem, introduce it. If your teammates have a hard time chasing xfn threads, own driving some xfn discussions into clear action items or outcomes. As a senior eng, I will say this is most important thing that makes or breaks if you're perceived as a senior eng/lead: it's very easy to tell the difference between a junior/mid-level engineer who's trying way too hard and thrashing around and a senior engineer who's passively identifying and resolving issues they encounter.

Do you have metrics set up quantifying the value that you're bringing? If your team's goals is to save customer support time, it might be helpful having metrics around the time needed for customer service to onboard a new feature. Once you have that value, you can multiply it by the dollar average a customer service agent gets paid to paint a clear picture.

Another line of thinking might be you're trying to get acknowledgement from the wrong crowd: engineers generally don't have that much visibility about support, but the folks on support who are using your tools would. If you get acknowledgement from customer support leadership, that might help get acknowledgement from the engineering side.

It's a bit hard to have a complete grasp given the vague description, but it seems to me the scenario is that they're unhappy with your velocity and they do a terrible job expressing themselves. If you aren't the only person the project lead is overseeing, you should ask your teammates privately how they feel about your project lead's behaviors. If there's a general negative sentiment that can be documented, I'd look to talk to your manager about your project lead's behaviors.

This is a great opportunity for growth for a more experienced engineer, but as a new grad this is unfortunately an opportunity that will inhibit your growth in the short term. Since you're at the beginning of your career, you need a stable environment to build up your fundamentals as a professional. There are things you can do though to push for a better situation:

- I would voice your concerns to your manager that there's instability in the team due to a lack of domain knowledge and tight delivery timelines. I'd push the recommendation to your manager to push back on the timelines and to look into having a team lead (either by empowering an existing report or by getting one through an internal transfer).
- If you feel like there's information gaps around things your team is doing repeatedly, write things down on a public document and share your notes with your team! This might even push other teammates to do the same, creating a stronger knowledge repo.
- Building on ^, one of the main ways I built up domain knowledge in a critical domain in Robinhood that had no stable owners was that I'd help people. I tried to answer as many questions as I could about my team and the products I owned, I'd provide advice to help others debug, and I'd loop in the right/better owners if I couldn't help but I knew who could.
- Worst case, you can look to transition into a team that's more stable and with work you're more interested in. Generally, the expectation for an internal transfer is that you need to be meeting expectations at your level on your team. I'd start thinking about this option around 6 months into the job.

Hope this helps!

I'd follow this format (from top to bottom):

- Work experience
- Side projects
- Skills
- Education

As a new grad, having a limited resume is fine. A lot of your time was dedicated to school, so it's fairly hard to find something meaty enough to properly fit on a resume.

The general steps I follow are:

- Write small pull requests. Smaller pull requests are much easier to read for everyone, making the overhead with interacting with the diff lower. Reviewers can provide much more narrow feedback, you're much more easily able to write focused tests, and it's much easier to infer context from the code.
- Write detailed summaries on the pull request. This usually varies based on what the pull request is for, but I do a mix of: linking project specs (and designs if it's for the frontend), writing a test plan, explaining how I arrived at the current code for the diff.
- For any pull requests that touch code, write a test plan on how you tested the code (manually, existing tests, new tests, etc.). If you cannot perform any sort of testing, explain why the changes can't be tested.

tl;dr pick any language/framework/platform and stick with it. The skills will naturally come as you get more experienced.

If you're at the phase of your career where the one of the main questions you have is what tech-stack/framework to use, the general & narrow advice I'd give is to focus on any 1 tech stack. Learning how a framework works takes a lot of cognitive overhead (and the domain knowledge is generally isolated to that framework) and learning multiple new frameworks means that you're incurring this overhead multiple times. Repeatedly operating in the same framework allows you to eventually thinking less about the how the framework works and think more about the nature/quality of your code and why the framework is designed the way it is. Once you have a strong baseline of writing code in that framework, you're able to leverage that as baseline for understanding how other frameworks, tools, language works. As you grow more experienced, you can find yourself building soft skills around this baseline since your understanding of the framework serve as a baseline for how you communicate technical details in an abstracted manner (for non-technical stakeholders).

Hope this helps!

Let's meet up in Fremont & have some pizza! I'll be out of country next meetup, so I'd like to meet some folks (both new & old) and say hi. The pizza place is vegetarian (with vegan options), so there'll be food for nearly all diets.

Transit info:

- There is ample free parking nearby.
- The location is a long walk/short drive away from the Fremont BART stop. BART only does clipper cards for payment now, so look to have that set up beforehand.

(If 50 people show up, maybe Mr. Beast will finally connect with me on #LinkedIn...)