> Do you recommend building my own projects using that technology (although this approach might be slower) or just jump straight into the company codebase and figure things out as I go (even though I do not know that technology)?

You can do both! (I am assuming that you aren't married with kids or something as a new grad and you have free time after work)

At both Course Hero and Facebook, I would go home and build side projects to deepen my Android understanding and increase my overall coding efficiency.

Just try stuff. Run into walls, get hurt, learn to never run into those particular walls ever again, run somewhere else, hit some other walls, repeat. I don't believe in super tactical courses that "teach you how to code". As Sai, just do 1-2 basic ones max (or even 0 if you're comfortable being uncomfortable).

Also, just because a startup moves fast doesn't mean that it can't have a culture of helping others and providing support (quite the opposite in fact). At a good startup, everyone should be aggressively available to help you out and walk you through stuff. You just need to take the initiative to [ask for the help](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/) as the startup engineer's default mode is to be heads down and super busy, oblivious to their surroundings.

Tech Lead @ Robinhood, Meta, Course Hero

Alex Chiou

> Do you think these job cuts at Meta (every year) are here to stay?

Yes, because this has always happened. Even when Rahul and I were working at Meta, the company aimed to cut the bottom 5 to 10% every year. They just weren't as public about it, and the bar is higher now.

Meta was never a "chill" company - It has always weeded out low performers very aggressively. I had several peers join and then mysteriously disappear \~6 months later once performance review results dropped. For the most part, this is how Big Tech operates, and it's done so for decades.

> Also, any tips on battling imposter syndrome, especially when coming from a non-FAANG company?

It's much easier said than done, but the most powerful and efficient way to correct a bad mindset is to bias towards action. Your goal is to make yourself so busy [doing great work](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/) and [building deep relationships](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/) that you don't even have the time to stew in your own negative thoughts. Once the praise starts coming in, the negative thoughts will melt away.

More thoughts here:

