5-year of practical software experience is enough to get interviews at most companies with a recent resume. Just apply.

I just work here @ Robinhood

Jonathan C

Don't jump on the latest trends. Focus on getting good at writing code in some modern language by quite frankly writing more code.

If you're looking for entrepreneurship, a PM job likely isn't that much of a jump. Honestly, being proactive at finding opportunities & convincing others is the better shift to make (and that's not really tied to any job).

Focus less on titles and more on what skills & behaviors you want to build & loosely rank them on how important they are for you. See if you're able to find opportunities to build those skills/behaviors and leverage your manager to help you opportunities as well.

Roles are just a string and there's not hard-coded fixed list of things that narrowly defines what is OK/not OK in each role. The control over the skills and behaviors developed in your career is what matters for progressing to your goals. If that results in a role/title change, so be it. **But don't be dependent on needing to switch to PM as a deciding factor to move your career towards entrepreneurship: doing so is 100% a skill issue.**

Since you're joining at mid level, the good news is that a lot of the momentum is coming from individual skill.

The main behavior I'd demonstrate to show that you're serious is being proactive.

- Don't wait to take up more tasks for your project(s): just take them.
- Someone has a question around your domain? Give them an answer and potentially some references.
- Code isn't as clean as you could be? Fix it along the way of your current task.
- Are there tasks on someone's else project that could be parallelized with an extra set of hands? Jump in.

Being close to E5 at Meta means nothing to your Anthropic manager: so you need to set the baseline that you're doing more than what's needed beyond E4/mid-level and that impression can be seen. If your manager views your baseline as an average mid-level engineer, they likely won't take you as seriously. Once that baseline is set, I'd look to the following two:

- Ask your manager for opportunities to lead projects to show senior-level compotency. If you really want the senior-level promo, bring this up every 1:1 or every other 1:1.
- While you're proactively poking around the broader scope of the company/team, see if there's any gaps you can help fill around existing projects when it comes to project leadership. Why wait for your manager to give you opportunities when it could be faster finding them yourself?

Before switching teams, do you know if other engineers on the team feel the same way? If it's just you encountering this level of friction, your manager sees the world like this:

- E6 with longer tenure with more equity is doing things the way they always do. This has historically had impact for the team/company/org.
- You (new E5) comes in and doesn't work well with the E6.
- You complain to manager.
- E6 gets paid more and has longer tenure =&gt; bigger risk to the team/org to disrupt them.
- Therefore, your manager will bias towards the E6.

In order for your feedback to be received, you need to put more weight on your side of the scale. You would need an E5+ in your org with tenture to also vouch for you. If not, your manager won't take any action.

Coming from someone who's in the position your E6 is, the main thing that causes me to more aggressively shoot certain people down if they don't follow the same principles as I do. I'd look to figure out the following:

- What does your E6 value when it comes to engineering?
- What patterns does the E6 display when it comes to reviewing artifacts (code, docs, etc.)?
- How does your E6 view the world around them?

Once you figure those out, try to see if you can proactively incorporate those learnings into your workflow. Download your E6 and work with/around their behaviors. It might help to have your manager mediate in case you don't feel like your E6 will respond well.

(A few other misc notes)

- It's plausible that you might be taking enough scope to risk their E6 standing. If you feel like the friction they're putting is often amounting to nothing, start documenting these occurances and if they amounted to some changes.
- One key piece of feedback I got growing towards a TL was that I needed to shoot people down more.

A sprint is just an arbritrary construct to ensure some level of consistency. I'd focus less on completing the sprint and more on proactively calling out if the corners you're cutting should be cut or not. In the end, business impact is what matters the most if you want to judge the value of your work.

Yes. Depends on the mood: sometimes I go for more fast-paced music when I need to spam code, but usually I do a mix of city pop & random youtuber drama videos.

Yes. I had my role as Software Engineer (Contractor).

When I contracted at Pinterest, I just said I was contracting at Pinterest during interviews. Even as a contractor, the big tech name does attract eyes.

Let's start by looking at metrics and measuring impact with it since that was explicitly called out.

How would you prove your code actually did something for your team/company? 

Some line that the company is tracking is going up. That line is a metric. If your project helped the company, the line's slope goes up more. That change of slope is your project's impact.

For larger efforts, the main expectation is that you are able to disambiguate what needs to be done.

Right now, we can see from your question you're leaning towards thinking about it as one big thing. You've broken it down to a few sub items, which is a good step forward.

The next steps would be: how should the work be sequenced? Let's start with the first step: there's always a first step in the project. Out of the different things you need to do, what should be done first and why should it be done first? And are you able to break it down into an even smaller action?

That's a lot of questions, so let me start with one to help you move forward: what's stopping you from doing everything right now without needing someone else to carry you? Answer this question and see if you can narrow down on something from that answer that you can immediately do independently.

For general junior =&gt; mid level advice, I'd recommend:

- <https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/how-this-course-works/>
- <https://www.jointaro.com/course/grow-from-junior-to-mid-level-engineer-l3-to-l4/how-this-course-works/>

The best to understand a programming language is to write more code in it. Your diff count is the main metric used to guage your skill level. To repeat: **just write more code**. Anything else you can potentially try to do provides negligible value compared to getting better at writing code and landing diffs.

The main heuristic for junior engineers is diff count. If your count is low, you will not get anything above meets all. If you are an expert, it will show in your diffs (volume and quality will be examined, but volume is an easier step forward & more quantifiable).

- Dig into why your management thinks that this on-call is a high impact opportunity.
- Not every opportunity is tied to your role & and the highest growth opportunities beyond senior are often outside your role. Take an extreme ownership mentality: focus on potential impact that you're able to execute on and not if it fits the bound of your role.

Take whatever # of diffs you're averaging in a day and 2x the volume. A lot of code you're writing will be specific to Meta & learning outside of your codebase won't be as valuable.

Since your marriage is 1 year away, I feel that's enough for 1-2 attempts at switching jobs. Given your years of experience and your current job at Amazon, you should be able to secure mid-level interviews.

But the honest question you want to ask yourself is: do you really want to live in the Bay Area? The weather's nicer and all, but housing here is quite expensive and it's like 80% sparse suburbs. If you don't like the bay area, it's going to be a potentially expensive reversal (time and money). I'd start with having a ranked list of what you're looking for and working backwards towards what that maps to location-wise.

Are you always afraid when you're walking down any stairs that you're going to fall and get injured? Is your mind working in overdrive to figure out how to put one foot in front another?

(Assuming your body is perfectly fine) No you don't. Becauae you've spent so much time naturally walking and occassionally using stairs that you just do it.

It's the same thing with coding: just write more code. If you are actively trying to improve at coding, you will start spend less energy and effort writing code. With one less thing overworking your brain, you'll have more mental bandwith to focus on other things that need attention.

I would also recommend checking out [Taro's resume course.](https://www.jointaro.com/course/get-more-interviews-write-a-stellar-resume-as-a-software-engineer/how-this-course-works/)

Instead of paying the $50 on fiverr maybe you should pay me instead 🤔🤔🤔🤔🤔🤔🤔🤔🤔

The experience is okay enough where it should get bites, but the resume formatting is not that good.

First priority: if you're paying more than 1k yearly for the masters program and/or spending time regularly on it, **drop it immediately**. Your career is too late where a master's program will help out your career and it's sucking up time and money. If I were an employer: Stanford or bust. **(Assuming you are a US citizen) No other school quite franky justifies the value for the "oh I want to do a Masters to make myself more marketable" route other than Stanford.**

I read your work experience and honestly I just glazed over it. It's fairly verbose (in terms of the wording and the number of bullet points).

- Everbeat: number of bullets points is fine and you clearly wrote code for the stuff. But what was the impact? **What does the company/your team do to provide value and how did your work further that?**
- Amazon: there's a brazilion bullet points with lots of words. My mind pretty much shut down when I read this (code for "your resume is getting tossed"). **Have less bullet points with simple, more concise wording. And focus on impact.**

Honestly, just run your resume through ChatGPT for free and ask it to make the wording simple & concise and flatten the number of bullet points. That'd get you the most yield of your time and money.

I'd start with writing more code (without sacrificing code quality) than every other SDE1. The first step to get promoted is being better than the average of your current level. The next step is to build the behaviors of the next level.

This course will likely help break down the path more thoroughly: <https://www.jointaro.com/course/grow-from-junior-to-mid-level-engineer-l3-to-l4/>

For showing more impact: get to landing diffs as quickly as possible.

For 2-3 months in towards E5:

- Be in the 80th percentile for diffs landed
- Start reviewing code
- Start answering questions for your team

For dealing with politics: get good at writing code. You're likely fighting other mid levels for scope due to up-or-out and they're all asking for scope to get promo'd. Asking is not enough (since every other mid level engineer is doing this): you need to stand out. At mid-level, the main bar is execution. So the focus on standing out should be on execution first.

For the 1 year target with your manager: I'd bring it up early on in your 1:1s to set the pace (after you're done onboarding is a good time), but I wouldn't expect much in terms of having the E5 promo in a year secured. Most likely, your manager will do their best to set you up and you end up with "Exceeds Expectation" (no promo) if you meet your manager's expectations.

For what to focus on: write more code. In this economy, the efficiency expectations are much higher for senior. Strong foundations are needed to more quickly break problems down into systems and code. The simplest way to get better with code is to write more code. The more time you spend thinking about code, the less time you have for impact.

Do you feel like the growth of the engineers is reflecting more the growth of the company and not the engineering culture? If the team skews fairly young & most folks spent most of their career at the company, their view of the world is narrowed down to what works for them at the company.

Instead of rolling with the existing system, why not try to fix a small part of if? If you're serving as a TLM (tech lead manager), there's a clear line of influence on the engineers around you. If you don't think you can get buy-in from upper management to fix things, then just fix it first and then tell them later. There's a clear opportunity with the DB updates: why not get your team to make the deploy faster?

There's always a hypergrowth and/or high-paying company out there, but you only get one life. You can't work hard to make money when you're dead. If it's starting to look like the stress is causing long-term health issues, just quit.

You have \~6 months to stabilize from your join date (9 months would be the maximum stretch). If you have a decent manager, they'll likely save you if you get a Meets Most (MM) trending towards Meets All (MA).

- No.
- Focus on building 1 good app and learning the concepts behind it along the way.

As a fairly senior Android engineer, I don't know the internals of many of the newer frameworks. And I honestly don't need to: the skills needed to grow to senior and beyond is heavily skewed towards non-technical skills. If I need to learn it in order to accomplish a critical task or goal for the team/company, I will learn it. Else, the knowledge doesn't give me that much value.

For evaluating interns, I'd evaluate the following (ordered by descending value):

- Repeat internships at top companies
- An internship at a top company
- Strong side projects (thousands of downloads for mobile apps, thousands of daily page views for a web app)
- School

It's easier for earlier career enginners to focus on creativity and ideas: the understanding of the world is smaller, so the view of paths forward are more short-sighted. If you can only see 100 meters ahead, how can you immediately tell the cliff ends in 500 meters?

The first step to understanding if software engineering is not for you is to get more experience. Get more software engineering experience, but also see if you can incorporate learning about other roles along the way. Build up a strong track record so that people in the roles you're interested in are more willing to invest their time in you (either letting you take on some of their responsibilities or properly engaging with you during conversations). People are generally nice, but that doesn't necessarily mean they're going to properly spend their time for you.

As an experienced frontend engineer, I've worn many hats to get something done (frontend, backend, data analysis, product/project management, etc.). I just see the world as using my time and skills to solve whatever problem. If you anchor your view on the world based on the limits of your role, often times you miss the opportunties to grow and change standing there right in front of your face. And that's often why most junior engineers who have the same mentality often fail with zero progress: they only see the destination and never see the steps towards that destination.

If you really need space and time and have the money to pay for rent/mortgage for a few months, you can try applying for FMLA & using that leave to study for your next job.

I work around 35ish hours a week pretty consistently and I spend 20% of that time browsing the internet. This is what worked for me.

- **Understand what times are you generally more productive**. Out of morning/afternoon/evening, identify which one are you most productive in. Organize your work so that your most important tasks happen around that block.
- **Understand how focused you are as a person**. Some people have long attention spans, some people don't. I personally have a very short attention span. Build your focus blocks around how you naturally work around your focus: if you have a short attention span for example, long planned focus blocks will not work (instead plan smaller blocks for shorter bursts of focus).
- **After a certain number of hours work, behaviors &gt; impact**. If you're doing the same work in the same exact way given the more hours, you will not be rewarded with a higher rating or a promo. Promotions are mainly about developing behaviors that have a higher baseline of impact. For every task/project/whatever you get, ask yourself how this will grow you (towards the next level). If you can't give yourself a clear answer, spend your time trying to shoot down that task instead.

Engineer @ Robinhood

You should focus on what you're assigned by your team and not think about the broader cross-collaboration of the team. You don't have the experience to know how to use the knowledge of how the other team operates, so getting it will yield 0 value of your time. 

Start by repeating this scenario.

1. You are writing some code for task X
2. You need to touch Y code/service owned by the other team
3. You are unsure how this integration works
4. You ask Y team how to do the intregration
5. They tell you
6. You do it

As you repeat this scenario with the same team, you should look to get more effective at this pattern by doing some of the following:

- When you go to Y team, you will provide them with your best guess on what you think you need to do
- You reference a past task that you or someone else has done that you looked at & mention what information you got from it
- You narrow down the scope of your question ("How does this API work" =&gt; "What does Z field in the API request do"  =&gt; "I set use Z field in this specific way, will the API behave in &lt;blah&gt;")?
- You ask your questions in more public mediums (like a public project Slack channel) so that others can reference your question in the future

A collaboration means someone else needs to spend time with you to get something done. Your first step to getting good at this is spending your time to make sure the other party will spend the least amount of time and effort to work with you. The [asking great questions course](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/how-this-course-works/) establishes a pretty good framework that also works for thinking about collaborations.

That Android engineer pretty much sounds like the position I'm currently in my org. So the perspective that I can share is how did I get into this position.

- I wrote a ton of code: I consistently do 2x-3x the yearly average for mobile engineers.
- Whenever I had spare bandwidth, I'd immediately try to refactor/delete something based on how much I had to spare. This led to me understanding the codebase more broadly and allowed me to play around with figuring out how I wanted my code to look.
- I spent a lot of time iterating on the code I wrote so I was exposed to pain points that my past decision introduced. Over time as I got more exposure to these points, I also began to code around them or be more deliberate for the tradeoffs I wanted. Since I circled back to bad code I wrote less, I was able to move and ship faster.
- This naturally built up to me reviewing a lot more code (since so much code had my fingerprints on them): I'd say this yearly number I do is 3x-4x the average.
- I pretty much said "yes" to every opportunity (that I felt like I could reasonably do given my bandwidth), but often times I didn't have much choice (one time, I ended up TLing 3 projects concurrently + writing nearly all of the Android code for all 3 projects). I felt like the exposure I got was much broader here compared to "normal work": both in terms of variety of responsiblities and intensity of work.

I'd boil down my experience to 2 themes:

- If your volume of work is signficantly more than your peers, you will get more opportunities. Since in the end, teams are judged on impact every year and giving work to the fastest, most consistent engineers means more impact to be had.
- Mentality is a big factor as well: what you think you own impacts what you're actually owning. I've been fortunate enough to be at the company for a while, so I have enough domain knowledge and trust where people are more willing to let me do whatever. Example: I just spent 2-3 months deleting an entire feature from the Android codebase the company shut down a while ago. I never worked on the feature before, it was causing complications to occassionally support it, and no one planned to delete it.

Hope this helps!

How companies perceive failure reflects how the experiences end up shaping your career. I'd say &gt;90% of folks who go this route end up failing. And this becomes very clear when you talk to them:

- They are unable to clearly express how they see the world and how their failures shaped their world.
- A constant resume of flip flopping between random ideas makes it clear they're just purely treating it as a game of chance.

3-4 years after graduation is likely the edge of being able to go back to an entry-level role: after that, companies will push towards mid-level+ roles (where your experiences will be scrutinized more thoroughly).

If you feel like you absolutely want to explore before working full time, go for it.

I think a lot of early career engineers are seeing peers jumping into entrepreneurship and making a big and flashy impression (likely through LinkedIn). These impressions are surface level and I highly doubt these peers are going to be honest about their current situation. This is to hold up an illusion of success when reality is likely much more stark and harsh. No one's going to be jealous of someone living of discount ramen from Walmart, so why post it?

Honestly for junior engineers, there are 2 general truths.

- **They can't do anything meaningful.** Internships, clubs, etc. build experience, but that experience isn't deep since the durations of those efforts are short and shallow. To build something, you must understand something deeply. If you have not understand something deeply, how will you be able to build a solution for it that people need? And if you need the company to make money, that just increases the activation energy for success 100x.
- **They don't know how to work with people**. Similar to experience + expertise above, it takes a long time (more than however many months spent on a club or internship) to have a relationship with people. At some point, you need to interact with people: a potential cofounder, a potential customer, a VC. If you (in your current state) try to reach out to the people that will move your company forward (even with the best idea in the world on hand), nearly all of them will ignore you. And you will have no idea why.

I'd recommend that you should just work both a standard tech job and doing your entreprenurial work on the side. Your day job will set up foundations of people you can interact with and potential build deep relationships in, give you a baseline of code to write and some structure for you to improve, and work experience to make your background look stronger. You can pull in your learnings about software into your soon-to-be startup & you have a pool of coworkers that could be a potential customer/cofounder or potentially route you to someone who can help you.

There's also nothing stopping you just finding a job that better aligns with your goals (joining a smaller company) or just shifting your behaviors at work to better align with your goals. My very hot take here is that the folks (working a decently sized company) who are complaining about their work not aliging with their goals just have skill issues & don't want to admit it.

Can you try fixing 1 test? Set a hardstop 1-2 weeks in the future, annoy whatever people can help fix it, and then document what you tried? This will compliment what Rahul is suggesting: what you're looking to define is yield (value/effort). If the yield is low (value is very low or effort is too high), that will explain why no one fixes the tests. In that case, I'd just delete them and measure if that decreases build times.

1. Yes
2. If you ditch a smaller company, you might run the risk for getting blacklisted from that company's network. Other than that, just leave the 1-2 month stint off your resume and it'll be fine.

There's not enough depth in a junior engineer's experience to be able to have a thorough behavioral interview.

Honestly most of my improvement outside of coding skills has been repeated pratice in a broader group. For system design, I started with:

- Asking questions on other people's docs on how does X work or why did we pick Y
- Then I started asking could we do Z instead once I felt like I got the hang of things. Example: whenever service A needs to talk to service B, I usually ask could Kafka work for this.

I also try to design systems to be simple. My prioritiy is breaking down the system into a hierarchy of smaller pieces (needs to be small enough to describe in 1 phrase or 1 word). Ideally I'm going for a structure like somewhat balanced tree or a list. Then I focus on the implementation of each piece.

Did you register it as a non-profit or a Delaware LLC? If not, it's a side project.

After watching each section of the course, can you try boiling down the course into 1-5 action items or frameworks for thinking? A 10h course is a bit too mentally intensive to memorize everything for.

Yes: you can specialize in domains specific to your company (knowing how x product works for your company). As an early career engineer, I'd just focus on finding something you're comfortably able to do good work in first. You'll have a feel for depth and your interests once you've hit a good comfort level. Then you can start thinking about how you want to specialize, using that understanding of yourself and your skills as a guide.

Start with a programming language you're most comfortable with and can consistently write code in.

- Context switching takes away some focus. The more junior you are, the more expensive that focus cost is (since you don't have the mental framework to refocus yet). You are still learning, so there's an additional cost to make sure that learning is reinforced.
- Business logic (which is nearly always written in some programming language) is generally what glues all the pieces of a system together. So it's a great jumping point to see how every connects.

Look at a mix of:

- Time to land (low = good)
- Lines of code/diff (low = good)
- Average words in diff summary + test plan (high = good)
- Comments/diff (low = good)

I'm going to take a shot in the dark: your diffs are likely too big. As a result:

- It's making it harder for others to properly review
- It's harder to have an exhaustive test plan for every diff you put up

Break up your changes into smaller diffs (ideally at most 100 lines of non-test code changed) and try to split out codegen + boilerplate code changes into isolated diffs.

In terms of how this will impact perf, I'd say this pushes you down to Meets Most (MM). E3/E4 perf is usually focused on coding fundamentals (speed + quality)

I might be off though since I don't have the full context. Maybe [this course](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/) can help?

Promos are lagging, so you need to generally perform at slightly above average for your next level for 9 -12 months. This is so that perf can confirm that this level is your operating baseline & your performance is not due to 1-off circumstances.

Usually when I downlevel someone in a coding interview, there's a clear foundations gap between:

- The candidate being able to concisely talk about code at both a high and low level
- The code the candidate typed out

I'd look to see if your recruiter can give you more details on what reads they got.

Are you looking to measure this for a personal project that you're doing on the side or within the bounds of a larger company that you're currently employed at?

I've gone through similar struggles: it took a while for me to find what works for me. Given:

- At E5, your interactions with people are the core part of your work
- Getting pinged is generally the main way focus is shifted away/lost (from my experience)

I'll focus on tackling the people aspects of your situation. Here's the framework I had that worked for me:

1. **Accept that people will always ping you & derail your focus.** It's going to happen and the occurences are going to be unpredictable.
2. **Find out the timing for responding to them that works for you.** Having a dedicated block on your calendar for responding to these pings is one way. For me, I have a short attention span so I try to respond to pings the moment I'm pinged (if I can't then I give the person a rough ETA).
3. **See if there's any themes on people pinging you.** If you're noticing that people are pinging you for the same thing(s), it might be worth having a centralized communication medium for people to ask questions or see past updates. Dedicated project channels for project updates and a channel for general Q&A questions are the most common channels I've spun up. Once those mediums are pushed up, push folks to go through those mediums instead.

Once you feel like you've lowered the time distractions from other people going to you, take a step back and see what's the next thing giving you trouble (whether it's still people pinging you, on-call, better foundations around perf). Take things one step/one problem at a time.

You don't need to go through this discovery alone either: I'd talk to your manager about your stresses and work with them to help figure out a clear path forward. Keep in mind though at E5 it's when people expect you to tell them what to possibly do, so you'll need to lead the convo by:

- Stating your stress in a clean, straightforward problem statement
- Provide one or two potential ways to move forward with this stress

Else your manager might interpret your struggles as you being overleveled & underperforming.

I'll assume the following happened:

- They agreed in writing & still walked back despite the written agreement

The questions I would have are:

- Why are they pushing back?
- What's lost if the project is pushed back?

Maybe the service is unable to effectively be shared across teams because it's in a legacy state? Sinking in more time might not be the most effective short-term use of time, but refactoring it so that it's much easier to work with later could help out. And it seems like this legacy system isn't low impact: high risk and low impact are descibing opposite things to me (high risk = high impact).

I've written over hundreds of thousands lines of code in seconds by code genning json migration files and lint baseline xml files. Does that count as writing code? I'd imagine Google's AI coders are doing something similar with the "code" they touch.

I think you made the same mistake that a lot of folks make in college of assuming that doing well in school matters. It doesn't: a lot of your classmates are either coasting with borderline grades or cheating to save time.

What does impact your ability to get a top tech job is your ability to ship code. There are 3 factors companies look at:

1. Can you write code independently?
2. Are you able to talk about your code effectively?
3. Are you able to ship code with real user impact?

Often times the candidates who are struggling miss out on at least 2 out 3 of these categories, get frustrated that they're struggling, and deathloop back into whatever behaviors got them stuck in their first place. The priorities of tech are much more aligned with providing practical value in the real world (especially when software is so easy to deploy out). While in school there's a clear rubric and path on a good outcome, this does not exist in tech. Treating succeeding in tech like academics will incur harsh (but fair) outcomes: slow career growth at best, unemployment at average and at worst.

If you want break out of the loop, you need to write code. You need to get into a focus loop where you are constantly writing code, learning as you're writing code, and using those learnings to write better code faster. Side projects are a great place to start ([here's a Taro playlist on it](https://www.jointaro.com/playlist/vKUWMgmmaEvzcYUXZs4B/)).

For picking your first company, **beggars can't be choosers**. Pick whatever position you can get that's reasonable (factoring in pay, location, hours worked, modernity of tech stack, culture) and work your way up. Unless your bachelors is for comp sci from either Waterloo or Stanford, assume that your options are limited. Big tech will always be around, but the time spent on zero outcomes will never come back.

Feel free to put some time on my calendar if you want to chat more (message me on Slack): I've gone through a lot of struggles after graduating & I currently work a FAANG-adjancent.

It's common to push back dates so you have more time to prepare (and won't reflect poorly on your packet), but there is a risk of the roles running out of headcount.

- It doesn't matter who refers you: what matters is how strongly they can vouch for you
- If you are rejected at the resume screening stage, you can keep applying. The cooldown only comes if you interview with another human and they made a concious choice to reject you.

Instead of imagining it as we need to do X doc for Y path, let's think about a RFC as a scenario working toward resolution.

1. You have a proposal that will impact the code surfaces of multiple people.
2. You want to make sure that the people impacted are aware of the changes and are comfortable having them made.
3. You write a document to explain the problem that is leading to the changes needing to be made, the changes being made, and the path of progression for making said changes.
4. You tag the people impacted on your doc and have them read it. Try to be exact with the tagging people on the exact changes that only impact them.
5. Go back and forth until they explicitly sign off (likely on a table on the doc).
6. Proceed with making the changes.

Lead with principles identifying the core problem first & work towards the outcome for the problem. Don't think about the exact terminology unless it makes communication with the people around you easier.

Your first step is to validate if your approach is acceptable with the miminum amount of effort possible. If edge cases won't change the core design, don't include them & focus on getting your senior engineers to approve the approach.

My general guidelines are:

- Lead with high level summaries & try to use as concise wording as possible
- Prioritize topics that the audience is most interest in

Since there's a lot of high-level employees in the meeting, you should ensure their time is used as effectively as possible. Their time is worth more, so optimizing for their time should be the priority.

You're taking initiative (which is a good signal of growth), but you seem to be unclear on how to proceed.

If you think of everything at once as one goal, excution becomes harder: instead of a path forward, things seems more like a maze. Mazes are disorienting because it's unclear if your movement is bringing you closer or further away. The more you're imagining doing, the larger the maze. The larger the maze, the harder it is to get out. Fortunately for us, we're able to construct our own path and just simply not construct a maze.

I'd start with: what's the least amount of effort you can do to move the project forward?

- Is there a simple solution you can start out with that you can iterate on?
- What is the bare minimum needed to product an artifact for your senior engineer to review (you can probably ask them)?

Identify these small steps forward and then take them one at a time. You can leverage your senior engineer peers to make sure you're moving in the right direction. Small steps are easy to walk back from: running 50 miles, not so much.

(Misc note: in the future, it'll really help the small pool of question answerers if you could organize your thoughrs and use simpler wording. Try doing a few proofreading passes to clean things up & run your question through ChatGPT to clean it up).

wow if they're charging 2.8k for 5 lessons maybe you should pay me for the coaching instead for cheaper?

Feel free to connect to me. Do you mind telling me which LinkedIn post of mine was inspiring and how it was inspiring?

The only magical portal is to network IRL and be skilled and confident enough to convince people you're worth hiring.

It's too early to say. If you do your work well over time, your path forward will become clear. Experience is what truly will give you an answer, and it must be built up over time.

A tech lead is just a possible career path as an engineer, but not a title in itself. A tech lead's main impact is supporting the team around them (the more senior they are the larger the team they support). Not all engineers need to grow to become a tech lead of a team as opportunities are pretty spread out across a company.

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

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

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

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

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

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

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

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

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

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

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

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

I would put it like this:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

My general baseline is keep things simple:

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

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

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

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

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

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

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

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

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

Hope this helps!

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

Try doing the following:

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

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

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

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

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

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

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

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

Here's my thoughts:

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

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

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

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

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

This is pretty common feedback for the following 2 buckets:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hi OP: can you share an anonymized resume?

Raises are only based on:

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