- ["I've felt imposter syndrome from seeing super talented peers - How do I deal with this?"](https://www.jointaro.com/question/MPUkGXFDaBixmxfjOg9i/ive-felt-imposter-syndrome-from-seeing-super-talented-peers-how-do-i-deal-with-this/)
- [Imposter Syndrome (Building Confidence)](https://www.jointaro.com/course/15-years-of-software-engineer-knowledge-in-1-hour-30-minutes/imposter-syndrome-building-confidence/)

I recommend this as well: ["Advice for someone joining big tech from a non big tech background?"](https://www.jointaro.com/question/CJWMEjoueAaVksw5H3nO/advice-for-someone-joining-big-tech-from-a-non-big-tech-background/?revalidate=true)

Here's my thoughts on your specific questions:

> How do you prioritize and balance retroactive documentation with the need to keep up with new development within a Scrum framework?

I think just don't do it honestly.

But if you absolutely need to do it, your balance will come from working backwards from deadlines. So if the deadline is 2 weeks (10 business days) out and you can finish the project in 9 days, you have 1 day to work on the documentation. With that time constraint, you can figure out the level of thoroughness and quality you can achieve.

> What strategies or modifications to the standard Scrum process have you found effective for embedding documentation tasks into sprints without hindering delivery?

With stuff like this, you need to weave it into the culture. If you get a project that takes 1 month for just the raw execution and the deadline is 1 month, then you have 0 time for extra stuff like documentation. Engineers just have to burn themselves out to write the documentation, which isn't sustainable.

If documentation is a first-class citizen at your company, you need to work with whoever is making the deadlines (i.e. leadership) so they know they have to add 10-25% buffer to every project for the documentation to be done. In other words, delivery always needs to be pushed back for this work, because it is considered part of the core work.

> Are there specific tools, processes, or best practices you recommend for tracking documentation progress and managing technical debt in this context?

If you're a JIRA shop, Atlassian has Confluence. I haven't used Confluence in a long time, so I don't know what features it has, but it seems like you're creating tasks for documentation anyways. You can use JIRA to see what documentation tasks are open, which are on the backlog, which are blocked, etc.

Okay, I have a lot of thoughts here, so I'll split things up.

### Writing The Documentation

[The key to communication is empathy](https://www.jointaro.com/course/effective-communication-for-engineers/effective-communication-guide-part-1-core-high-level-principles/), and documentation is a written form of communication. Your goal at a high-level with documentation is this:

> This content will be so simple even the clueless intern who just joined the team can understand it.

In terms of how this manifests, it will depend on what you're writing about and the writing culture of the team. But here's some high-level pointers:

1. Include as many visuals as possible like diagrams (a picture is worth 1000 words!)
2. Don't rely too much on acronyms, just spell them out
3. Use basic words and analogies where you can

You can probably use AI to help with a lot of this, even generating the diagrams. ChatGPT integrated image generation natively fairly recently.

Here's a good thread about doing better writing: ["How does Alex write so well?"](https://www.jointaro.com/question/tE1rI7jIaWw34xOQIHz3/how-does-alex-write-so-well/)

### The Value Of Documentation

So here's my meta-point: I don't really believe in documentation that explains how code works. I have many reasons for this:

1. **It conflicts with development** - It is impossible to move fast and evolve the codebase quickly while simultaneously documenting it extensively. What you'll find is that writing the initial doc isn't so bad, it's *maintaining* the docs that completely destroys you - It just takes way too much time and cognitive load. This is why Meta had almost 0 documentation about how its codebase worked. If you need to learn a codebase or how some component works, just go talk to someone. It'll be more efficient, and you'll build up relationships with your peers through these interactions. That social capital will allow you to move even faster in the future.
2. **Code should be self-documenting** - At the base level, [code should sort of explain itself if it's well-written](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/). On top of that, code and systems should have natural artifacts that are generated as byproducts from working on them like pull request context sections, test plans, system design documents, well-written tasks, and even git commit/blame history.

Instead of making an explicit effort to create standalone documentation, it's way faster and smoother to create it organically along the way through existing avenues. I break this down more here: ["Tips for someone with poor working memory?"](https://www.jointaro.com/question/55fEwxKMxTLMyiurKdBH/tips-for-someone-with-poor-working-memory/)

There isn't really a catch for you as the candidate unless the staffing agency is a scam. How those firms work is they make you think you are interviewing for a job, but it's a fake job where you need to pay the company for "training" before you get the actual job. So avoid those obviously.

If the firm is connecting you with real companies though and you are interviewing with people from those companies, you're good to go. As you mentioned, these agencies can be useful with providing you training fodder opportunities at less prestigious companies where you effectively just use them as interview practice.

> I also feel that I need some basic guidance on how to effectively ask for a referral.

I recommend this section from the question asking course: <https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/put-them-on-a-pedestal/>

The baseline is to just be incredibly polite, ideally with some degree of flattery.

If you can add substantial value in return, obviously do that, but don't treat it as a requirement. If you feel like your connection has some amount of warmth to it, I would give it a shot, especially if you are struggling to get interview opportunities.

Congrats on getting the job! Startups are crazy, but you'll learn a lot and have a ton of fun if you have the right mindset. It seems scary, but I think what the hiring manager told you is good. They are simply being honest with you and setting expectations. I would say the same thing to a Taro new hire.

In terms of having the right mindset, I recommend starting with this: [How do you learn "on the job"?](https://www.jointaro.com/question/kv2KAIr16TuvRKPs7sY2/how-do-you-learn-on-the-job/)

From there, go through the onboarding course: [The Complete Onboarding Guide For Software Engineers](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/)

Finally, take the junior engineer growth learning path: [Nail Your Promotion: Junior To Mid-Level (L3 -&gt; L4)](https://www.jointaro.com/learning-paths/nail-your-promotion-junior-to-mid-level-l3-to-l4/)

Good luck!

> I go to work to do some useful work for the company but not build relationships with managers or others. Meaningful connections can be byproducts but they are not the key goals in my opinion.

It's true that having good relationships doesn't magically produce impact on its own, but it's so, so deeply connected that you should definitely view this as a key goal of your work.

Even ignoring the tactical aspect (good relationship = easier to convince people to do stuff for you), relationships are valuable for future jobs as those people can refer you and connect you to other opportunities in general (e.g. they founded a rocketship startup and want you to join).

So of course your relationship with your manager is useful. But let's say that fails, and the manager sucks. It's critical that you have good relationships with all your other peers, because if you do, they can *protect* you from the bad manager. The most common scenario here is that the manager thinks you're doing low-quality work or not enough work, but your peers can vouch for you, proving that your manager is wrong and that you are indeed delivering.

I need to convert this into a course, but in the meantime, we have this: [\[Masterclass\] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)

> I wonder why he has chosen this gaslighting behavior over me and what might have done to prevent such situations in the future.

From "good girl complex", I assume you're a woman and he's a man. It can honestly just be that. Sexism is still rampant in tech, and given how the US is going, this will probably get worse.

Not liking your "tone" is a classic sexist attack as women's ambition and confidence are often interpreted as them being "entitled" or "bossy" by men. I've seen this happen way too many times unfortunately.

> Can anyone suggest how I should move on and how to grow from this scenario?

It's grim, but take it as a learning of the harsh reality of the industry. Even though your manager was clearly in the wrong, there are rarely situations where you functioned 100% optimally and did nothing wrong. Always try to introspect and see what you could have done to improve the situation - You'll generally find at least 1-2 small things. Here's a good course about managing up: [Managing Up: Build Effective Relationships With Your Boss](https://www.jointaro.com/course/managing-up-build-effective-relationships-with-your-boss/)

Sorry to hear about this - I imagine most of the industry, especially now, is working with bad managers. With toxic managers, the right solution 99% of the time is:

1. Mitigate the pain (while step #2 is happening)
2. Leave and find a better manager

### Mitigate The Pain

This is a mix of working with what little goodwill they have and surrounding yourself with allies. We break this down in detail here: ["My manager and I don't see eye-to-eye. How can I improve this relationship?"](https://www.jointaro.com/question/WWuU0HRpNu90J638iJPs/my-manager-and-i-dont-see-eye-to-eye-how-can-i-improve-this-relationship/)

An extreme option is to create a "secret manager" who effectively acts as your real manager without the title. Your actual manager is the reverse, having the title but not the influence over you. I talk about that here: ["How can I navigate a toxic work culture with a low EQ engineering manager while maintaining my motivation and professional integrity?"](https://www.jointaro.com/question/GlBwA7k9dyknoJ5GOz89/how-can-i-navigate-a-toxic-work-culture-with-a-low-eq-engineering-manager-while-maintaining-my-motivation-and-professional-integrity/?a=POhP9KuCHs8El1FUcLks%20%20%20%20//%20to%20guarantee%20unique%20URLs)

### Leave

First, you obviously never want a toxic manager to know that you're thinking of leaving, so coordinate the move in secret. Do the bare minimum to meet expectations at your job with 10% buffer, and use the remaining time for interview prep. Check out our job switching learning path here: [Land Your Dream Job In Tech](https://www.jointaro.com/learning-paths/land-your-dream-job-in-tech/)

Of course, you want to make sure your next manager isn't toxic as well. I recommend this: [\[Masterclass\] What Software Engineers Should Look For In Their Engineering Manager](https://www.jointaro.com/lesson/oeY7ncZhzJ5NO6dij5e7/masterclass-what-software-engineers-should-look-for-in-their-engineering-manager/)

Something for you to figure out is if the issue is your coding ability or your confidence and handling of anxiety. I have a feeling it's the latter.

If your code is generally well-received in code review, your technical skills are probably fine. If your pull requests are getting torn apart instead, then I have just the course for you: [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

When it comes to interview anxiety, it's a tough problem to solve because it largely requires a mindset shift, which takes time. What I can do though is teach you what that correct mindset should be, so you can start adjusting your thinking accordingly - Check out the lesson here from our overall job searching course: [Having The Right Mentality](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/having-the-right-mentality/)

If you have time, I recommend just going through the entire course: [Ace Your Tech Interview And Get A Job As A Software Engineer](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)

> Will the interview notes/feedback from behavioral round (first round) be available to all subsequent interviewers?

At Meta, every interviewer at least shares the questions they asked with all the subsequent interviewers, but they usually don't share detailed notes. However, it's still possible, especially for more senior candidates.

> and will they cross question me about it in the following rounds?

Probably not, but it's possible.

> Eg - for driving efficiency if I say I improved the bottlenecks in an ETL pipeline, will the interviewers in the next round deepdive into this? Or If I say I trained a LSTM variant, will they grill me in the analytics round about it?

Anything you say in an interview opens you up to getting grilled about it, especially at FAANG. With subsequent rounds, it's unlikely as asking new questions generates more signal, but the current round obviously will.

Okay, "generating" is a bit of a vague term, so just in case, I'm going to say that *you should **never** create completely false stories for behavioral interviews.* There's so many ways this can come back to bite you:

- **Instant rejection** - Interviewers, especially at FAANG, are perceptive as that's literally their job. The behavioral round (codenamed "Jedi" for a reason) is usually given by a very senior engineer (Staff+) or an engineering manager. These are people with excellent social intuition.
- **Blacklisting** - If a candidate is blatantly making stuff up, they can be barred from interviewing at the company ever again.
- **Incorrect leveling and PIP** - Let's say you trick the behavioral round and convince the interviewer that you're more senior than you actually are with grand stories full of great experience, getting an IC5 or IC6 offer. Once you start at the company, you will actually need to function at that level. Given the atmosphere of Meta nowadays (look at the 5% "low performer" cut), it's very unlikely you'll make it past your first performance review.

If by "generating" you meant taking an existing story and embellishing it a little, that's totally fine. Behavioral interviews are all about making yourself look good. But ***do not*** fabricate entire stories/answers from scratch.

I highly recommend going through our entire behavioral interview course: [Master The Behavioral Interview As A Software Engineer](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/)

These 2 lessons are particularly relevant:

- <https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/its-a-conversation/>
- <https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/when-you-dont-have-an-answer/>

> I only recently started my job - when would be a good time to do so?

Good question! It's true that you don't want to "rock the boat" after joining. This is because you haven't earned any trust yet as a newbie. If you are doing a good job, you should be able to ask for more general responsibility after \~3 months. Follow the advice from the onboarding course to do so: [The Complete Onboarding Guide For Software Engineers](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/)

Some companies even have a midpoint performance review check-in every 3 months (that's how Meta worked for me). This makes it really easy to tell if you have properly situated within the team and earned their respect. If you're getting great feedback, this means that it's safe (and expected) for you to expand your role within the team.

If you like talking to customers, you should make friends with your UXR lead (user research), product manager, and designers as they are closest to the customer. These resources can be helpful too: [\[Taro Top 10\] Product Management For Engineers](https://www.jointaro.com/playlist/2GNJo0RWsT4GK6VXyWIy/)

Even for ad-hoc situations, someone should still be a scribe. If it doesn't fit into an existing doc or merit a new one, at least post the summary + action items to Slack or something.

For higher impact things, it might be worth task-ifying them into whatever project management system you use and leverage the reminders (e.g. *"This task is due in 2 days, please do it"*).

Yeah, system design is pretty awkward when it's fully virtual. People are using online whiteboards now. For Robinhood, I think I used Google Jamboard but I learned just now that it was killed in late 2024 (classic Google). Here's another one I've seen used: <https://miro.com/whiteboard/>

I recommend this system design course as well, especially as it shows concrete virtual whiteboarding examples: [The Top Ways People Fail System Design Interviews](https://www.jointaro.com/course/the-top-ways-people-fail-system-design-interviews/)

Monetization/ads will have the *worst* work-life balance out of any org in the entire company. In terms of how much better infra is, I don't know, but it can't be worse than monetization/ads (WLB is just terrible across the entire company right now).

The weird thing is that I don't know how Meta classifies infra for new people. Infra isn't an org, it's more of a function that can exist in any org. I worked in ads. We had *ads infra* teams - I literally worked with them. Ads and infra aren't mutually exclusive.

Here's a good thread about product vs. infra overall: ["Between platform (serving developers) and product teams (serving end customers), what should be one's preference based on level?"](https://www.jointaro.com/question/zyEImoKWObsSm8YymzvT/between-platform-serving-developers-and-product-teams-serving-end-customers-what-should-be-ones-preference-based-on-level/)

> Also, how should one define impact after joining a team?

Meta is very metrics-oriented. Figure out the KPIs/OKRs and work backwards from there. As an E4, you are expected to become familiar with the experimentation frameworks there relatively quickly: ["I got feedback about experimenting, and I'm unsure how to process it."](https://www.jointaro.com/question/mP0YGnGPZISrxSTDLeuv/i-got-feedback-about-experimenting-and-im-unsure-how-to-process-it/)

Here's what I recommend to prepare yourself for the Meta role and succeed there:

- [The Complete Onboarding Guide For Software Engineers](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/)
- [Nail Your Promotion: Junior To Mid-Level (L3 -&gt; L4)](https://www.jointaro.com/learning-paths/nail-your-promotion-junior-to-mid-level-l3-to-l4/)

> I actually setup a perplexity space for Taro, so basically it only looks at [**jointaro.com**](http://jointaro.com) links which is pretty cool

Dang, please share this if possible. This is legit.

At a surface level, getting an E4 offer with 12 YOE sucks. However, it's hard to tell what to do here without knowing where you currently are.

What I will say is that Meta compensation is very, very high within the industry. Even among FAANG, it tends to pay the highest in the aggregate. With proper negotiation, you can get an E4 offer to around $400k TC (assuming you live in the US). In comparison to one of my prior companies, I know many Staff Engineers at PayPal who are very far from making $400k/year, being closer to $250k.

If there's a major compensation boost, you don't like your current job too much, and you've never worked for a FAANG company before, a strong Meta E4 offer has a good chance of being worth it.

All that being said, the first step here is to follow the advice from the negotiation course to bump up the offer as much as possible, maybe even return it to E5: [The Insider's Guide To Negotiating Your Tech Salary And Compensation](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/)

Even in this economy, I'm happy to say that many people in Taro have [gone from E4 -&gt; E5 in a year](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/how-this-course-works/) (they've thanked me for it!). You would be better positioned than most.

It's pretty rare for an engineer to be genuinely excited about the product they are working on. I literally worked on ads at Instagram. Do you think I'm super passionate about making people buy crap they don't actually need on social media? Hell no. But I loved the work, and here's why:

- **Great peers** - Instagram ads was full of rock stars who were also very helpful and kind. I often felt like the dumbest person in the room. This was very invigorating, motivating me to catch up and get better. Once I got better, I started taking on mentees to reshare that energy (now they're the dumbest person in the room and need to get better 🤣).
- **Hard technical challenges** - Instagram ads are viewed by over a billion people every month. It is a +$25 billion per year business. At that scale, even the smallest change can [require 5+ pages of detailed system design planning](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/). I love striving for perfection and getting every tiny detail correct. This was fun.
- **Diverse skill building** - When you're as big as FAANG, you will have a bunch of challenges besides the technical part. At Instagram, I was forced to get way, way better at more [fundamental skills](https://www.jointaro.com/question/3VNPK7wol76s89EkgFeW/what-are-software-engineering-fundamentals/) like communication, leadership, project management, product direction, mentorship, and more. Over time, I could feel Instagram making me a more complete engineer and even a more complete person with a broader skillset and worldview.

So to answer your question, that's how you find SWE work that is genuinely fulfilling - Look for teams that can provide you these. Affinity for the product specifically is a nice-to-have, but many people think it's absolutely necessary and the only way to unlock true passion for your work. That's completely untrue.

*Honesty is the best policy.* Yes, results are important for a manager, but they're equally (maybe even more) concerned about predictability. If you know well ahead of time that something is struggling, you can react to it, either by adding more resources or creating a backup plan. Because of this, having a miss but knowing about it beforehand is easily 5x better than having a miss that comes entirely out of nowhere.

I think you have laid out your communication strategy pretty well. Communicate the following:

- The error you found and why it's creating a major delay
- Your best estimate on the delay length
- All the approaches you can think of to mitigate the issue and derisk the deadline
- What you think your chances of hitting/missing the deadline are

There is almost never anything to gain from restricting information, especially as an earlier-in-career engineer who needs a lot of support. On the other hand, restricting information often has lots to lose. [In general, it's always best to overcommunicate](https://www.jointaro.com/course/effective-communication-for-engineers/effective-communication-guide-part-1-core-high-level-principles/).

Your list is good, but I would split it up like this:

### Table Stakes

- Coding velocity (code output)
- Coding quality
- Independence (can unblock oneself without too much reliance on mentor)
- Debugging
- Asking great questions
- Responds well to feedback

These are the ones where you need to have very solid proficiency just to survive.

### Nice-To-Have

- Builds great relationships with team members
- Disambiguation

You need to have made *some* progress on these as an E3, but you can be very rough around the edges with these 2 and still survive as an E3. For these behaviors, it's more about you planting the seeds. The seeds will mature once you start meaningfully progressing to E4 (mid-level) and will bloom even further as you grow from E4 -&gt; E5 (senior).

In the beginning, just focus on the table stakes as that will take a lot of time, especially since you're an intern. Most engineers will take the entire internship just to nail the first 3 (code velocity, code quality, independence).

If you're interested on the progression from junior to mid-level, you can check out the course: [Grow From Junior To Mid-Level Engineer: L3 To L4](https://www.jointaro.com/course/grow-from-junior-to-mid-level-engineer-l3-to-l4/)

The midpoint review is just a check-in and either an encouragement/validation mechanism (if you're doing well) or a course mechanism mechanism (if you're doing well). It's very passive for you as the intern - You mostly just go in and listen. *There is no self-review for you to write or formal score for you to maximize here. It's really just feedback.*

The self review comes for the final review, but it's not that important for interns as they're closely looked after, primarily through their intern manager. This is in contrast to full-time engineers who are doing far more across a longer time span, especially more senior engineers (E5+). For these engineers, the self-review is necessary to get the full picture of what they did. This isn't the case for interns - Their destiny is computed from the intern manager review alongside the 1-3 peers. My Instagram intern had an extremely bad self-review (it pretty much violated all the advice in Taro 🤣), but he still got an "Exceeds Expectations" return offer.

The main thing you need to do is aggressively probe for feedback and [do a good job sharing status updates on your projects](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/sell-yourself-claim-your-wins/), particularly in 1 on 1 meetings with your manager. [Well-written diffs](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/one-diff-one-thesis/) helps with self-documenting your journey as well. It's on my backlog to create a course dedicated to giving and receiving feedback, but in the meantime, check this out: [This Is How You Get Feedback - Making The Process Smooth](https://www.jointaro.com/lesson/aGuxjGbFjYb34ofhRxjs/this-is-how-you-get-feedback-making-the-process-smooth/?playlistId=llknt3sHtV4xmhDThKOx)

Sorry to hear about the re-org: This is going to happen all the time at Meta and pretty much every other FAANG company.

Ideally, you shouldn't have to learn this as a fresh E4, but Meta, especially now, is a "sink or swim" environment. If you don't have any major impact shipped come PSC time, it doesn't matter how many excuses (even valid ones) you have. *You absolutely need to find scope.* There's 2 main ways to do this:

### Ask Your Manager

You always try this first, especially as a new E4. It's easy for managers to lose track of their reports, like not realizing an entire engineer has nothing to do. From my understanding, your manager is figuring this out alongside the rest of leadership, but that doesn't mean you should just sit back and wait. Keep pressuring your manager for meaningful work. Managers make and break promises all the time - The onus is on you to keep the thread alive.

### Create Your Own Scope

This is more something for E4s who are closer to E5, but the Meta bar is higher now, and there's no reason why you can't develop this behavior earlier. Follow the advice from here for starters: ["How do I come up with innovative, impactful ideas and bring them to my team?"](https://www.jointaro.com/question/3QIJhAT4loA7n1hSfCuw/how-do-i-come-up-with-innovative-impactful-ideas-and-bring-them-to-my-team/)

You also probably don't need to start from scratch here either. Most teams should have some semblance of a backlog, particularly with "Better Engineering" type tasks. Go through those. On top of that, talk to other engineers on your team to see if they have some backlogged tasks they can share with you.

You're in luck - I literally made a course on the Meta internship: [Nail Your Return Offer As A Meta Software Engineer Intern](https://www.jointaro.com/course/nail-your-return-offer-as-a-meta-software-engineer-intern/)

For interns, they are only really evaluated on 1 axis and that's "Engineering Excellence". This is more or less the case for full-time E3s as well.

I recommend going through this thread as well: ["Internship Metrics For Conversion?"](https://www.jointaro.com/question/mC56HuFZ7gpJvIhdx5B9/internship-metrics-for-conversion/)

Lastly, take this course (if you truly follow the advice from this course, you are 90% good to go): [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

Your tenure will be sort of "pro-rated", so you aren't just put on a PIP. However, this isn't that relevant for E3s anyways as they are held responsible for engineering excellence, not impact. I break this down in-depth here: <https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/impact/>

The main thing to succeed as an E3 is coding velocity + quality. Follow the advice from the code quality course and you should be okay: [Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

> by any chance, would it be possible to make the transcript available for each video?

I'll file a task, but this will be a more involved project as a heads up. Will take a while.

Treat it as a behavioral interview. The difference with a team match interview vs. a "regular" behavioral interview is that the balance shifts more towards you asking questions instead of you getting asked questions.

This means that you need to make sure that the questions you ask convey a lot of value about yourself, ideally E6 signals. Follow the advice from my behavioral interview course, particularly the "Questions To Ask" section: [Master The Behavioral Interview As A Software Engineer](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/)

Make sure to do a lot of research on each team and its domain. Weave the evidence of that homework into your questions.

On top of Rahul's great tactical advice, the main way for a mentee to attract a mentor from my experience (both as the mentee and the mentor) is to aggressively add value to others in a public way. I break down many ways to do that here: ["How does one attract a sponsor who is invested in their growth?"](https://www.jointaro.com/question/pRX7I8QC5YPOEDNX5q87/how-does-one-attract-a-sponsor-who-is-invested-in-their-growth/)

I don't think you should pay for mentorship as good mentorship is very expensive. Engineer time is *extremely* valuable - Even the junior engineer at FAANG in the US has an hourly compensation around $100/hour. Try to find a mentor organically within your company first, especially as they will be a more effective mentor than anybody you can find on the outside anyways.

So at Big Tech companies at Microsoft, there should be an equivalent EM level for each IC level, so you shouldn't "lose" any career progression by staying as an IC for a while. For example, Meta principal engineer \[E8\] maps to engineering director \[D1\]. I knew an Instagram E8 who was able to switch directly to D1 - They didn't have to waste time going through the manager ranks first.

> Morever I have received feedback to become an A player in current role before getting considered for EM path? How can I fastrack my transition to EM path?

There's several components here:

1. Establish yourself as a very high-performing IC and get to Staff (which I think is Principal at Microsoft since they skip Staff). Follow the advice from the senior -&gt; staff course here: [Grow From Senior To Staff Engineer: L5 To L6](https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/)
2. Show strong ability mentoring and growing other engineers. The most concrete way to measure your progress here is to see how fast you can get other engineers promoted. I need to make a course on this, but in the meantime, check this out: [\[Case Study\] Mentoring Junior SWEs \[E3\] to Senior \[E5\] In Just 2.5 Years At Meta](https://www.jointaro.com/lesson/EX9563YnxcJb62cCmetg/case-study-mentoring-junior-swes-e3-to-senior-e5-in-just-25-years-at-meta/)
3. Assuming you have a good relationship with your manager and a decent track record at Microsoft by now, start having those deep ([and maybe awkward](https://www.jointaro.com/lesson/xjeFRpp5YHxG9TTK8wjn/1-on-1s-are-the-time-to-be-awkward/)) conversations with your EM about your own desire to become an EM and how you two can forge a path together to make that happen.

Great question! First, I recommend going through this section in the [promotion course](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/) about judging technical complexity: <https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/technical-complexity/>

If you have more time, I recommend going through the entire "Project Credit And Scope" section of that course as well - Should be really helpful.

LinkedIn L3 with 1.5 years of experience alongside a track switch maps to later junior/early mid-level. From my experience mentoring many engineers at that level, you should take on a project that's:

1. Somewhat well-defined but still has a couple major ambiguity gaps
2. Takes 1-3 months to complete
3. Has 1-2 POCs (points of contact) who are an expert on that area

\#3 is very important, maybe even more important than the project complexity/impact itself, as you want to make sure you have a couple people who can "bail you out" if the project turns out to be overwhelming. At your level, I still think it's good to play it fairly safe. Once you get closer to senior (3+ years at LinkedIn), that's when you want to start taking on projects where there is nobody to save you and you need to become the expert/pioneer in that area.

> oh wait that helps. I didnt see that! I vaguely remember there used to be per video slide download but I could be wrong so I never bothered messing with it.

Unless Rahul or Charlie snuck something in without telling me, I don't think we've ever had this 😅

The "View Slides" feature used to be very poorly designed. It was in an overflow menu on the course viewer page. There were 3 small dots on the left and if you clicked it, you would see the button to get the slides. It was super hidden and unintuitive, so very few people realized it existed.

About a month ago, I came up with the redesign to create that big "View Slides" button that shows up underneath the course banner on the landing page, also moving the "Save Course" feature there as well to make it more visible.

I'm glad that the slides are helpful 😇

> I wish there was a "notes" or a "cheat sheet" to revisit. I could make my own notes but thats a chore. Is it possible to expose the transcripts? or maybe just genAI to generate an outline and then yall can refine it?

The course slides are effectively the notes/cheat sheet. Does that work? For every course with slides, you can click the "View Slides" button on the landing page for any course. Here's my DSA course as an example: <https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/>

If you're looking for something more thorough, a feature I've been thinking about is exposing the subtitles in a text reader pane somewhere on the course viewer page. Once you get that, you can theoretically build AI summaries on top of it.

> Would Letting Meta Know Of Another Offer Affect Their Hiring Decision?

Yes, it will make them want you *more*, especially if the other company is a competing Big Tech company.

Tech companies aren't charities. They're not going to reject a great candidate because they already have an offer and will be okay for the struggling candidate who only has Meta remaining as a potential opportunity. *Their goal isn't to maximize employment among the labor pool,* *it's to get the best possible people* (this is especially the case for Meta and FAANG overall).

By showing a competing offer, you are signaling to them that another smart group of tech people have blessed you with a mark of competence, which reduces the risk of you being a weak hire. You are statistically safer for Meta to hire as the engineers with competing offers are better overall like 99.9% of the time. I know a couple engineers who can get 5+ FAANG offers like it's nothing (even in this economy), and they're all genuinely brilliant.

If there's some tactical limitation like headcount not being available but they still *genuinely* want you (i.e. you got a "Strong Yes" on most, if not all, rounds), they will try to counter-negotiate by asking you to wait a little longer or something (or maybe even extend an offer outright with some very late join date just assuming things will be worked out by then). If they were erring on rejection, sharing the competing offer will almost certainly not change the outcome. You'll just potentially get rejected now instead of inevitably later.

Another thing I'll say is that Meta E3 hiring is *insanely* competitive, especially if you aren't a returning intern. I wouldn't hold out on Meta, especially if you need to make some sacrifices like rejecting an existing quality offer in hopes Meta pans out later on.

1. Tell them that you really appreciate the offer and the quality of the interview/recruiting experience
2. Reiterate your excitement for Meta overall as a company and the work they're doing
3. Ask them if it's okay for you to follow up with them in 3-6 months to see if anything has changed with the remote work situation

Good question! For Taro's particular use-case, it's an extension of our communal learning roots. Taro started off as a free community where Rahul and I would hop on a Zoom call (this was during pandemic times when people were stuck at home with nothing to do). That's a video-based medium, and when we organically spun that into a startup we quit our jobs for, video just made sense as that's what everyone in the community was used to.

You can learn more about the overall story behind Taro here: ["How did you decide to quit your job and make a startup?" - 9/13/2022](https://www.jointaro.com/lesson/beZzIkLUP28WinNQctlP/how-did-you-decide-to-quit-your-job-and-make-a-startup-9132022/)

On top of that, it's better to go with the market and what's established rather than against it as that usually involves training/convincing end-users to take on new behaviors, which is *extremely* hard. Coursera and Udemy are the biggest course players ever and they're video based. Even in our niche software engineer domain, websites like AlgoExpert and NeetCode are video based.

This "go with the flow" method is actually something we learned the hard way through many mistakes. For example, we did magic link login (similar to Slack) instead of password-based, which is pretty much by definition safer (it's also less work for the user as they don't need to create/remember a password). However, users are so used to the email/password model as it's been around for 25+ years, that many people are confused as to where to enter their password. There's a ton of value in making something familiar as it reduces cognitive load for the end-user by leveraging their existing mental model of the world.

> Reading is generally a far more effective+faster medium to learn from.

I would actually challenge this, even though this is the case for me (I rarely use videos to learn something).

When it comes to learning, the challenge for most people isn't rate of information consumption, *it's retention and motivation*. The human brain is irresponsible by default - It's much more fun and tempting to binge Netflix than to consume a complex educational resource that makes you a more effective human, even though the latter is objectively better for you in the long run.

Taro is also built for people [who already have a good job and are looking to level up](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/) (not just those interviewing), and for them, they are coming back to Taro after a long day of work and are tired, so they need the media they consume to be inherently more engaging.

This is where video comes in. Since video contains everything (text on screen, audio, and visuals), it's more engaging to the brain as it's stimulating far more senses. If the person behind the video is also someone you know/trust (as is the case for Taro as many folks in the community follow Rahul + personally), that adds another layer of stickiness and ease of deep engagement. This richness makes it far easier *to both finish the resource and actually remember the information long-term so you can actually apply it.*

It's true that with pure text, you can pragmatically consume all the raw information faster, but if I give the *average* engineer a 25-page wall-of-text essay with some graphics here and there vs. a well-made 2 hour video course, I'm very confident that they'll do better with the course. There's a reason why educational YouTube + course platforms are an order of magnitude bigger than stuff like Medium.

> keeping money aspect aside, do you think amazon better supports my entrepreneurial goals?

If you want to be a founder, it's better to work for a smaller company instead of a bigger one as the experience will transfer over better.

At FAANG, the work is largely ultra-incremental, especially for junior and mid-level engineers.

> Wonder what changed 🤔

Meta wants to save money and go to $1000/share.

Now I'll go through your questions 1 by 1.

> How much does FAANG experience actually matter for future career flexibility (especially if interested in entrepreneurship/product roles)?

A lot. Brand names are powerful. I think Amazon wins here as BitGo is a smaller-end unicorn ($1.75B).

> For those who've worked at both large tech and smaller companies - what are the key tradeoffs in terms of learning opportunities and career growth? Especially interested in hearing from those who later moved into entrepreneurship or product roles.

I've done both, and I put really detailed thoughts here: ["What's the difference between Big Tech and startups in terms of learning and growth?"](https://www.jointaro.com/question/KWXIrFIR1EIJsvdOdo7u/whats-the-difference-between-big-tech-and-startups-in-terms-of-learning-and-growth/)

> Any red flags I should look for during team matching/final conversations that might indicate poor team culture?

I recommend this: ["How possible is it to spot red flags about toxic culture during the interview?"](https://www.jointaro.com/question/1JwmhC3Nh9Ku0fkDL1bq/how-possible-is-it-to-spot-red-flags-about-toxic-culture-during-the-interview/)

I actually think top unicorns are better than FAANG as you get both the stability and money, but your situation is a bit tricky. BitGo seems like a very good company; however, I wouldn't put it in that highest tier (I personally haven't heard of it). As for what I think is in that highest tier, Notion is a great example IMHO (OpenAI and Anthropic don't really count as I consider them Big Tech given how they're funded). Between Notion and Amazon, I would recommend 99.9% of the time that the person take Notion.

I am *slightly* leaning towards Amazon, but I don't think you can really go wrong here with either offer. With the 2024 US election, the crypto market is definitely going to heat up (Trump is pretty much a crypto bro now), so BitGo's prospects are promising.

My advice is to listen to your gut. Which hiring manager did you enjoy talking more with? Just go to them. At the end of the day, manager and team quality are the most important thing, far more than the company overall.

First off, $200k base is *really* good for a mid-level engineer. Even if you went to FAANG, you probably wouldn't get $200k base (that's more senior band). As others have mentioned, *you should probably take the offer* unless you have a Google onsite next week or something.

Living in your parents' attic is rough, both tactically (harder to hang out and bring people over) and mentally (you don't feel independent/successful). I think your goal now should be to break out of that rut - Maybe move out into an apartment with roommates (ideally other tech people to learn more/stay motivated) to keep rent low.

When it comes to FAANG, it's more a matter of "when" not "if". You are relatively early in your career, and careers are long. I think you should just take your "bird in hand" so to speak, [work hard to crush it at that job](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/), and apply to Big Tech after 1.5+ years.

As a new junior engineer, you are almost entirely judged on your code as Jonathan mentioned before. There are 2 simple axes here:

- How fast you code (table stakes)
- How *well* you code (this is what differentiates you from other juniors)

On top of the L3 -&gt; L4 course, I recommend the full learning path here: <https://www.jointaro.com/learning-paths/nail-your-promotion-junior-to-mid-level-l3-to-l4/>

Other ways to separate yourself as a junior (all of these are covered in the course/learning path):

- Ask very high quality questions
- Regularly help other people (like other juniors/interns) instead of only receiving help (this is what juniors normally do)
- Be ultra-prepared for meetings and have a good presence in them, especially team meetings

Congrats on getting into Meta! First thing's first - Take our onboarding course (it has senior-specific lessons too): [The Complete Onboarding Guide For Software Engineers](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/)

It seems like Meta is your first FAANG-level company so senior expectations are probably higher than what you're used to for senior. For folks who are breaking into FAANG, I always highly recommend our promotion courses (even though you're not looking for a promotion right now) to get to their *current* level to thoroughly understand how FAANG engineers are evaluated. So for you, go through the L4 -&gt; L5 course here: [Grow From Mid-Level To Senior Engineer: L4 To L5](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/)

Among engineers I saw who were cut in their first PSC, they were largely E5 and above. This is because E5 is when expectations start getting really high, and most of them came from companies where senior was more like E4. I highly, highly recommend that L4 -&gt; L5 course after going through the onboarding one, and after that, go through the full mid-level to senior learning path: <https://www.jointaro.com/learning-paths/nail-your-promotion-mid-level-to-senior-l4-to-l5/>

1. Manager is new to managing (&lt;1 year of experience)
2. Manager is new to Meta
3. Manager can't come up with the overall area you'll own (especially important as I assume you were hired at E6)
4. Manager's team is imbalanced (too many senior/staff or too many junior/mid-level)
5. General negative vibes you get from your own social intuition reading people (can't make eye contact, doesn't seem honest, avoids hard questions)

Check out these other resources as well to learn more:

- ["How to navigate through team matching with Meta?"](https://www.jointaro.com/question/ctIpEokLUNbLiR86I1hd/how-to-navigate-through-team-matching-with-meta/)
- ["How possible is it to spot red flags about toxic culture during the interview?"](https://www.jointaro.com/question/1JwmhC3Nh9Ku0fkDL1bq/how-possible-is-it-to-spot-red-flags-about-toxic-culture-during-the-interview/)

Given your 12 years of experience + Master's, are you sure that you weren't just hired for Staff? It makes no sense to have the internal level be 4 and the title be Senior. 12 YOE is on the higher end of senior, so I honestly think you're just getting hired at Staff.

For the US, $400k - $500k for LinkedIn Staff sounds about right. LinkedIn tends to pay lower than the top of FAANG (mainly just Meta). On a side note, platform engineers at LinkedIn get paid more than product engineers by around 10%, so if you're platform, go for something more like $450k - $550k at Staff.

Anyways, here's our negotiation course to help with all this: [The Insider's Guide To Negotiating Your Tech Salary And Compensation](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/)

Congrats on getting the offer! LinkedIn is an amazing tech company.

In general, I'm not a fan of these very hand-holdey interview help things as they're obviously very expensive (the time of talented tech people is very valuable). This is a big reason why we made Taro as you can get access to the same information but way cheaper. I would go through our entire job searching learning path ([check out the one on DSA where I break down the FAANG grading rubric](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/)), and see if you still feel like you need additional support: <https://www.jointaro.com/learning-paths/land-your-dream-job-in-tech/>

If you absolutely need the accountability though (which some people indeed do), I think the logic should be as follows:

- **If you can't get any interviews** - [Formation.dev](https://formation.dev/partners/taro) is better as you need the full support experience, all the way from polishing your resume/LinkedIn to applying to jobs
- **If you're getting interviews but failing them** - Pay for mocks from a place like [interviewing.io](http://interviewing.io) or HelloInterview. You can actually get discounts on both as a Taro Premium member perk: <https://www.jointaro.com/perks/>

> What Big Tech level should I target? I received a L4 recruiter interview at Uber (7/18/24) and failed the recruiter call so that makes me a bit confused.

Given your experience, target higher-end of junior (L3) and lower to middle part of mid-level (L4). 1.5 YOE in this economy won't translate to mid-level a lot of the time.

I think for the most part, QA (assuming it's a real organization at your company with depth/levels) will have similar career paths to SWE, following the classic level structure: ["What do career levels structure in big tech company look like? What are the responsibilities for each level?"](https://www.jointaro.com/question/qV5oikdcgs4GWmGeousX/what-do-career-levels-structure-in-big-tech-company-look-like-what-are-the-responsibilities-for-each-level/)

I think something for you to figure out is what expectations will look like concretely at each level as the words "junior", "intermediate", "senior", etc do a lot of the heavy lifting. SWE is different from QA, but a lot of the behaviors as engineers level up are common. I recommend going through our learning paths for inspiration:

- [Nail Your Promotion: Junior To Mid-Level (L3 -&gt; L4)](https://www.jointaro.com/learning-paths/nail-your-promotion-junior-to-mid-level-l3-to-l4/)
- [Nail Your Promotion: Mid-Level To Senior (L4 -&gt; L5)](https://www.jointaro.com/learning-paths/nail-your-promotion-mid-level-to-senior-l4-to-l5/)
- [Nail Your Promotion: Senior To Staff (L5 -&gt; L6)](https://www.jointaro.com/learning-paths/nail-your-promotion-senior-to-staff-l5-to-l6/)

You have done a lot of good thinking about what questions to ask these people if they were to respond to you (very thoughtful). Now you need to focus on something even more important: ***How*** *will you get them to respond to you?*

If I were to get your a cold message like yours on LinkedIn from a stranger about my experience at PayPal, Meta, Robinhood, etc, I would definitely not respond. This is because:

1. These are very intimate, deep questions that take a lot of time to answer
2. You generally don't want to share this information too readily, especially with strangers, as you never know what will come back to bite you via some crazy leak
3. I see no incentives in the message

The good news is I think [my question asking course](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/) can help you a *ton* crafting this message. If you aren't able to manufacture some sort of incentive/paying it forward, you can definitely bolster the message by placing them more on a pedestal. If you have time, I recommend taking the entire course, but if you're busy, just go through the section about asking for favors: <https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/put-them-on-a-pedestal/>

Given Meta's much more intense nature (especially after the 2024 US election), it is effectively impossible for you to sidestep the RTO requirement. E4s are also pretty replaceable - From what I've heard, you can only negotiate a remote exception as an external hire if you're at least E6 (Staff). For internal, very high-performing E5s can do it (I know this as I have mentees who did this).

You can still try but go into it knowing that your chance of success is &lt;1%.

Best of luck and congrats on passing the Meta interview! Definitely an accomplishment.

> What do you mean by "meta" mechanisms?

It means that it's more important to focus on the system, culture, and infrastructure surrounding the tests instead of the tests themselves.

In concrete terms, it means that organizations looking to promote healthy automated testing shouldn't focus on something like test coverage as that's too primitive and reductive a goal.

Instead of that, organizations should focus on things like this:

1. Engineers getting rewarded if they write tests
2. Engineers getting rewarded if they *maintain* tests (this is arguably more important than #1)
3. Engineers being able to see the impact (i.e. volume/severity of bugs prevented) of the tests they write
4. How easy it is to write, debug, and run a test

I have seen so many engineering teams just force test coverage/volume as a goal and end up with a bunch of tests that are flaky and unmaintained. Test coverage being the KPI also incentivizes engineers to write tests for unimportant logic that is non-critical and not likely to break (i.e. the "easy" code). A real example of this is when I found several unit tests back at Instagram that were testing methods that were literally just null checks.

From first glance, the course doesn't seem worth it. I think it's much better to organize all the ways you've been failing Android interviews, look for patterns, and then honestly just use ChatGPT (and Google) to fill in those knowledge gaps. For your coroutines example, ChatGPT's explanation is decent (it's more about the overall APIs rather than the under-the-hood stuff though): <https://chatgpt.com/share/678ed83d-58ac-8007-8565-e8cebd73c1a7>

At the end of the day, [interviews are inherently random (and dumb)](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/interviewing-why-it-sucks/), so don't worry too much about the straggler interview asking you dumb trivia nobody else did. It's really hard to control for those.

Yeah, in Amazon's case, the $35k/year would be an average (so it would be like \~$150k total across 4 years).

Your first year comp would be very cash heavy:

- $150k salary
- $7.5k RSUs (5% of $150k)
- $25k cash from a signing bonus which is prorated

Amazon should just get rid of their infamous backloading honestly. It's a nasty way to convince people to stay longer (assuming good stock growth), and it's so, so confusing.

TikTok is one of the best tech companies in the world: Even getting the average rating as a mid-level engineer is very tough. I'm sure you could land senior offers at good companies, even with the current climate. Believe in yourself!

As Rahul alluded to, don't overthink it. For the most part, the market will level you. On your end, do the following:

- Apply to both mid-level and senior roles
- Make sure to have senior-level stories and show senior-level behaviors during the interview (check out the [behavioral interview course lesson here](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/senior-engineer/))
- Get as many offers as possible to maximize leverage, giving you the best chance of negotiating an uplevel if you need to

If they ask you for your current level, there's some nice dialogue to reply back with here: ["Recruiter asking what my current level is when applying for new roles - how to answer?"](https://www.jointaro.com/question/2fK71r3NhIuhLzq07atk/recruiter-asking-what-my-current-level-is-when-applying-for-new-roles-how-to-answer/)

Best of luck! The situation with TikTok is a complete mess right now. Hope all the hard-working engineers there like you end up okay 🙏

Schools do matter, but work experience reigns above all. The main thing to look at is prior internships. Let's say you have the following 2 students:

- **Student 1:** Berkeley degree (Top 10 CS school), no internships at known companies
- **Student 2:** Degree from no-name university but interned at OpenAI

Student 2 is going to be way stronger, and the fact the company managed to get this person is very impressive.

Jonathan's framework is very good.

> Am I being an optimistic idiot?

You are not. Your heart is in the right place, and I think this is a good idea. If it isn't, that's fine - Being a good engineer is all about trying stuff and seeing what fails!

Here's some good resources to help you:

- ["How do you answer questions effectively?"](https://www.jointaro.com/question/0tDjq7S2uYZRy3pT0U9v/how-do-you-answer-questions-effectively/)
- ["How can I teach and onboard other engineers faster?"](https://www.jointaro.com/question/tNvKJAgJanv6wdTBlIui/how-can-i-teach-and-onboard-other-engineers-faster/)
- ["How can I help juniors?"](https://www.jointaro.com/question/OzbQJCzLPbOKTEqpeSxF/how-can-i-help-juniors/)

Taro's too small to have any real automation, but back at Instagram and Robinhood we mainly had a mix of these 2 things:

- Unit tests
- Snapshot/integration tests (snapshot tests are specific to mobile and front-end overall)

In terms of making testing more effective, my main advice is to focus on the more "meta" mechanisms surrounding testing instead of just the test coverage itself. You can find more very detailed thoughts here (thread is mobile-focused but applies to everyone): ["What do mobile testing strategies look like at top tech companies?"](https://www.jointaro.com/question/fpySzIO02aQ0sCz5N6dP/what-do-mobile-testing-strategies-look-like-at-top-tech-companies/)

For FAANG junior, you usually don't get much equity, with most of your pay being salary. In the US, the typical package is between $175k - $200k and will look something like this:

- $150k salary
- $35k RSUs per year

Amazon is weird due to its backloaded vesting. To offset this and make your TC normal, they will give you a big signing bonus that vests across the first 2 years.

On a side note, I recommend learning more about equity as you won't get stock options at Amazon, just RSUs. Stock options are particularly for startups. Check out our tech pay explainer masterclass here: [\[Masterclass\] Understanding And Optimizing Your Pay In Tech](https://www.jointaro.com/lesson/gk408yBIV2fa5RjVR213/masterclass-understanding-and-optimizing-your-pay-in-tech/)

You get a rating every 6 months with a full-blown PSC happening every year. Working backwards from that, 6 months is the absolute latest you can be at effectively 100% productivity.

In the current economic climate, particularly at Meta, I think it's much shorter nowadays. After 3 months, you should be 90%+ of the way to full productivity as an E5.

I made a case study about onboarding at senior+ levels at top companies here: [\[Case Study\] Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta](https://www.jointaro.com/lesson/X8vpfJooDpsX915ouC00/case-study-becoming-a-tech-lead-again-in-just-1-month-after-joining-robinhood-from-meta/)

Check out the onboarding course too: [The Complete Onboarding Guide For Software Engineers](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/)

I found an article which links the original whitepaper: <https://productschool.com/blog/product-fundamentals/spotify-model-scaling-agile>

It's cool you bring it up as I remember talking to the VP of Engineering at Course Hero about this back when I was there. He was considering using it to scale Course Hero's engineering org (we were hiring like crazy back then).

While the ideas seem cool, I honestly felt like it was way too complicated and idealistic. It's really hard to build solidarity groups outside of your immediate org-chart. If you want X group of engineers to regularly collaborate and cross-pollinate info, they should all just report to the same manager or skip manager. From there, have it baked into your leveling structure that engineers are expected to lead, collaborate, and cross-pollinate more as they get more senior (e.g. at staff, you are expected to regularly bring multiple teams together for a common goal).

At a high-level, it was a combination of:

1. Time (I built those apps across \~10 years)
2. Being easily annoyed with suboptimal UI/UX 🤣

To help with #2, my recommendation is to not just be complacent with Big Tech apps and assume you can't add value on top of them. In particular, *"addition by subtraction"* is very powerful. Big Tech apps will often have 100+ features and do them all sort of okay. You can add value by creating an app that just extracts 1 to 3 of those features and does those extremely well.

A personal example from me is Google Maps. It's great for real-time navigation and location discovery, but it's pretty bad at saving very specific locations (the feature is buried many clicks deep). It's particularly bad at saving raw locations that are just lat/long. I remember being annoyed that I couldn't save the random location where I parked, so I made a simple location saver app and got \~1,000 downloads.

To go deeper, check out my side project course: [Build Side Projects With 500k+ Users: Coming Up With An Idea](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/)

Check out the #job-searchers-accountability-group on Slack! If you aren't on the Taro Premium Slack yet, check your email, including spam - You should have gotten an invite.

If you can't find an invite, email us at [help@jointaro.com](mailto:help@jointaro.com).

You can check out Taro Networking as well: <https://www.jointaro.com/networking/?selectedServices=Mock+Interviews>

> I recently accepted an offer at a decent place.

Congrats! 🥳

You should 100% take the offer:

1. Being a FTE at Big Tech is 3x-5x more prestigious (maybe even more) than being a contractor there. It will help you a ton with future job searches
2. You get the stability of being FTE vs. a contractor who is much easier to let go (contractors don't get severance). Execs need to think twice about laying off FTEs
3. Big Tech has historically outperformed the S&P500. So your equity package will likely go up over time, increasing your TC
4. At pretty much every Big Tech I know of, [contractors get worse scope than FTEs](https://www.jointaro.com/question/KM6mWpwwCZHRwh2WF4LI/faang-contracting-is-it-worth-it/), hampering their career growth

Your disadvantages are valid, but I don't think they are enough to outweigh everything I mentioned here.

Also, I am confused as to how the grant works: Normally RSU grants are across 4 years, so after the 1-year cliff, you get 25% of the stock. Are you getting 50% of the stock after the 1-year cliff so that your first year comp is higher than following years...?

ChatGPT and Copilot are the big ones. There are folks using Gemini, Claude, and Perplexity as well. Most recently, Cursor (AI-powered IDE) has been popping off.

I am using ChatGPT a decent amount as I pick up Node.js back-end development again. It's been really helpful as a faster Google effectively where I can quickly familiarize myself with basic syntax and mechanics (e.g. how to write the cleanest loop, how to check for null). It gives code that I can usually copy-paste (after I verify it of course) alongside good explanations.

When it comes to the higher-level stuff though like code structure, I am relying on my own fundamentals ([all programming languages are effectively the same](https://www.jointaro.com/lesson/wUl3hc2wr1ms493bd23b/this-is-how-software-engineers-should-initially-learn/?playlistId=iBKHYpkjd0BRWWLKQG2j)) and doing that myself. AI is generally pretty bad at this stuff as [code quality is very context-dependent](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/code-quality-isnt-static/), and there isn't a lot of information about deep optimization for it to train itself on (this is the kind of stuff that's gatekept by working at top companies like FAANG).

As for 20% - 40% boost, I am skeptical, but it depends on the organization. If your engineering organization doesn't really care about quality and the blocker really is just code velocity instead of something like lack of alignment, I could see that. Otherwise, not really.

Here's some other good resources to go through:

- ["What are the top 3 generative AI tools/use cases that can boost productivity?"](https://www.jointaro.com/question/x8JTm70Go8yQdWVmRWJO/what-are-the-top-3-generative-ai-toolsuse-cases-that-can-boost-productivity/)
- ["How Can Junior/Mid-level Engineers Effectively Integrate AI into Their Coding Workflow?"](https://www.jointaro.com/question/dlsuqOZpW9O2zOjdCUIl/how-can-juniormid-level-engineers-effectively-integrate-ai-into-their-coding-workflow/)
- ["Are there any AI tools that can validate design approaches?"](https://www.jointaro.com/question/IbfRZiN2VTWHGVpS1iMy/are-there-any-ai-tools-that-can-validate-design-approaches/?revalidate=true)

First off, I totally get the vibe when leadership is being ambiguous with what they want (honestly, they probably don't entirely know themselves). But at the end of the day, it's much better to have the CTO with you rather than against you. I would try to build a bridge here:

- Assume good intent and that the CTO just wants their engineers to build stuff better while having you be a lead empowering these other engineers to be better
- Ask the CTO for any examples they can come up with where they felt like the code quality wasn't up-to-par and there was some sort of clear negative impact
- Try to talk to them in a friendly environment to extract this information as smoothly as possible. If you're in-person, the optimal one is over lunch or coffee

When it comes to the docs themselves, my advice is to essentially take what you do yourself with planning and code review, and just turn that into words as closely as you can. This is a great exercise for 2 reasons:

1. Building a deeper understanding of yourself is always valuable, particularly when you are trying to communicate your values and principles with someone
2. I don't know about you, but I love it when all the engineers I'm leading are on the exact same page when it comes to process, standards, and quality. This was a big reason why I was so successful at Instagram - I aggressively picked up mentees and molded them in my ways. My Instagram oncall case study is a great example of that: [\[Case Study\] Revamping Oncall For 20 Instagram Engineers - Senior to Staff Project](https://www.jointaro.com/lesson/esVxIGXYC5BdgxXUkO6H/case-study-revamping-oncall-for-20-instagram-engineers-senior-to-staff-project/)

I feel like daily updates is overkill, but if you can do it, go for it! [I have rarely found overcommunication to be a problem](https://www.jointaro.com/course/effective-communication-for-engineers/effective-communication-guide-part-1-core-high-level-principles/), and if it is, they will tell you. It's much better to adjust down (e.g. go from a daily update to a twice-a-week update) then to adjust up (e.g. realize that your manager really wanted weekly updates while you were only giving monthly). The latter is a recipe to be labeled as a low performer, and in an intern's case, not get a return offer.

What I will say though is that if you're doing organic status updates outside of 1 on 1, don't use the 1 on 1 to do more status updates. Try to have [that awkward 1 on 1](https://www.jointaro.com/lesson/xjeFRpp5YHxG9TTK8wjn/1-on-1s-are-the-time-to-be-awkward/), and in your case, you just want feedback on how you're doing. Given how internships are so short, I think it is very reasonable to effectively ask *"How am I trending towards a return offer?"* (and ask for feedback as well obviously) every 2-3 weeks. With a standard 12-week internship, even just 2 weeks is over 15% of your entire time there.

If you haven't already, I recommend this course as well (it's specific to Meta, but it also covers many fundamentals that apply to any internship): [Nail Your Return Offer As A Meta Software Engineer Intern](https://www.jointaro.com/course/nail-your-return-offer-as-a-meta-software-engineer-intern/)

All of the AI chat bots (ChatGPT, Gemini, etc) are relatively decent-ish at this. However, you need to be specific with your prompt. In particular, you should lay out your system design values (e.g. velocity vs. quality, fail fast vs. suppress, what you value the most among resilience, scalability, correctness, etc).

*My advice is to treat the AI as a friendly partner to bounce ideas off of and listen to yourself in a productive way, not as an authoritative source.* This is because there is no such thing as a "right" system design due to system design being all about trade-offs and what your organization's specific engineering culture values. AI is much better suited for situations where there is a clear cut optimal solution like data structures and algorithms problems. With open-ended problem spaces, AI struggles immensely.

On top of all this, you should never have AI be your sole source of system design feedback. You should always run a technical design proposal by actual humans. A competent Staff Engineer will give you 10x better feedback on your design compared to AI, even if you gave the AI the most specific prompt in the universe.

No matter what you do, you need to make a detailed system design doc to either feed into the AI, your team, or both. Go through this course to learn how to do that: [System Design Masterclass: Shipping Real Features To Production](https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/)

> ...so hoping I can at least make a better user experience ;)

That's the spirit 😇

You have the following options:

- **Talk to your manager about getting more fulfilling work** - If you have at least a decent relationship with your manager, I would pursue this path. Frame this as a mutual benefit (*"I want to have more impact by taking on more ambitious work"*). Yeah, this conversation could be awkward, [but 1 on 1s should be awkward](https://www.jointaro.com/lesson/xjeFRpp5YHxG9TTK8wjn/1-on-1s-are-the-time-to-be-awkward/).
- **Switch teams** - Based on what you've said, I assume this is hard, but I would try it anyways.
- **Switch companies** - This is the nuclear option. Given that market, switching jobs entirely is a huge grind and quite an unpleasant experience overall. I would pursue the first 2 before trying this. If this is what you want to do though, check out our learning path here: [Land Your Dream Job In Tech](https://www.jointaro.com/learning-paths/land-your-dream-job-in-tech/)

I feel like you're overthinking this - I can't imagine applying through the portal would hurt you if you also reached out to the hiring manager directly as well. If it makes sense to do both, do both.

What I will say though is that I wouldn't try to reach out to the hiring manager behind every single job you apply to as that would be a waste of time. For a reach out, at least 1 of these criteria should be met:

- The hiring company is a small startup (100 people or less)
- You have a genuine connection to the hiring manager (you used to work with them, you met them at a conference, etc)
- There is a special resonance between the company and you. It's not just another company where you primarily just want a high-paying job from them. I see a lot of engineers delude themselves that FAANG in particular is special to them

I dig deeper into all this alongside how to send an effective reach out here: <https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/cold-messages/>

Good question! There's a lot of options here:

- [**Get promoted from senior to staff**](https://www.jointaro.com/learning-paths/nail-your-promotion-senior-to-staff-l5-to-l6/) - Of course, this will require a modern company that supports IC-levels beyond senior. However, I feel like most companies offer this, especially FAANG and FAANG-equivalent companies (Uber, Airbnb).
- **Stay at senior** - Being a senior software engineer is already a large accomplishment. There's nothing wrong staying at this level forever, especially to [preserve work-life balance](https://www.jointaro.com/playlist/JNCZ1vbRF3NwsOQCqblt/). Being staff is very stressful, and I know several engineers who purposely down-leveled themselves from staff to senior.
- **Become an engineering manager** - This is a very traditional path as you mentioned. But it's obviously not for everyone and spots are limited (there are far more IC engineers than engineering managers). Here's a good playlist to learn more about this transition: [\[Taro Top 10\] Software Engineer To Engineering Manager (IC -&gt; M Track)](https://www.jointaro.com/playlist/oz0mnJvHHgM8NfVF7rgp/)
- **Pivot out of software engineering** - The most common paths I've seen here are becoming some sort of project manager or product manager. For the product path, check this out: [\[Taro Top 10\] Product Management For Engineers](https://www.jointaro.com/playlist/qy9UeZWKqbb5Hl6h5Vtr/)

5% is actually quite low for a stack rank target, pretty much as low as it can go. What was unclear to me was whether the stack rank target is 5% for this year or he is tacking on another 5% to whatever percentage Meta already kicks out every year.

Even when I was at Meta, it would target to fire 5-10% of engineers every year. Meta has a very high bar, so there were always a lot of people who couldn't meet the bar.

At FAANG, the stack rank/PIP percentage can be as high as 15%. Amazon in particular is notorious for stack rank and PIP culture.

> A quick search leads me to a handful of openings for software engineer positions at Salesforce .... so they are still hiring?

Hehe, got 'em 🤣

The lesson here is to not take tech CEOs seriously (at least not initially).

#3, #4, and #6 seem the best to me, especially #3 which feels table-stakes. The main resource you cultivate at any job, especially at more senior levels, is the relationships.

Finding mentees seems awkward as you are on your way out.

Congrats on the new job!

The remote work/WFH policy should be on the job posting - Is it not there? If it really isn't, I would ask the recruiter. I think that question is fair game, and you don't need to use some ultra-carefully crafted language to ask.

I would ask this ASAP, assuming hybrid work is a deal breaker for you and you can't do 5 days RTO. A pretty bad outcome is to go through the entire loop, get an offer, and then realize they are 5 days RTO so you can't take it. This is the worst failure mode as it costs everybody a ton of time.

If a company thinks lesser of people who want remote work, that's probably a red flag and you shouldn't work there anyways.

What time zone are you in? It's tricky as Taro is a very global community.

In terms of my own events (primarily Group Office Hours), I go on opposite sides of my spectrum for maximum coverage:
- 9AM PT
- 5PM PT

California morning is doable for Europe and India alongside the US if they can work it into their work day. Late afternoon is doable for US folks who need to plug into Taro after work alongside folks in East Asia/Oceania (Australia, Singapore).

Feel free to host an event of your own as well - Just reach out to Rozie Delgado in Slack!

In terms of life at Meta, it will get worse and already has. Stack rank percentages and PIP quotas are being cranked up. Everyone is more stressed out and working longer hours. I still have a lot of friends/mentees there, so I hear all the stories.

Meta is the most represented group in Taro, so I hear what life is like at Meta through Taro as well.

I still think Meta is overall a good place to work though for most people. It's not just Meta losing their chill - It's every Big Tech company.

Unfortunately, I think this is mostly, if not entirely, political. Trump and the Republicans swept all layers of government in the 2024 election, so Zuck is doing what he can to get on Trump's good side. In particular, Trump is currently against the TikTok ban, flip-flopping from his position just 3-4 years earlier. Zuck wants to flip Trump back to being anti-TikTok.

All of this behavior is unethical, but that's capitalism. I don't blame Zuck for following the incentives laid out for him in our capitalistic system. At the end of the day, Zuck's priority is to boost Meta's share price, no matter what. He is simply executing on his duty.

I wouldn't take what Zuck says too seriously. FAANG CEOs are very far from being arbiters of truth and morality.

Yes, code machine is definitely the odd one out among the archetypes. At Meta, I would say maybe 1-2% of Staff+ engineers fell purely into that archetype.

It is a hard archetype to sustain as it requires many conditions:

- Extremely high technical complexity (so delegating is near impossible)
- Lots of greenfield areas where a ton of code can be written
- Spaces where large amounts of alignment aren't needed. Many code machines at Meta focused on making high-fidelity prototypes super fast

At Big Tech, very few organizations meet those conditions. My org at Instagram Ads certainly didn't so we had 0 code machines. Portal did, so we had 2-3.

Marc Benioff is also known for saying crazy things, but this statement makes more sense. Salesforce is a very bloated organization. It has a headcount of \~70,000 people with a market cap of 300 billion. For comparison, Meta has the same amount of employees but a market cap 4x higher. However, I assume he will still be hiring in 2025 for backfill when engineers leave, especially high-performing senior+ engineers.

AI won't directly replace engineers (i.e. you fire an existing one and put an AI in its place), but it does make them more productive. If leveraging AI properly, a team of 7 engineers can match the productivity of an AI-less 10 person team. This will lead to less headcount being needed over time, especially for junior engineers. It's typical for a Big Tech company to be 10-20% junior engineers - This could drop to as low as 2-5% in the future.

For future junior engineers, things will be more competitive and they'll need to leapfrog the junior phase faster with self-study. [Side projects](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/) and [open-source contributions](https://www.jointaro.com/course/become-an-open-source-master/) will be more important as it will become harder to get work experience to go past junior (as less companies will be hiring juniors). My side projects allowed me to get hired directly at SW2.

Very late to the party here, but I'm super glad you fixed the bug! It's really awesome how you write out that entire process - [That's exactly what engineers should be doing as they work on tasks to increase their chances of root-causing faster](https://www.jointaro.com/lesson/Xto64GnsyxIGs24axaI8/this-is-the-easiest-way-to-get-better-at-debugging/?playlistId=H6KpEhiZPVLyO3HQ9pIn).

> How credible is this?

I'm going to be honest, Zuck has kind of gone crazy over the last year or so. This is coming from someone who empathizes with him and thinks he's treated unfairly by the press, particularly with politics. I wouldn't treat anything he says nowadays very seriously. As Ilya mentioned, all of these Silicon Valley CEO billionaires have an agenda. For FAANG in their particular, they want to convince everyone of the following:

1. AI will quickly reach a point where it can do everything ever
2. Big Tech will be the driving force behind this AI revolution, making hundreds of billions of $$$
3. (buy Big Tech stonks and drive up their share price)

It's been 2+ years since ChatGPT came out, and it's still struggling to fully independently write code that would meet expectations as a Meta E3 (junior), let alone a Meta E4 (mid-level). I'm sure it'll get there someday, but definitely not within the next 1-2 years.

> How to prepare?

There's nothing special you need to do - Just keep developing senior-level behaviors that are independent of the code (i.e. follow the advice in Taro 😛). This is something every engineer everywhere should already be doing, AI revolution or not. Here's some great resources to get started:

- [\[Course\] Grow From Mid-Level To Senior Engineer: L4 To L5](https://www.jointaro.com/course/grow-from-mid-level-to-senior-senior-l4-to-l5/)
- ["What are software engineering fundamentals?"](https://www.jointaro.com/question/3VNPK7wol76s89EkgFeW/what-are-software-engineering-fundamentals/)

Here's another fun AI doomsday thread: ["The AI frenzy is really making me rethink my career - What direction should I take?"](https://www.jointaro.com/question/z4yxcV50SBaCLea3dBMA/the-ai-frenzy-is-really-making-me-rethink-my-career-what-direction-should-i-take/)

At a very high-level:

- **Product** - Build stuff for end-users
- **Infra** - Build stuff for other engineers

I am not 100% familiar with how every org does the labeling though, so I'm sure these guidelines have a ton of exceptions. Someone recently told me that all of ads is labeled as infra now, which is super weird (I literally worked on ads product at Instagram).

If you're joining as an E5, I recommend joining an infra team as that should generally have better scope to grow to E6 (Staff). Again, there are exceptions to this, and it really depends on how you operate/think as an engineer. More thoughts here: ["Between platform (serving developers) and product teams (serving end customers), what should be one's preference based on level?"](https://www.jointaro.com/question/zyEImoKWObsSm8YymzvT/between-platform-serving-developers-and-product-teams-serving-end-customers-what-should-be-ones-preference-based-on-level/)

Here's some good advice on how to pass the Meta interview: ["How does the Meta interview work?"](https://www.jointaro.com/question/Ne8lv2jCMZGuSGkr8wp9/how-does-the-meta-interview-work/)

I think you have already balanced it. As a back-end developer, you are naturally closer to the AI/ML stack then front-end developers are. You can specialize your back-end skills to work on ML-adjacent areas, and of course, go to a cutting-edge company that has AI applications (FAANG, Snowflake, Reddit, etc).

It's not like you need to be a pure MLE to be employed in the future - That's ridiculous. More thoughts here: ["The AI frenzy is really making me rethink my career - What direction should I take?"](https://www.jointaro.com/question/z4yxcV50SBaCLea3dBMA/the-ai-frenzy-is-really-making-me-rethink-my-career-what-direction-should-i-take/)

Multi-tasking is a spectrum that is denominated by time-span. Extreme multi-tasking is literally switching between multiple tasks within the same hour, which is what you're doing. A more reasonable multi-tasking level which I think you should aim for is dedicating certain days to tasks, making your multi-tasking at a weekly level (Monday/Tuesday is Project A, Wednesday - Friday is Project B). As a junior engineer, it will be a lot tougher to multi-task.

If you are going to aim for a daily multi-tasking throughput, try to spend at least a couple hours on a single task before moving off as Charlie mentioned. [Focus blocks are tremendously powerful at your career stage for deep productivity and learning.](https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/focus-blocks/)

My suggestion is for those 10-15 minute waits, *you should review someone else's pull request* (this was my go-to when I had these small time blocks). Other things you can do are going for a walk around the office (given that you're at Amazon, I'm accounting for 5 day RTO here), talking to a teammate (small talk, task alignment), or doing some writing (updating brag journal, setting 1:1 meeting agenda).

Here's another good thread as well: ["How to improve at multi tasking at work?"](https://www.jointaro.com/question/ION8KZHyA8fNWOpHDhZI/how-to-improve-at-multi-tasking-at-work/)

If you're not able to break up aggr1, aggr2, aggr3, etc into separate entities that can be run in clearly separate phases, can you just add a *ton* of well-labeled logging?

The key to debugging efficiently is [breaking down the entire code-flow into clear steps](https://www.jointaro.com/lesson/2cJlQgjXDDOGpAkFy8xl/once-you-get-this-you-will-be-able-to-fix-any-software-bug/?playlistId=H6KpEhiZPVLyO3HQ9pIn). In an ideal world, you can just carefully step through and be able to "rewind" to certain phases, but if you can't and need to rerun the entire pipeline every time to verify a fix, add a ton of logging to capture the entire process and see what assumptions are broken.

The logging makes it so that when you do try a fix and pay the large cost to validate it, you have a (hopefully) very large chance of the fix being correct due to it being very well-educated via the logging insights.

Node.js is a very popular framework. Python/Java/C++/C are all top-tier languages in terms of usage as well, [but C++/C are tricky for passing DSA interviews due to their verbosity](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/programming-language-selection/).

All that being said, I would first figure out what SWE work you can pick up around DocuSign by talking to your manager and SWE peers (ideally tech leads). It's generally better to have self-study reinforce what you're already doing at work.

*First off, don't think about leaving the company - You are literally just 4 days in and LinkedIn is one of the greatest tech companies in the world.* Based on your context, I assume you're working at LinkedIn India - I don't know about the pay there, but in the US, LinkedIn pays top-of-market. It's an amazing place to work for that most engineers can't even get into.

Go get married first (congrats!), and after you come back, settle in and try to meet as many people as possible to understand the organization. Follow the advice from here:

- [The Complete Onboarding Guide For Software Engineers](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/)
- [\[Masterclass\] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)

It generally takes 1-2 months to build a meaningful understanding of an organization, especially at a senior/staff level.

All that being said, it does seem like your team is working on an internal tool without a ton of scope. Big Tech companies are filled with these teams like these. These teams aren't inherently bad though as they often have a *huge* benefit that you have identified: Work-life balance.

Being able to work 9AM - 3PM in this economy for a company as prestigious as LinkedIn is an opportunity many engineers would kill for. Yes, it's not likely you can get to Staff on this team (certainly not in 1.5 years), but being able to have so much free time outside of work is a huge asset.

If it turns out that you really can't stand this team after 3-6 months, you can talk to your manager about doing an internal transfer. LinkedIn is a huge company with thousands of great teams - It's much better (and easier) to switch internally than to job hop entire companies from my experience.

DocuSign is a large, great company (look at that stock price over the last year!), so you likely have an opportunity that many engineers don't have: *Internal mobility*

You have seniority and ownership alongside what looks like a solid amount of practical experience with JavaScript. *My advice is to parlay that into getting the experience you want at your current job.*

Talk to your manager and partners you have on the SWE side to see if there's SWE work that you can pick up, particularly projects that lie at the intersection of software and data. The ideal scenario is that you hybridize in this way and eventually pick up so much SWE work on the side that DocuSign just lets you switch over internally. This will make it 10x easier to convince Netflix to hire you in your dream role as another big company has already given you their blessing to do it.

These are for different transitions, but the concepts are similar:

- ["How do I transition from QA into SWE?"](https://www.jointaro.com/question/EA3qCjmCMzyZcV6hFNMI/how-do-i-transition-from-qa-into-swe/)
- ["How to transition from back-end development to distributed systems?"](https://www.jointaro.com/question/zzb5xiaRVK1pOmeCzG97/how-to-transition-from-back-end-development-to-distributed-systems/)

I also have some comments on your perceived technical gaps:

- **Front-end/design** - Based on what I've read (and what I've seen from data folks transitioning over to SWE), being a back-end engineer seems like a better fit for you? I know that visualization tools can come into play for data, but those are often internal and the design bar isn't super high.
- **TDD** - I don't think TDD (at least as how it's traditionally defined) is worth it. FAANG largely doesn't really do it. More thoughts here: ["What are your thoughts about Test Driven Development? Do you think it adds value in your career?"](https://www.jointaro.com/question/SYwVplJYcyO8Sr7PLT2j/what-are-your-thoughts-about-test-driven-development-do-you-think-it-adds-value-in-your-career/)

Switching jobs/interviews is a big reason why specializing is a lot better - It's generally easier to get opportunities if you can effectively brand yourself as a high-quality specialist, especially for engineers with &lt;5 years of experience.

In your scenario, I suggest figuring out what path you want to take. I think it's worth it for you to dabble in front-end just to see if you like it. If you do, you can invest more into it by taking on more front-end tasks at your current job. Eventually you'll have enough experience there that you can brand yourself as a front-end engineer on your resume/LinkedIn and apply to front-end roles.

Conversely, if it turns out that you hate front-end, invest yourself more into back-end and brand yourself as that.

Your resume and LinkedIn are artifacts that you completely own, so you can use that to control the narrative surrounding yourself.

Good question! My general advice goes as follows:

1. **Do what gets the most impact for your team** - This is always the highest priority as it's best for earning trust, making your team more respected (and less likely to get laid off), and building up general skills (product intuition, communication, etc). If front-end adds the most impact, do front-end. If back-end adds the most impact, do that. If the team really needs a full-stack person who can do both, do that (I've seen this scenario many times, including among my mentees who needed to do this to get to senior at Meta).
2. **Try to specialize** - I'm a huge believer in [going deep, not wide](https://www.jointaro.com/lesson/wUl3hc2wr1ms493bd23b/this-is-how-software-engineers-should-initially-learn/), but this still comes after #1. What you can do though is try to sway your path - Ask your manager if you can work out a niche that's specialized in just one or the other. If you do end up as a full-stack developer but want to specialize, you can reinforce the side you want via [side projects](https://www.jointaro.com/course/build-side-projects-with-500k-users-coming-up-with-an-idea/) and [open-source](https://www.jointaro.com/course/become-an-open-source-master/).

The vast majority of the time, engineers switch jobs without having a gap in employment, i.e. [they have their next offer teed up while they are working at their current job](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/interviewing-while-employed/). Are you not able to do that? It's certainly tough, but it's possible. You'll need to carve out some time after work and on weekends and save some PTO days for the onsite/final round interviews.

When it comes to succeeding in what is effectively "survival" mode, there are 2 components:

1. **Define clear expectations** - The formula here is pretty simple. First, talk to your manager about what it takes to meet expectations. Second, do that with 5-10% extra for buffer (just in case). Devote whatever remaining time you have left into personal life, side projects, interview prep, etc.
2. **Get more from your time** - The more impact you can land per unit of time spent, the more free time you'll have after executing #1. Follow the advice from here: [\[Course\] Maximize Your Productivity As A Software Engineer](https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/)

If you are going to try and remedy this situation, I recommend this thread: ["My manager and I don't see eye-to-eye. How can I improve this relationship?"](https://www.jointaro.com/question/WWuU0HRpNu90J638iJPs/my-manager-and-i-dont-see-eye-to-eye-how-can-i-improve-this-relationship/)

If not, I recommend trying to leave, ideally with an internal transfer to a different team (assuming you like the company) or switching companies entirely. If you're taking the latter nuclear option, I recommend this: [\[Course\] Ace Your Tech Interview And Get A Job As A Software Engineer](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/)

It seems like you should switch teams. Managers are hard to change ([because most managers are bad](https://www.jointaro.com/lesson/4NJbAn0uTDUPfYfa859V/this-is-why-most-engineering-managers-are-terrible/?playlistId=nbrlPXodHrOIBccAmzr8)), even when they have good intent.

There are 4 types of managers:

1. **Good intent, good skills** - These are the best managers. Rockstars.
2. **Good intent, bad skills** - These are managers who genuinely want to help their people but don't have the skills to do it (yet). This is very common. It's rough, but this is at least redeemable.
3. **Bad intent, good skills** - This is very, very rare. If a manager doesn't have the right intentions, they are usually bad.
4. **Bad intent, bad skills** - This is unfortunately most managers. Many managers go into the job for money/power and don't actually care about growing people.

It seems like you rolled #4. Managers in this bucket can't be changed 99.9% of the time. I would leave ASAP.

You should 100% use TypeScript. JavaScript/TypeScript are concise and fast, making them a great choice to beat the clock (i.e. one of your biggest enemies in coding interviews).

If you're using it for work, it will also be your sharpest language. Win-win.

From a product value perspective, *this idea is extremely good*. You are taking a manual behavior that everyone is already doing and automating it with the power of code, which is the classic value add of software. This tool would also make it very easy for folks to follow the advice in our job searching course about [building and understanding your interview funnel](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/organizing-your-job-search/).

The problem with this idea is that it's very complex despite technically being a solo-player app:

1. **The technology is complicated** - You need to ingest the data from Gmail (3rd party integrations are always hard due to regular API/SDK changes), process it with an LLM (which won't always get the interview stage right I'm sure as this is fuzzy data), and then convert everything into structured data (the schema is no joke either, and you'll probably need a lot of fields).
2. **You need the UI to be good** - You are competing with someone just manually organizing their emails into certain folders/tags, and the Gmail UI is honestly not too bad. You need to be a step function better to be able to attract users, which means that your UI really does need to be clean, smooth, and intuitive. The design bar is high as Sai mentioned.

In short, you will need to be both good and back-end and front-end for this to have a real chance at success. The bright side is that even if this side project doesn't get any real traction, I'm sure you'll learn a ton just building it.

As for an MVP, I'm having trouble scoping it down into something super-duper simple that also provides some modicum of user value. I'm thinking you need to set up the Gmail ingestion (obviously), and from there, just have the LLM parse out a company and a status enum field? From there, you show it in a table of some sort. That should be enough to share, and if you really grind at it, I think you can have something decently polished in 1 week?

I've actually talked with other Taro members who have had a similar idea and tried building it, but none of them succeeded due to the aforementioned high quality bar. That being said, you are a senior engineer already, so you'll have a better shot.

If you are able to pull this off, this will *easily* clear 10,000+ users and probably hit 100,000+ and maybe even 1 million+ as well. This is one of those side projects that can easily be turned into a legit tech startup if there's enough traction.

Good luck!

I actually originally had a skills section on earlier versions of my resume. I removed it later on as the technologies were organically woven into the experience sections anyways, and I was running out of space due to my work experience and side projects growing rapidly.

I definitely don't think you need one (I'm living proof of that), but if you have the space, you can put it down. It'll reinforce your resume a little bit against the ATS keyword checking in theory. I don't think it hurts you unless you need the space.

I don't know if they're "fun", but there's a lot of nice book recommendations here: ["Must read books for new software engineers?"](https://www.jointaro.com/question/oDIyUFCNQjUOOhfyL6rs/must-read-books-for-new-software-engineers/)

If you have extra time after finishing all those books, I actually do have a fun one that isn't mentioned in the other thread (it's about user research though, so it wouldn't be super relevant unless you're doing a startup or are a very product-focused senior+ engineer): [The Mom Test](https://www.audible.com/pd/The-Mom-Test-Audiobook/B07RHWCHD8)

Jonathan gave a lot of excellent points with very specific tactics on finding scope. On the other hand, I have a higher-level, broader approach that starts off with a simple realization: (almost) *Every senior engineer wants to get to staff.*

Let's keep up the simple ideas: [In order to get to level X, you need to be able to create scope for level X-1](https://www.jointaro.com/course/nail-your-promotion-as-a-software-engineer/an-easy-way-to-understand-the-next-level/). So if the senior iOS engineer on your team wants to become a staff iOS, they need to be able to create high-quality projects that are comfortably senior level.

Tactically, this means my recommendation is to *just talk to the senior iOS engineer and see what big, ambitious ideas they have on their backlog.* Reassure them they can bring on the "sushi grade" and raw ideas are okay - It's expected for high-performing senior engineers to work through lots of ambiguity anyways. An interesting way you can tease out these ideas is to have a 1 on 1 with them and ask them a question like this: *"If you had a magic wand and could solve any problems across the team, what would you do?".*

Software engineers are always looking for projects and scope, but those are downstream artifacts. In order for those to exist, you need to start off with a problem. If you have just a problem, that is enough to create scope.

All of this rests on the assumption that your goal right now is more to solidify your reputation as a high-performing senior engineer, not start seriously pursuing the jump to staff.

Here's some other resources I recommend checking out as well:

- ["How do I come up with innovative, impactful ideas and bring them to my team?"](https://www.jointaro.com/question/3QIJhAT4loA7n1hSfCuw/how-do-i-come-up-with-innovative-impactful-ideas-and-bring-them-to-my-team/)
- [\[Course\] Grow From Senior To Staff Engineer: L5 To L6](https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/)

Bay Area Tarodactyls unite!

Join us in Palo Alto for the Silicon Valley Taro meetup! Come by to:

- Network with 75+ talented and ambitious tech workers
- Enjoy snacks and drinks (yes, we will have Taro boba!)
- Meet Alex, Rahul, and other industry veterans from companies like Meta, Robinhood, Google, and Pinterest

To stay up-to-date on logistics (especially on the day-of), make sure you're a part of the #g-sf-bayarea-meetup channel in the [**Taro Premium**](https://www.jointaro.com/r/achiou15/) Slack.

We're excited to meet you!

Tech Lead/Manager at Meta, Pinterest, Kosei

Rahul Pandey

Meet Alex & Rahul - Taro Bay Area Tech Meetup

In order for a side project to actually matter on your resume, it must have a meaningful amount of users. Follow the advice from this course to learn how Alex came up with feasible (but exciting) project ideas to build 3 apps with 500k+ users.

[Course] Build Side Projects With 500k+ Users: Coming Up With An Idea

Master the LeetCode interview with this in-depth course covering core DSA concepts in detail with animated visualizations and full code examples in Python.

[Course] Crash Course: Beginner Data Structures And Algorithms Concepts

Data structures and algorithms (DSA) are the bane of many software engineers' existence. They are a hard requirement in FAANG interviews, particularly Meta and Google. This course will teach you how to master this incredibly complex and frustrating topic.

[Course] Master The Data Structures And Algorithms Interview

Becoming a software engineer is one of the most impactful and attainable paths to boost your income. While it's definitely possible to do this career switch without a 4-year degree, doing so is incredibly difficult. Use this course to guide your journey.

[Course] Break Into Tech And Become A Software Engineer

As a manager, your impact is entirely dependent on the talent you hire. If you're looking to build an incredible engineering team, this course is for you. If you're an engineer looking to join an incredible team, you can now understand the other side of the table.

[Course] How Engineering Managers Hire Great Engineers

Congratulations on becoming a software engineer! The next step for you: Figure out how to evolve past the helpless "junior" label. This course will teach you how to do that fast.

[Course] Grow From Junior To Mid-Level Engineer: L3 To L4

System design is a critical engineering skill, which is why it's a huge part of the software engineer interview, especially at FAANG. However, the open-ended nature of system design leads to a lot of engineers struggling immensely with these rounds. Never again.

[Course] The Top Ways People Fail System Design Interviews

The most important language for software engineers isn't Python, JavaScript, C++ or any other programming language: It's English. Follow the principles in this course to ensure that you always get your point across while building up relationships.

[Course] Clear Communication For Software Engineers

What does it take to be a tech lead? Join Google Staff Engineer [L6] Lalit Kundu as he breaks down how you can grow into tech leadership.

[Course] Tech Lead Blueprint: Role, Skills, and Strategies

Staff Engineers (L6) are critical members of their teams, which is why they're paid extremely well with FAANG L6s being paid $500,000+ in the US. But how do you make the jump from Senior to Staff?

[Course] Grow From Senior To Staff Engineer: L5 To L6

In order to grow quickly as a software engineer, you need to learn a lot from others. This process will go 10x faster if you ask high-quality questions instead of low-quality ones: Go through this course to learn how to do just that.

[Course] Ask Great Questions That Get Great Answers Quickly

As a software engineer, you need to get a lot done with a relatively small amount of time, especially if you work at a high-performing tech company like FAANG. This course covers tactics you can use to move faster and prevent yourself from wasting time.

[Course] Maximize Your Productivity As A Software Engineer

There's much more to being an effective tech lead than telling people what to do. In this course, Jocelin Ho walks through what it takes, drawing on her rich experience as a Meta tech lead and as the CTO of Cooby (a Sequoia-backed startup).

[Course] How To Be An Effective Tech Lead

Having a high-quality, polished resume is the 1st step towards a successful job search. As a software engineer, you need to be incredibly precise with how you present yourself and avoid the many traps that make tech resumes suck.

[Course] Get More Interviews: Write A Stellar Resume As A Software Engineer

Every engineer wants to become senior someday, but this promotion is notoriously difficult, especially at FAANG. Learn what it takes to quickly become a high-performing senior engineer.

[Course] Grow From Mid-Level To Senior Engineer: L4 To L5

Data structures and algorithms (DSA) interviews are the most notorious in tech, leading to millions of engineers over-grinding LeetCode. In reality, behavioral interviews are the most important interview type, and most engineers unfortunately suck at them.

[Course] Master The Behavioral Interview As A Software Engineer

PIPs are a cruel mechanism that tech companies use to force out low-performing engineers. Here's how to avoid them and think about your next steps if you are put on one.

[Course] The Ultimate Performance Improvement Plan (PIP) Guide

Promotion is incredibly important and acts as the foundation for your career at top engineering levels. This course will cover how you can master the promotion process by leveraging the tactics Alex taught to grow his mentees to high-performing TLs with $500k+ TC by their mid-20s.

[Course] Nail Your Promotion As A Software Engineer

"Designing Data Intensive Applications" by Martin Kleppmann is one of the most famous system design books out there. Whether you're preparing for interviews or just want to get a better understanding of data (crucial for Big Tech), check out these recordings where we discuss the book in-depth.

Taro Book Club: Designing Data Intensive Applications

The software engineer interview grind is almost always far harder than people realize, and the existing resources to help don't do nearly enough, focusing far too much on DSA and LeetCode. This course solves that by going into the far more important "meta" parts of a job search like the overall structure and mentality.

[Course] Ace Your Tech Interview And Get A Job As A Software Engineer

With the meteoric rise of ChatGPT, ML and AI are on software engineers' minds more than even before. How can we leverage AI to boost our workflow? Is it worth it pivoting to MLE? Use the resources here to find out.

[Taro Top 10] Machine Learning And Artificial Intelligence (AI)

This is the kind of advice that should be viewed by every engineer ever but currently isn't.

Underrated Engineering Discussions

With the infinite amount of tutorials and infrastructure services out there, writing code is easier than ever before. If you want to stand out as a software engineer, you need to write much better code than almost everyone else. You need high code quality.

[Course] Level Up Your Code Quality As A Software Engineer

The absolute first step in a successful job search is to write a stellar, concise resume. Despite this, so many engineers fail to do the incredibly high-leverage act of resume optimization, making several basic mistakes.

[Taro Top 10] How To Write A Better Engineering Resume To Get More Jobs

It doesn't matter how skilled and talented you are as a software engineer if the team around you is fundamentally unsupportive. In order to have a successful career, you need to join organizations that foster your growth.

[Taro Top 10] How To Find A Good Engineering Team And Company

As a software engineer, you will quickly realize that you can't do it all alone, especially at senior/staff levels and beyond. In order to continue growing, you need to learn to mentor others and delegate.

[Taro Top 10] Effective Mentorship And Growing Others

Your engineering manager (EM) is easily the most important figure in your professional life, and how you manage your engineer <-> EM relationships will largely dictate how much career growth you have.

[Masterclass] How To Work Better With Your Engineering Manager

A lot of software engineers get obsessed with learning new technologies, constantly distracted by shiny object syndrome. What the rockstar engineers realize is that learning how to learn is much higher leverage.

[Masterclass] How To Learn Quickly In Tech

As you become more senior as a software engineer, reviewing code becomes far more important than writing it. It's crucial for you to learn how to leave salient feedback on others' code, even when they're working on a codebase you have never touched.

[Masterclass] How To Do Amazing Code Review

Here's the harsh reality: If you are a software engineer, you will almost certainly get laid off at least once in your career, no matter how brilliant you are. However, there are steps you can take to recover from them more rapidly than others.

[Masterclass] How To Survive Tech Industry Layoffs

FAANG - It's where seemingly all software engineers aspire to be. But is it actually worth it? Go through this playlist to find out both the real pros and cons of working at these prestigious behemoths.

[Masterclass] Should You Work At FAANG? - What Big Tech Is Like For Software Engineers

Your career lives or dies on the quality of your professional network. Whether it's finding a job or getting promoted, you always need a large bench of people willing to go to bat for you.

[Masterclass] How To Build Deep Relationships Quickly In Tech

Promotion, not job switching, is the true foundation for any software engineering career. However, you don't get promoted by just doing good work and hoping for the best - You have to be much more deliberate about it.

[Masterclass] How To Get Promoted Faster In Tech

The 1 on 1 meeting is one of the important mechanisms within the workplace, especially in the fast-moving tech industry. How you leverage this time will make or break your career, especially when it's with your engineering manager.

[Masterclass] How To Have Impactful 1 on 1 Meetings

The absolute 1st step towards a successful job search is to have an effective, polished resume. Despite this, so many engineers mess this up, missing a lot of low-hanging fruit to improve their resumes.

[Masterclass] How To Write A Stellar Tech Resume That Gets You More Job Opportunities

As a software engineer, you are going to work across many, many different teams and companies across your career. This means that it's vital for you to get good at onboarding, so you can hit the ground running at any new job.

[Masterclass] How To Succeed At A New Team Or Company As A Software Engineer

Money. It's what makes the world go round, and it's especially true for the tech industry. Software engineers are paid more than 95% of the population, but tech compensation is... complicated to say the least. There's far more to it than base salary.

[Masterclass] Understanding And Optimizing Your Pay In Tech

We all have the same 24 hours in a day, from the new grad engineer to the veteran principal engineer. 1 common theme that separates the rockstar engineers from the rest is that they're able to get far more done (up to 100x more) from those 1440 daily minutes.

[Masterclass] How To Manage Your Time Optimally In Tech And Achieve More Results

It doesn't matter how talented you are as a software engineer: If you don't have a good engineering manager supporting you, your career growth is dead in the water.

[Masterclass] What Software Engineers Should Look For In Their Engineering Manager

Data structures and algorithms (otherwise known as "DSA") are an infamous part of SWE interviews, especially those of Big Tech companies. They're agonizing, but they can truly be mastered by anybody.

[Masterclass] How To Ace Your Big Tech Interview - Data Structures And Algorithms

As software engineers, we all start off writing code. However, a mindset shift is needed as we become more senior: We need to review more code than we write to positively influence others' technical direction.

[Taro Top 10] Code Review

It doesn't matter how talented you are as an engineer: When a talented developer is pitted against a crappy team, the crappy team wins 99.9% of the team. In order to grow in your career, you must find a supportive team first.

[Masterclass] How To Choose A Good Company And Team As A Software Engineer

As a software engineer, you are more than just your code. As the person bringing the product to life, you are uniquely positioned to have a strong influence on its direction. In fact, it's extremely important for very senior engineers to get to know their PM and develop strong product intuition.

[Taro Top 10] Product Management For Engineers

No matter what, there will always be bugs. As a software engineer, it's crucial for you to master this often underrated skill.

[Taro Top 10] Debugging

Engineers are surprisingly terrible at taking care of themselves. Never forget: A healthy personal life is the foundation for a successful career, not the other way around.

[Taro Top 10] Work-Life Balance

This is one of most important interview rounds, especially for engineers targeting more senior levels. However, so many engineers struggle in these interviews due to poor communication skills.

[Taro Top 10] Behavioral Interviews

If I told you that you can make $10,000+ just sending a couple emails, would you do it? Definitely yes right? This is why you should always negotiate your offers. Use this collection to learn how you can navigate these awkward, high-intensity conversations to get the pay you deserve.

[Taro Top 10] Pay Negotiation

We're in the middle of the "Content Renaissance" when it comes to engineering content. More and more engineers are building large audiences across platforms like YouTube, LinkedIn, Substack, and more. Learn how you can build your own voice online and how it helps your career.