I put a bunch of thoughts here: [**Understanding a new code-base**.](https://www.jointaro.com/question/xA7BSngEuCfOnlhtVd26/understanding-a-new-code-base/)

(interestingly, this is also one of my [most viewed Twitter threads](https://twitter.com/rpandey1234/status/1457522650633232384))

A course on this topic is a great idea, it'd probably have appeal for many people (SWE interns, people new to Big Tech, etc). 

Tech Lead/Manager at Meta, Pinterest, Kosei

Rahul Pandey

The math around landing a Big Tech job is that you can likely increase your comp by $50K or more. If you feel programs/mock interviews like this will meaningfully increase your chances, it's worth it.

But if you're in doubt, you can try cheaper sources (or free mock interviews with friends) to see how much worse the interview quality is. Then make a decision based on the delta.

That strategy seems reasonable to me. I'd **also** focus on segmenting the problems into category, e.g. graph problems, linked lists, arrays, strings, etc. 

There are really only a few categories of DSA problems, so you want to make sure you have coverage across them. 

The best way to get more involved is to **add value**. If you can do that consistently, everyone on the team, including your lead, will want to include you in meetings and decisions. 

How can you add value? One good way of doing this if you don't already have the access to meetings is to look at the "exhaust" of the project work: 

- Look at meeting notes and propose an idea to make something faster or easier
- Look at the code output and make some (non-controversial) improvements or bug fixes

I also put some thoughts on finding new projects here: [How to find new projects to work on within the same company?](https://www.jointaro.com/question/1EGDn8x7BHkCJunVMUgF/how-to-find-new-projects-to-work-on-within-the-same-company/)

> it was the same things i did before but i got repeateadly said that expectations for a Technical Leader is going to be much higher than a Sr. SWE.

Promotions in Big Tech cos are **lagging**, meaning you should already be operating at the next level before you get the promotion. (I discuss this in the Senior to Staff course here: [Why Is The Staff Promotion So Hard?)](https://www.jointaro.com/course/grow-from-senior-to-staff-engineer-l5-to-l6/why-is-the-staff-promotion-so-hard/)

So it may not be the case that you have to change your output or behavior. You could be doing just fine!

A big company like Cisco will almost certainly have an evaluation rubric for each level. Can you look at that and judge your work according to that criteria? 

The other recommendation I have is to observe the behavior of other Technical Leaders in the company: [Talk & Observe](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/the-talk-and-observe-framework/). Following this will remove the anxiety you're dealing with about what exactly your role should be.

No, that's fairly rare. Assuming the level based on title is imperfect, though -- how confident are you that they're actually that senior? It might be some amount of title inflation, i.e. the person you think is E7 is E6 or E6 in reality.

You can bring this up with the recruiter, you can ask if it's possible to chat with people at a similar level to you, since their day-to-day will be more representative.

That's what these courses are for! 

- [Tech Lead Blueprint: Role, Skills, and Strategies](https://www.jointaro.com/course/tech-lead-blueprint-role-skills-and-strategies/)
- [How To Be An Effective Tech Lead](https://www.jointaro.com/course/how-to-be-an-effective-tech-lead/)

One thing to note is that your company seems much smaller, since you're the only mobile engineer. Most of the concepts will still apply, but you likely won't have as much process or examples to pull from compared to a TL from Google or Facebook.

> I want to give new engineers (probably all E4s) chances to lead tech design. To what extent should I be helping with the designs?

This really depends on the person. I would have a conversation with them about their level of ambition (and comfort) with leading a project, and how much involvement they want from you.

Since you're being asked to interview in C, you don't a choice to switch to a new language (this is rare, but does happen for interview loops on teams that only care about 1 language).

Spend some time sharpening your C muscles, but I have two thoughts that can hopefully relieve some of your stress:

- The types of problems you are expected to solve are likely to be different since the interviewer knows if something will be very cumbersome in C. Their goal is to maximize signal from the interview, so they shouldn't ask you to write something that has 30 min of boilerplate code.
- If there is something very tedious/slow, one smart strategy is to "invent the API", something like this:

> In Java, here's the syntax I'd use for the Hashset. I forget the exact syntax in C, but I'll assume some library exists for this so I can make progress on the core problem. If you'd like me to come back and flesh that portion out in more detail, let me know.

Alex talks about [Programming Language Selection](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/programming-language-selection/) in his course as well.

Lalit explains it very well in the intro to his course! [What's The Deal With Tech Leads?](https://www.jointaro.com/course/tech-lead-blueprint-role-skills-and-strategies/whats-the-deal-with-tech-leads/)

At FAANG cos, "**Tech Lead**" is not an official title. You could be an acting Tech Lead as an L4 (mid-level) or as an L6 (staff). You could also be a Staff Engineer and *not* be a Tech Lead if your impact comes from being a specialist/consultant. 

Tech leads typically don't manage people, but they do have some overlap with a people manager: <https://www.jointaro.com/course/how-to-be-an-effective-tech-lead/what-makes-a-good-tech-lead/>

We have a tactical DSA course that I'm very excited about coming to Taro soon! Order: 

- Warm-up questions, Big-O
- Arrays and Strings
- Recursion
- Linked Lists
- Binary Trees
- Graphs
- Dynamic Programming

In the meantime, go through Alex's exceptional course about the [study approach for Data Structures and Algorithms](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/)

My recommendation to make your job search much, much easier: **lead with value**. 

Become an expert in something (anything!) and share your knowledge. Offer to help people with something like React boilerplate, Node, or SEO.

Also, you get \~100 LinkedIn connection requests per week. Use them! (and add personalized notes to make clear that you're not selling anything). 

Two standups/day is rough 😳 I wonder if that can be reduced to just once/day if you explain the situation to your manager?

It's not uncommon that work doesn't happen in the office. Crazy, I know! Our offices (and workdays generally) are filled with distractions that split our time and attention into tiny chunks so we can't get anything done.

While you have 2 standups/day, you can still explain honestly what you did during the day: I'm guessing a lot of it is attending meetings, ad-hoc conversations, replying to pings, etc. If you notice this as a trend among people in the standup, that gives you more credibility to make a change.

BTW, I made a YouTube video about standups that I'd recommend going through: <https://youtu.be/NmoNIkF6xOA>

Recruiters are extremely high variance: some of them are a net negative to the company, while others are so effective at building relationships that they can attract amazing candidates simply through the trust they've built up over the years.

You're dealing with the first category of recruiter, which is unpleasant. But the recruiter being transactional/low-quality doesn't necessarily mean the actual company is low-quality. I would continue interviewing, but set clear boundaries on what you can commit to. I'll provide a few examples:

> She gave me a weekend to decide whether to accept the offer or not.

When something feels rushed/unfair, the best response you can have is curiosity. Ask questions about why you're only given the weekend. Something like this:

> I'm curious what the urgency is to decide this weekend? I spent the past 2 weeks getting to know the team. This is a big decision for me so I'd need at least a week to ensure I can fully commit.

Use a similar strategy for meeting the boss. That does seem like a red flag, it's totally natural for you to speak with the hiring manager before joining.

> She insisted i meet with my potential boss at the office and do so only if i am 100% sure of accepting the offer.

You could say something like:

> The manager plays a huge role in my day-to-day life at the company, so I want to ensure it's a mutually good fit. My goal is to understand the working style of the manager so we can prevent any misunderstanding -- how would you recommend doing that?

The strategy here is to **be curious instead of combative**. If you end up joining the company, you'll have a multi-year relationship with them, so it's in your best interest to keep things positive.

The other strategy which I tried to showcase above is to frame things in terms of benefit for the company. Obviously, having more time benefits you as the candidate, but it's your job to explain why that **also** helps the company. e.g. this will ensure you're even more committed to the long-term and will help you perform better.

It's impressive to interview at the Staff L6 at Google given how aggressively they downlevel! I've interviewed at Google several times (not for Staff though). Here's what I learned from my experience and what I've heard from others: 

- As you interview for higher level positions, there's more emphasis on system design and your prior work. System design in particular is often used for leveling. Go through this: [What is the difference between a Senior and Staff engineer in a System Design Interview?](https://www.jointaro.com/question/5TaZMBhgxvdsKMoQ7qWi/what-is-the-difference-between-a-senior-and-staff-engineer-in-a-system-design-interview/)
- You should still expect coding, but you may find the bar to be slightly lower than for an L3/L4 position. 
- There will be at least one behavioral round (watch this course: [Master The Behavioral Interview As A Software Engineer](https://www.jointaro.com/course/master-the-behavioral-interview-as-a-software-engineer/))

Yep, this has been a great initiative among Taro members who simply create the events (2 weeks+ out) at <https://www.jointaro.com/events/create/>

This is extremely valuable for the community and also has some additional benefits for the organizer: 

- If you are teaching anything, you'll learn that concept much more deeply. 
- You'll build a name/brand among Taro which will help you with referrals (I've personally done this for others who have put on a series of events).
- You can include your Taro referral link in the description (<https://www.jointaro.com/rewards/>) to potentially earn money for people joining.
- You'll get many messages of thanks!

Alex and I will do our best to support you by broadcasting the event and sharing feedback if you'd like. My recommendation would be to schedule at least 3 events so people can understand it's a series. 

One of the people who organized the DSA/system design study groups was [Danny E](https://www.linkedin.com/in/danny-esaid/). 

Great question! I have two tactical thoughts: 

- You're not saying "*no*", you're saying "*not right now.*"
- It's always better to phrase a decision like this as "*I am excited about where I'm headed*" instead of "*I didn't like a certain attribute of your company.*"

It's actually quite common for the recruiter or hiring manager relationship to continue after an offer rejection, so you should absolutely take the time to circle back and be gracious in your decision.

Start by saying thank you for all their help. Then focus on things that are unchangeable about the company, e.g. size, type of work, a specific person you are able to work with at the other company. 

If it's a compensation issue, take a look at [How do I reject an offer politely because the compensation is too low?](https://www.jointaro.com/question/9r7WVDsLKQZkMUuXjnBk/how-do-i-reject-an-offer-politely-because-the-compensation-is-too-low/)

hi Vicente, I'd post here: <https://www.jointaro.com/question/HdNE8698uWYnwJtAYMN2/i-will-review-your-resume-for-free/>

One quick thought from me, instead of calling yourself "Software Engineer, Working Student" can you just call yourself "Software Engineer"? This will legitimize your work experience, and it feels genuinely true if you were working close to full time. 

For your projects, can you share any numbers? Number of users, API requests, pageviews, etc. 

The sentiment on this reddit thread seems quite negative about India :/ <https://www.reddit.com/r/developersIndia/comments/18nfuxp/moving_back_to_india/>

I put some thoughts on things like economics, infrastructure, environment here: [Choosing location over career and money](https://www.jointaro.com/question/QTIL6abVDz5GeJWwpawj/choosing-location-over-career-and-money/)

(I've never lived/worked in India, though, so my opinions are based off talking to others!)

When do you finish your part-time masters at Georgia Tech? **Doing the masters, working full-time, and doing interview prep is too much**. For the next round of interviews, I'd strongly recommend that you compartmentalize, perhaps taking a semester off from the program.

I think the best bet is to (1) solve all the questions tagged with Meta on Leetcode, and (2) do some mock interviews. It's hard to create shortcuts for interview prep, unfortunately. 

I also don't recommend applying for just one company: instead, apply for many so you can do 5+ interviews in a short period. You'll find that you naturally get significantly better between the first and last interview. 

This Meta seems opportunistic, so it's great to pursue it, but I'd calibrate your expectations (sounds like you're doing this)

You mentioned "moved back to India from the UK for personal and family reasons" -- are those reasons still an important part of your life? 

What are the likely *next* jobs if you take the UK jobs? It sounds like you're viewing that as more of a stepping stone, so I'd research what the people who used to work there are doing now.

I really like Shine's answers to think about the future for your kids? Do you think they'll have more success in India or the UK? I'm not sure the answer to this question, to be clear, but there are various dimensions to think about:

- **Economic opportunity**: not clear which is better. The US is probably the best in the world here.
- **Family/friend connection**: I'm guessing India is much better here
- **Infrastructure**: Probably better in the UK? (I'm thinking about things like traffic.)
- **Environment/pollution**: obviously the UK is much better here.

Unfortunately, if a workplace is toxic, it usually stays that way. It's rare for one person to leave, or for a management change to fix all the problems. I would not pin your hopes on some simple change allowing you to thrive if the culture is broken across the whole company.

So my advice is to be clear about: 

1. What are you trying to learn? 
2. What is the exit criteria? 

You have a great person to learn from in the senior 10x engineer on your team. I'd figure out what exactly they're exceptional at and try to collaborate closely with them.

The exit criteria is important because it helps you establish what you're sticking around for. Your long-term career will suffer if you get burned out. So figure out a promotion, learning, project launch, or management experience that you're looking for, and work methodically toward that. 

I also really like Alex's answer here about finding a "Secret Manager": [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)

Alex can share his opinion when he's back from his Japan trip, but I think the answer here will depend on the signals you're getting from the interviewer. 

As Sophie mentions in our [discussion about system design](https://youtu.be/i2lgRWLKT00?si=xFDq84JTYv7cKfqz&t=647) (but is still applicable to DSA problems), a really smart technique is to propose what you're about to do and then ask "*How does that sound?*" at the end. 

This gives the interviewer the option to interject if they feel like you're spending too much time on edge cases or too much time on the happy path.

I agree with you that option 2 is probably better if you are strapped for time. The max signal the interviewer can get from you is if you actually start writing code (option 2), not just discuss all the approaches.

The first thing I'd do in this scenario at Meta (or any company with high-caliber people) is just to **observe others**. Find other Senior/Staff engineers on the team and figure out how they decompose problems and delegate tasks. 

There's usually some sort of team sync where people talk about the work they plan on doing in the next few days or weeks. This will likely be a critical meeting where you should come prepared with ideas of:

- What major work items have to get done, and what is a reasonable decomposition of the work?
- What skills are required to get those tasks done, and who on the team has those skills?

For the acceptance criteria, the question I'd ask is: 

> How can I make it **unambiguously** clear to anyone relying on this work that is has been completed adequately?

What are the likely questions they'll ask, or what resources/test cases will they ask for? Embed that in the work description, and ask the engineer doing the work to include links in the deliverable.

Here's the opposite of the question you're asking, where an engineer feels like they were given something far too vague. Use this to understand what NOT to do: [What can I ask to break down vague requirements?](https://www.jointaro.com/question/AYt6751mE1rw4jblzHSw/what-can-i-ask-to-break-down-vague-requirements/)

> do you expect the trend of reduction in software salaries continuing over the long-term?

I think there will be an **increasing** demand for software engineers in the next 5-10 years, but the roles and expectations will change as we learn how to properly use AI. There is a very, very large appetite for software in the world, so we'll finally see "[software eating the world.](https://a16z.com/why-software-is-eating-the-world/)"

- There will be more emphasis on the intersection of software and knowledge of another domain, e.g. genomics and software.
- There will be more emphasis on understanding customer requirements and working with other functions in the company to create effective solutions. 

Also, I expect the salaries to go up. 

I made a video about using AI here which might be interesting! [A Framework For Integrating AI Into Your Workflow](https://www.jointaro.com/lesson/I3CvgoyGGJdZpDSDLc69/a-framework-for-integrating-ai-into-your-workflow/)

I don't think it's true that every other team in big tech is shrinking. **Most** of the jobs from [joinTaro.com/jobs/](http://joinTaro.com/jobs/) are non-AI roles. Just a few random ones I found: 

- [Software Developer III, Mobile (iOS), Chrome at Google](https://www.jointaro.com/jobs/google/software-developer-iii-mobile-ios-chrome-7e8b6f75/)
- [Software Engineer, Product at Meta](https://www.jointaro.com/jobs/meta/software-engineer-product/)
- [Security Operations Engineer at Microsoft](https://www.jointaro.com/jobs/microsoft/security-operations-engineer/)

\`The narrative around AI tools making companies stop hiring is more of an *anticipated* impact rather than something widespread today.

Long term, I think there will be an increasing divide between the haves and have-nots -- some companies will thrive with more profit and more work to do in the age of AI. Others will see their revenues decrease. My advice: make sure you work for the former kind of company 😇

How are you defining top-tier job, and what exactly do you mean by "facing a lot of difficulties in getting through"? The **stair-step approach** to progress is usually far more successful than hoping for immediate success, so in general you should take the best option available to you. 

This also depends on your background. If you're running low on finances and getting frustrated with the job search, then take the best opportunity available to you and then re-evaluate your options in a year.

Careers are long: there are many, many examples of people who have grinded through "bad" companies or jobs on their way to something amazing.

If there are particular companies you want to get into, my classic advice is to use your unfair advantage: figure out your unique skill, network, or passion that will give you easier access to companies. Then, use that to get strong referrals.

Alex talks about how to get out of the job search struggle here: [Struggling? Send More Applications](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/struggling-send-more-applications/)

The abridged version (I hope to make a course on pitching/fundraising soon!)

- We raised entirely on SAFE notes with a set valuation cap. No discounts, super pro-rata, or other terms. It took some back-and-forth to determine a reasonable valuation cap and how much we were trying to raise.
  - The guidance from YC was to raise enough capital for \~3 years of operations, so you can safely hit the next company milestone (profitability or another round of funding).
- The whole process took \~4 months end to end, from August - November 2022. But the bulk of it was done in &lt; 2 months. 
- \~123 investors in our database. Majority were angels, some institutions.
- Average of 30 min for the first meeting, and usually people committed after 1-2 calls.
- Some VCs really dragged their feet and kept asking for more meetings and more information. The best VCs were able to commit after a single meeting and then wire money shortly after. 

Developing a game seem like solid experience, especially if you've published it somewhere. But you need to make sure you have a narrative around it where you explain what was interesting/difficult about it, and why it was valuable. If you're not applying to game companies, you need to figure out the transferable skills you gained.

I'd also go through the resume course: [Get More Interviews: Write A Stellar Resume As A Software Engineer](https://www.jointaro.com/course/get-more-interviews-write-a-stellar-resume-as-a-software-engineer/)

I think this depends on the startup you're aiming to join, specifically along two dimensions: 

1. Does the startup have product-market fit (PMF)? 
2. What is the startup selling? 

As I talk about in [this question](https://www.jointaro.com/question/Li0rePpbDHLHxmzDyZk6/is-it-a-good-strategy-for-a-single-product-to-be-a-multi-product-company/), startups are bifurcated into **pre-PMF** and **post-PMF**. If the startup is pre-PMF, you should probably expect to be more generalist since the company will have to try a few products or customers to figure out what actually works.

The other dimension is about what the startup is selling. If you're a startup selling a technology, e.g. a database solution, you should expect that the specialist skillset is most valuable. But if you're building a consumer product, for example, the generalist skillset will likely be more valuable. 

Also related, checkout this great discussion about [How to evaluate a startup](https://www.jointaro.com/question/UCG4XxyEOTjjyg4pEuwY/how-to-evaluate-a-startup/).

James Hawkins, founder of Posthog (which is undergoing hypergrowth right now), shared his perspective here: [The Really Important Job Interview Questions Engineers Should Ask (But Don't)](https://www.jointaro.com/lesson/IXikulqVz4SJHqk72a04/the-really-important-job-interview-questions-engineers-should-ask-but-dont/)

My Staff Eng archetype was most closely aligned to **Product Hybrid** (or perhaps parts of  Generalist). I took advantage of the fact that the org I was (Portal at Meta) in didn't have very strong product/strategic thinking. So I could drive product changes around things like user error messages, alignment with the Messenger calling infra, etc. (see the [case study for a tool I built here](https://www.jointaro.com/lesson/qvp2quodqAEWSkN7sayt/case-study-building-a-meta-internal-tool-to-empower-an-entire-org-staff-promotion-story/))

You can definitely change your archetype, but it's difficult in practice since people come to rely on you in that way.

Have to share one of the most famous investing quotes of all time:

> It's not about timing the market, but about time in the market

Almost every time I tried to time the market, I ended up losing money 😅 I recommend just putting all your money in VTI or ITOT.

There are [two distinct phases](https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/organizing-your-job-search/) of getting a job: 

1. Get interviews
2. Pass interviews

Working on projects is in bucket #1, and DSA prep is in bucket #2. These are two very different activities, so my advice would be to **focus on the next step to make progress**.

- Are you not getting any interviews now? Then focus on building projects or maybe even working for free on a project or for a low salary at a startup. 
- Are you getting interviews at companies you care about? Then spend the majority of your time on DSA prep.

> My understanding is that companies (FAANG and FAANG-adjacent) will recruit throughout the year

I've not found this to be true for new grad/intern roles, which is what I assume you're applying for. There are usually a fixed number of spots for early-career engineers, so once they're filled up, they'll close recruiting for that cycle. e.g. at Meta, I believe they fill up almost all new grad positions by January for the following summer. 

You're right that **job searching is emotionally exhausting and a big time sink**. How long is the verbal offer from Applied Intuition valid for? I am guessing only for a few weeks, in which case I'd recommend just finishing up one or two final interview loops and then making a decision.

Remember, a job is not permanent. Even if you feel like you didn't fully optimize your job search, you'll always be able to hop around after you join the company.

Also, I'm more bullish on Applied Intuition compared to the [sentiment in the linked thread](https://www.jointaro.com/question/gP9vEHKck57mD7I30CUd/how-is-applied-intuition-viewed-in-the-tech-world/). As autonomous vehicles become more prominent, the importance of Applied Intuition will increase. 

Great question! I talk about this in the "Learning The Codebase" section of [the onboarding course](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/how-to-not-learn-a-codebase/). My advice is to just dive in:

- Break things
- Add all the print statements ever
- Get the debugger working
- Run the code and see what happens

The key takeaway is that you should **get your hands on the keyboard** (even if it's uncomfortable).

You should also realize that in a large codebase, the code will follow the Pareto Principle (the 80/20 rule): 20% of the components account for 80% of the impact. So your goal as the engineer is to spend most of your time on the 20% of code that matters to the business and matters to your coworkers. I talk about how to do that here: [Figuring Out What Matters In A Codebase](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/figuring-out-what-matters-in-a-codebase/)

A well-known Meta story is from [Michael Bolin](https://www.linkedin.com/in/michael-bolin-7632712/), who reached E9, one of the most senior engineers in the company. 

You can read his LinkedIn to see how he continuously invented frameworks that were then adopted by 100s or 1000s of engineers. Notably, I believe the project that got him to E7 was creating [Buck](https://buck.build/). Buck is a build tool used by most teams at Meta now, and has gained adoption at other companies like Uber as well. 

Alex put together a bunch of side project ideas in a repository here: <https://github.com/Gear61/Software-Project-Ideas>

(not sure how many of these would involve message queues though)

One comment is that I don't think side projects are the best, or at least most efficient way, to build system design skills. Relevant discussion: [How to leverage side projects as a Data Engineer?](https://www.jointaro.com/question/pUZqNtUIL411VPO2Cvep/how-to-leverage-side-projects-as-a-data-engineer/)

I don't view raising a Series A (or any further financing) as "success." 

Our goal is to reach an increasing number of engineers and create better careers -- additional capital can help with that, but I'd want a compelling story about our longer-term plans before that.

I'm totally fine with bootstrapping from here and just growing consistently. Not tied to a particular outcome.

I've actually found the introvert/extrovert divide a bit confusing. 

- I find myself getting energy after talking to certain types of people, but drained of energy from other types. 
- I thrive on social interaction in certain times of day, less so for others. 
- Certain activities (pickleball! or walks) are an enjoyable way for me to hang out with others, but others are not. 

So my pushback on your question is that you shouldn't accept that you are an introvert, and certainly you shouldn't accept that you have a bad personality. 

Instead, make your interaction with others conditional. **Figure out what types of people, times of day, and types of activity are more suitable for you**. Be bold in trying out new things to see what might resonate -- once you find a close group of people, you'll find the next set of people are much easier to adopt since you meet others through your existing network. 

"Passion" is overrated -- focus instead on things where you can add value. Where can you help the company, a teammate, or a customer? I find that is much less intellectual than constantly diagnosing if you like (and how much you like) a certain activity. 

The latter: *the issues in startups and big tech are fundamentally different.*

There are only two types of companies: those that have reached product-market fit (PMF) and those that haven't.

The way you should operate and hire is very, very different between PMF and non-PMF companies. Most startups don't have PMF (and will never get it), so it's foolish to apply the processes and tools of larger companies.

Don't wait until you're ready -- you never will be! 

I'd start a startup almost entirely based on when the timing works out with a compelling cofounder. [What are the most important skills to be a successful founder?](https://www.jointaro.com/question/fTuvHTfjBTdyR1xuDnVy/what-are-the-most-important-skills-to-learn-to-be-a-successful-founder/)

I think I waited a bit too long to start a startup, unfortunately. If I could do it over, I'd probably tell myself to start sooner.

I wonder if you could **make remote work a point of negotiation**? Unless by remote, do you only want jobs that are fully remote for the long-term? 

e.g. what if you treated this as a normal job search and got 3+ job offers, 2 from hybrid companies, and 1 from a mostly-remote job. If the companies really like you, they may be able to make exceptions or changes for you so you only come in 1 week a month, or 1 day a week. 

Or perhaps you could have a written agreement with the company that they let you be remote after a year, assuming you hit certain performance benchmarks. As a founder, this is what I'd be most comfortable with -- I would **not** want to hire someone who wanted full-time remote immediately.

My point is, there are many definitions of "remote" and perhaps you could figure out a solution that works for you and the employer. Almost everything in a job is negotiable.

Have you gone through the resources here: [How do you get a remote job?](https://www.jointaro.com/question/8JHAUPt7CbXSruGjPmGi/how-do-you-get-a-remote-job/)

If you hadn't worked at Google (or other Big Tech) before, I'd say it's a no-brainer to take the Google offer. But since you're a previous Googler, you don't get much marginal improvement in your resume or networking by going *back* to Google.

The other hesitation about Google is that they are slow to promote. Unless you get lucky or are very skilled, you should expect the L4 (mid-level) to L5 (senior) promotion to take at least 2-3 years, and perhaps longer depending on the team. So if rapid career growth is important to you, I'd lean against Google. 

How long have you been at your startup? 

It sounds like you're not in an immediate rush to leave (the main issue is your skip level manager). Given this, I'd recommend sticking around at your company but doing a thorough round of interviews with 5+ companies. **When you're interviewing, try to avoid just a single offer**. This makes it harder to do a fair comparison of your current job (which you often will have a negative bias toward) vs the new job (which will be sold based on potential). 

So in the next round, I'd focus on setting up interviews so you end up with at least 2 offers. I wonder also if you could ask Google to keep the offer valid for as long as possible so you could collect another offer.

I don't have a strong opinion here. If I were you, I'd just follow the recommendation provided in a well-regarded system design course or book. Start with ByteByteGo from Taro Perks: <https://www.jointaro.com/perks/>

Use this as a starting point, but adapt it to topics you feel more or less confident in. 

Is there any incentive for these execs to help you? e.g. if they're at the same company, they naturally have a motivation to answer your questions and mentor you, since it indirectly helps them. 

You need to find common ground: If they're just celebrity industry veterans, it'll be hard to get something tangible from them. 

One idea is to have a concrete idea or proposal for them. The first thought that comes to mind is an invitation that you could profile them for your blog, or invite them for a talk. You can use the event as a jumping off point for a 2nd interaction. 

Another approach is to offer something of value. Share an insight or project that they'd want to know more about. 

There are some great answers here: [How to network effectively in a tech event?](https://www.jointaro.com/question/wx6HewLcKbxNRfMBiAAI/how-to-network-effectively-in-a-tech-event/)

> How much can I delay the interview?

I'd ask the recruiter this question. For more senior roles, they usually have flexibility (companies like Meta are almost always hiring Senior+ roles). But for new grad, those slots might fill up, so you might need to interview ASAP. 

> How many hours should i dedicate per day to leetcode?

This depends a lot on how much prior prep you've done. There's also a point of diminishing returns, where you won't retain much beyond a certain amount of time (probably 4+ hours in a day). So the correct answer is between 1-4 hours per day, if you can balance that with school.

> What are the HIGHEST bang for buck activities I can do?

Do mock interviews, focusing on Meta interview questions. Go through the [Master The Data Structures And Algorithms Interview](https://www.jointaro.com/course/master-the-data-structures-and-algorithms-interview/) course.

We are planning to bring tactical DSA content on Taro as well, very soon! Hopefully by early November :) 

My other recommendation is to interview at several Big Tech cos along with Meta. The prep is largely overlapping across all of FAANG, so why wouldn't you squeeze more juice out of the lemon (the lemon being the hard work of your interview prep!)

That seems like too daunting a side project, and also quite ambiguous on what the user value is. If your goal is to go deep on infrastructure, can you focus on open source instead? My initial recommendation would be to look at [TinyBase](https://github.com/tinyplex/tinybase), an open source project from James Pearce (former Eng Director at Meta). 

You can likely contribute to TinyBase if you go through the course from James here: [Become An Open Source Master](https://www.jointaro.com/course/become-an-open-source-master/course-james-intro/).

First, wanted to call out that this is a great question to be concerned about as a Principal Engineer. Improving the team culture and dynamics is one of the highest-leverage things you can do, and you're probably in a position to make change happen given your level. 

I think 2x/week standup is reasonable, enough will have happened for people to share updates.

A few questions I'd ask: 

- How many people are in the standup? Can you split it up into smaller groups where there's more relevance to each other? 
- Can you educate people on why standup is important and how people should share updates to make it beneficial for themselves and others? I made a video about this here: <https://youtu.be/NmoNIkF6xOA>

The goal, as you state, is to "improve networking and knowledge sharing." Standups are one way of doing that, but there are other solutions you could explore: 

- Define new/additional goals that are more team-oriented (e.g. build time, revenue, something which is more unifying)
- Have weekly/bi-weekly knowledge-sharing sessions, where one person is chosen to present. 
- Invite senior leadership for regular meetings so the team feels involved and heard in planning and roadmaps. 

This is a very broad generalization, but: 

- Managers have an easier time getting promoted at senior levels, but their job becomes more reactive and service-oriented. 
- IC engineers have a harder time getting promoted, but can keep some level of autonomy and flexibility.

If your goal is to start a startup, the Big Tech managerial skills won't really help you. Your network will be important, and managers may have wider networks, but the actual management experience is unlikely to transfer over into a startup. 

There are 3 main benefits of [Y Combinator](https://www.ycombinator.com/):

- **Money**: $500K is enough runway for a small team to survive for at least a year or 2 and find time to achieve the next milestone.
- **Accountability**: you work very hard during YC since you are put into groups with other startup founders all sprinting toward their own goals. This is very motivating. The group partners also help here.
- **Credibility**: You can easily talk to other YC founders and others outside the ecosystem by mentioning YC. This also helps mitigate risk in B2B deals, since going through YC helps larger companies take you more seriously.

Yes, I think YC did unlock opportunities that we wouldn't have gotten otherwise. In addition to the above, there's also a very tangible benefit that you get bookface access to connect with other founders and lurk on the internal forum -- this is very valuable and fun. You also discounts on common services a startup may use, like Stripe, Algolia, or emails providers.

The motto of YC is "**build something people want.**" They do a good job helping you eliminate all the work that doesn't tie to that goal. We actually have quite a few YC founders in Taro now, I'd encourage you to connect with them! (e.g. [Darwin Lo](https://www.jointaro.com/p/darwin-lo/)). See the responses to: [What are the most important skills to learn to be a successful founder?](https://www.jointaro.com/question/fTuvHTfjBTdyR1xuDnVy/what-are-the-most-important-skills-to-learn-to-be-a-successful-founder/)

Some good thoughts from Alex here: "[How did you decide to quit your job and make a startup?](https://www.jointaro.com/lesson/beZzIkLUP28WinNQctlP/how-did-you-decide-to-quit-your-job-and-make-a-startup-9132022/)"

Not sticking with ML / AI as a Stanford grad in 2014 and switching into mobile. If I had gone deeper into Artificial Intelligence, I'm sure I could have met very interesting people and built something very cool. 

At the same time, I have no regrets about my career. I'm grateful for the people I've met and the projects I've been able to work on. And all things considered, I'm very lucky!

The early days were tough: we knew we wanted to help software engineers, but we didn't know how to turn it into a business. In the first few months of 2022, we struggled to answer basic questions:

- Would we charge consumers or businesses?
- Would we create tools (in the flow of work) or content?
- How can we convince investors that we could take VC funding? Is that the right move for us?

I remember we did user interviews through a platform called Tegus, where we spoke to various enterprise leaders at various companies, e.g. Head of Learning, or HR Lead, or a CTO. Access to these people was great, but we became increasingly frustrated because:

- We didn't know how to properly interview these folks to identify problems that were worth solving for them.
- Our misguided expectation was that we'd be able to get "design partnerships" or Letter of Intents (LOIs) from these conversations, but we were still very far from having that kind of trust with enterprises.

We got rejected by YC (and a few other accelerators) the first time we applied, but ended up getting in for the Summer 2022 batch. Don't assume that seniority in FAANG makes it easier to get into YC -- it helps, but you're still much more likely to be rejected. Y Combinator was really powerful in helping us ship a product that we finally started charging for.

The core Taro team is still quite small: 3 engineers in the Bay Area (me, Alex, and Charlie), and we have one contractor abroad to help with operations.

For a trip down memory lane, here's a video from the early days of Taro (Sep 2022): ["How did you decide to quit your job and make a startup?"](https://www.jointaro.com/lesson/beZzIkLUP28WinNQctlP/how-did-you-decide-to-quit-your-job-and-make-a-startup-9132022/)

Fundraising after YC was challenging: hundreds of calls across 3 months, starting in August, with many unique characters in the investing world. Also a lot of disappointment and frustration, but that's a story for another time 😇 Overall, I'm actually grateful for the investors and amount we raised, and also that we don't have to fundraise anymore.

In [Understanding Your Boss](https://www.jointaro.com/course/managing-up-build-effective-relationships-with-your-boss/understanding-your-boss/), Ethan mentions both Myers-Briggs and the Enneagram Test.

Can you link the specific video in the course where he mentions this? I can try to find out. 

At Meta, I did a personality/strengths-finder assessment and I believe we had used [Myers–Briggs Type Indicator](https://en.wikipedia.org/wiki/Myers%E2%80%93Briggs_Type_Indicator).

To be clear about the pay increase: that was a **compensation increase**, which is different from a **salary increase**. Here are rough numbers to demonstrate what I'm talking about:

- When I started at Meta (2017): salary of $170K, equity of $150K
- When I left Meta (2022): salary of $235K, equity of $500K

You can see that most of my comp (TC) increase came from the higher equity value after I had stayed with the company for 4+ years. It's rare for someone to earn that much just purely from salary. 

To answer your question directly: you shouldn't have to ask your manager for a salary increase. Most companies will do regular salary adjustments for inflation, cost-of-living, and performance. Usually these are annual, sometimes more frequently.

Meta was nice (and somewhat unique) in that salary changes and equity grants were formulaic based on your performance rating. Based on that, you'd get a multiplier on the baseline salary change or equity grant.

If you need to ask for a salary increase, you can justify it in a couple ways: 

- Discuss your performance history (even if it's not an EE rating, you can still talk about your valuable contributions)
- Reference data from the market, for similar jobs as what you're doing
- Ask what the typical timeline/calibration is for salary adjustments

I talk more about this here: [Negotiating Your Current Salary](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/negotiating-your-current-salary/).

For most young people who don't have lots of responsibility (and especially you, since you're debt-free and close to family), I'd recommend being "risk-on": that means opting for more equity instead of cash. 

This is actually incentive-aligned with startups, which are usually cash-poor. Also given that the company is Series D, hopefully the equity won't end up as completely worthless, even if it doesn't live up to the full hype.

Is the negotiation with the company now done? Given how much they want you, it's likely you could get more. In the negotiation course, I talk about a tactic called "[Closing the Deal](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/closing-the-deal/)" which you could use here: 

> I will sign the offer if you give me 1.3x more equity

First, I'd definitely go through the Taro course: [Get More Interviews: Write A Stellar Resume As A Software Engineer](https://www.jointaro.com/course/get-more-interviews-write-a-stellar-resume-as-a-software-engineer/)

We have some listed in the Taro Perks page: <https://www.jointaro.com/perks/> (CareerFlow). The other I'd recommend is <https://simplify.jobs/>. 

The work of the Eng Manager might be *invisible*, but still essential to have the team function. Or you could just have a bad manager 😅 

Let's start by talking about how a manager is evaluated. It's very simple: 

> The value of any manager is the combination of the output of her team and the output of her surrounding teams.

This is from [**High Output Management**](https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884) by Andy Grove, the de facto management book of Silicon Valley. 

From this, you can tell that the manager's job is to do anything that increases the output of their 'sphere of influence.' The manifestation of this will differ based on the needs of the team, but the common behaviors will include what you already called out:

- Improving the performance of existing team members (or firing them)
- Bringing in talented new team members
- Identifying and reducing inefficiencies that slow down the team
- Running performance reviews
- Motivating the team to achieve more

A few ideas for you: 

- Ask other people on the team about their interaction with the manager, and what value they've seen.
- Look at how your manager spends their time
- Ask your manager what is top of mind for them, and ask "*How can I help?*" This will reveal their biggest problems, or perhaps will reveal that they truly are not doing much. 

We talk about the role of EMs here: [What Does An Engineering Manager Actually Do?](https://www.jointaro.com/lesson/GuVGwyNdKoZyCeU9jgQm/what-does-an-engineering-manager-actually-do/)

There will be some expectation of an ML background, especially at the senior level. However, this doesn't need to come strictly from having that exact job/title at another company. 

Instead, could you talk about how you worked on ML-related concepts in your projects at Microsoft? Seems like you have plenty of that from building a large-scale model. 

You should also talk about the transferable skills you've acquired. It's unlikely you'll have worked on the exact tech stack that Meta or another FAANG company wants. But you can connect the dots

- e.g. "*I haven't worked directly with PyTorch, but I have lots of experience with a specific module in TensorFlow which would be applicable here.*"
- This is especially important for recruiters who may not be able to make that connection on their own.

The biggest thing that can help you would be a referral from someone senior or in the ML space (ideally both) at Meta. I think the specifics of your background are less important once you get the interview, especially for someone like you who has worked at a MSFT. I'd focus your efforts on getting into the interview loops you want. 

Yes, there is often a huge difference between **practical** system design (DDIA) vs **interview** system design (ByteByteGo) -- they can be quite different.

I would **not recommend** learning these architectures and microservice concepts. The reason is that they're hard to really engage with on your own -- they are, almost by definition, used in the context of a  large team or large company. 

So if you attempt to learn it on your own, it'll feel very theoretical and academic. I don't think this is a productive way to learn the material. Instead, focus on expertise as a builder, and explore architectures as needed when you hit certain milestones.

The most popular question on Taro about system design is from this Amazon engineer: [What are the best resources to learn system design in a structured way?](https://www.jointaro.com/question/SeCsb4IRTijs2hg4XHxo/what-are-the-best-resources-to-learn-system-design-in-a-structured-way/)

Fair, I definitely don't mean to say Austinites are lazy! I was just thinking of this tweet when I wrote this 😅 <https://twitter.com/ZacSolomon/status/1790455371649200447>

First thing I want to mention is that this doesn't need to be (shouldn't be) a once-a-quarter discussion. I'd recommend having a constant dialog with your manager about what challenges and opportunities are coming around the corner: next week, next month, and next quarter.

Ask a simple question: **What more could I be doing? Do you have any feedback with my existing work?** 

Some ideas:

- Offer to take on tasks that align with your desired career path. Something like "I've noticed that there's not as much product definition for feature X, and I've been interested in working closer with PMs, so I'll start creating some milestones for it."
- Learn to anticipate problems and solve them without needing direct permission. This builds up a lot of trust if you do this consistently.

Ethan Evans talks about this a lot in his recent course, [The Growth And Promotion Recipe - Magic Loop](https://www.jointaro.com/course/the-growth-and-promotion-recipe-magic-loop/)

Being in the Bay Area, you're in the center of tech and startups - take advantage of it! One quick note about Taro meetups is that you could plan your own! Just find a coffee shop and create am event from [joinTaro.com/events](http://joinTaro.com/events) at least 2-3 weeks out. We can help promote the event and get the word out.

A few event ideas come to mind: 

- SF Tech Week (happening now in SF): <https://www.tech-week.com/>
- Tech-specific meetups, e.g. AI demo nights, or meetups for specific technologies such as Kotlin or databases. I remember I went to voice apps back when I was into building Alexa/Google Assistant apps. 
- Company-specific meetups, e.g. Google or GitHub might host events for certain new initiatives they have.
- Find a smart friend and just go to the same event they are going to. You might find an interesting topic, and if not, you got to deepen your relationship with this person. 

I added some additional thoughts here: 

- [How important is location (such as Bay Area) for career growth?](https://www.jointaro.com/question/qr7CYn90juXzRj8S6ewT/how-important-is-location-such-as-bay-area-for-career-growth/)
- [How can I better network with other software engineers in the Bay Area?](https://www.jointaro.com/question/oSBxZ0fzZlj9CFeetXCd/how-can-i-better-network-with-other-software-engineers-in-the-bay-area/)

Location is very important. It will dictate who you meet and the culture you are immersed in.

I made a video about it here: [Why Location Is CRITICAL For High Performing Software Engineers](https://www.youtube.com/watch?v=aEf3brlRrQc)

As someone who has only lived in the Bay Area, I can't say what other tech hubs are like, but from what I've heard: 

- **Bay Area**: the undisputed world capital of technology. Smart people and a constant discussion of technology and ambition.
- **Seattle**: more Big Tech focused (Amazon, Microsoft), and will skew older with older technology
- **New York**: lot more diversity in types of jobs, e.g. tech, finance, food, entertainment. Plenty of VCs here as well, but the main currency of status is moeny/power.
- **Austin**: more sales focused, and people generally don't work as hard

It also depends on what you're trying to achieve in your career. I'd optimize for where the best opportunities and people are within your company.

To get more plugged into various meetings, see: [Any meetups you recommend around Bay Area?](https://www.jointaro.com/question/SJuuzjjgdpQvaBMcgWC7/any-meetups-you-recommend-around-bay-area/)

There are many inputs into the decision of how much equity to ask for. If you're joining a startup, you need to have conviction that the best days are ahead of the company, so the valuation should increase. But it's very, very hard to tell if the company will go up 2x, 10x, or 100x in value. 

The comparison with the equity value of Google/Meta **doesn't make sense to me**. Those are trillion-dollar companies where the stock is almost as good as cash. For startups, you should expect the latest VC-fundraising valuation is inflated, so simply doing the math of *your equity % \* company valuation* will lead to wonky results.

Instead, you should think about what is a reasonable terminal value of the company after a few years, when you've vested a lot of your equity. Take into account dilution, and then that becomes the rough value of your equity. For example, if the startup is worth $10M today, and you think it could exit for $100M in 4 years, then your 1% equity package would be worth $1MM. Actually, it'll probably be worth less since there will be dilution from future financing rounds. 

This is my recommendation for very early-stage companies. For later stage startups, like Stripe, Brex, or Chekr, you can start to look at things like revenue, margins, and growth rates.

I left some thoughts here as well: [What do you think is a fair amount of equity for a first developer of the team?](https://www.jointaro.com/question/fE6SxTmzpgIblTHXcdc4/what-do-you-think-is-a-fair-amount-of-equity-for-a-first-developer-of-the-team/?a=33j42scTLR8dXIyfkg4L)

I really want to make a course about all the stupid things I did in my own entrepreneurial journey! In the meantime, here are my reflections on the most important skills to be a successful founder:

1. **Evaluate and convince an amazing cofounder to work with you**. This is the most important point. Your startup idea might change (actually, it most likely will), but your cofounder and founding team are much harder to change. A strong working relationship with a complementary cofounder will make your life much happier, and you're much more likely to succeed.
   1. *Most startups die of suicide, not homicide*. Startups often end up killing themselves due to interpersonal conflict instead of something like competitive pressure. Your founding team is the best antidote to this.
   2. Put yourselves in positions to meet a good cofounder, ideally someone you've had a relationship with for a long time. Work on projects with them.
2. **Ship faster than you think is comfortable**. For most software, mistakes and imperfect design is totally fine. You need to unlearn the process that larger companies have. Taro member Darwin Lo has a great article about [90/10 thinking here](https://docs.google.com/document/d/1o573abAhA3w_ovBIhT6_Sm-Ofy-FIYWciYCNjFfxiw8/edit).
   1. Since you're still employed, you can practice this muscle by building side projects. [\[Masterclass\] How To Build And Grow Tech Products To 500k+ Users For Free](https://www.jointaro.com/lesson/OEuX0KMhcnNSTJ50Voee/masterclass-how-to-build-and-grow-tech-products-to-500k-users-for-free/)
3. **Start charging money for something earlier**. This is a true test of whether you're creating something of value.
4. **Be human, not corporate**. You have very few advantages in a startup. One of the main ones is that you can provide a personal touch to customers in a way that a large company with millions of customers could not. Instead of using corporate language on your website, you must lean into the fact that you crafted this product with love and that you're eager to help customers directly.

Some additional thoughts here:

- [What are some strategies of getting started with Entrepreneurship And Tech Startups?](https://www.jointaro.com/question/Kpb6NNSNwHgnhfXbXrzv/what-are-some-strategies-of-getting-started-with-entrepreneurship-and-tech-startups/)
- [How To Prepare To Leave Big Tech For A Startup](https://www.jointaro.com/lesson/muNQH8uZSviN8P60RaKS/how-to-prepare-to-leave-big-tech-for-a-startup/)

For most people, **I would not recommend "engineer influencer" as a goal in itself**. If you're in a Big Tech co and your primary goal is to climb the ladder to the Staff level, you definitely don't need to become a public influencer. You need to be known well around your organization, but that certainly does not require a large audience on LinkedIn or GitHub.

Unless your work naturally leads to you having an external presence (and [aligns with your strengths](https://www.jointaro.com/course/become-an-engineer-influencer/catering-to-your-strengths/)), I'd focus on your company work. Having an external brand becomes more important as you get to very senior levels (e.g. a Google or Intel fellow must be known across the industry), or if you're trying to get hired in at an executive level.

I'll also note that the activities you mentioned are very different platforms and content: 

- **GitHub** is usually the most closely linked to our day jobs as software engineers, since it's related to code. But it's quite hard to get discovered unless you're big on another platform. (Most of my [GH followers](https://github.com/rpandey1234) came from YouTube)
- **Blog posts** are a great option, but again, it's very hard to gain any kind of distribution. I'd write blog posts as a way to reflect on what you've learned, and the bonus is that you have a body of work that someone could go through. 
- **LinkedIn** is the easiest to get distribution on (see the [case study from Alex on getting 2M+ impressions per month](https://www.jointaro.com/lesson/tmSAAWJjLcLWqeGWOl4t/case-study-how-i-get-500000-linkedin-post-views-per-week/)), but it's also the least technical. LinkedIn has more-or-less become like any other social media, which means it has lots of frivolous content along with career content.

The negatives: 

- **Your coworkers may judge you**. Creating content is an odd choice, especially among a group of well-paid people (SWEs). Your coworkers may assume you're not serious about your job, or you're using the team/company for personal benefit.
- **It takes time**. This is valuable time that could be used to contribute more directly to the team or company goals.

The positives: 

- **You get tons of inbound opportunities**, sometimes from people who are very interesting and smart.
- **You get daily or weekly messages** about how something you've created (either a video or post) has helped someone. 

---

I really like Brian Jenney's perspective on the value of building in public and why your goal is not to get likes or engagement: [Why It's Better To Share](https://www.jointaro.com/course/break-into-tech-and-become-a-software-engineer/why-its-better-to-share/).

Wow, this is so nice of you, thanks Vicente! I'll share this in the Taro Premium Slack as well. 

If you're delivering what the client wants in terms of code quality, I don't see any ethical concern at all. What the client is paying for, and what they care most about, is **business value**. Good code and craftsmanship may be related to this, but are not ends in themselves.

I think you're assuming that clean code is the *right* way to develop software, which is not true. 

Often times, speed and feedback is by far the most important criteria. In these scenarios, developing hacky, spaghetti code may be the exactly philosophy. Unless you have a direct conversation with the client, I would not assume that these "shortcuts" are bad.

If there's a certain level of reliability or testing that is being promised to the client, and your manager is encouraging you to skip on that, that starts to be an ethical conflict.

[Negotiating your current salary](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/negotiating-your-current-salary/) is generally harder than negotiating compensation for a new job, since you have less leverage. 

- **Timing does matter**. Larger tech cos will have specified windows when they can make salary adjustments. You should determine when this window is for your company and time it appropriately. You can also ask your manager on how/when compensation changes are made.
- **Your performance at the company does matter**. Ideally, you need to be well-liked by your manager, performing well, and working in an area where you'd be hard to replace. If there's written documentation of this, and numerical data, you should present this when making your compensation increase request.

On the topic of interviewing and getting another offer, this could work, but it's also high risk. Do you know if anyone around you has successfully done this? Some companies like Meta have a policy to not match counter-offers for current employees, so this approach could backfire. Something like this could work as a middle-ground: 

> I have been enjoying the work and impact I'm having on this team, but a recruiter did reach out from company X, and they're offering significantly more salary. I do love this team, but compensation is also important to me

This is good because it frames you as someone who didn't actively try to leave, but your eyes were opened to the possibility of you being under-paid. 

Meta point: You have a lot of questions in one question 😅 Feel free to break it up into more concise questions to get better answers. You want to [make it easy for people to help you](https://www.jointaro.com/course/ask-great-questions-that-get-great-answers-quickly/). 

Another thought is if there is a joint collaboration opportunity on your current team for a project that deals with cloud or security. 

Perhaps you can borrow an idea or project from one of those teams and see how you could apply it onto your team.

At a big company, I'd imagine there's existing policy for this, right? I'd have two different conversations: 

- Ask your manager how they think you're doing. If you know the company is really happy with your work, it may educate how you approach the contract renewal conversation.
- Ask the manager/HR what the process is like to renew the contract. What data do they look at, and what indication can they give you about after 3 months?

What is your eventual goal with the project? 

- If it's for learning and your goal is to get a Big Tech job, I'd **pick native development** since that's what larger companies use (at least FAANG does)
- If your goal is shipping speed, I'd **pick React Native or Flutter**. To pick between them: 
  - Which one is more used in your local market? 
  - Which one will let you get help faster? 

Alex put a ton of thoughts here on the native vs cross-platform debate: [Android (Kotlin) vs. React Native](https://www.jointaro.com/question/KUeUaVRfcjrnjGDcFuZC/android-kotlin-vs-react-native/)

It's much, **much easier to build trust in person**. In a vacuum, I'd opt for that. However, it obviously takes more time and money to travel, so you need to judge the opportunity cost.

Check the commitment level from the other side before you meet them. This comes in two forms:

1. **How much decision-making power does the person have?** If they're a newly-hired recruiter at the company, the answer is not very much. Then it may not be worth your time. The analog to this in the startup fundraising world is when you're doing tons of meetings with VC analysts who never have the authority to actually write you a check. You need to talk to the partners to make progress.
2. **How deep will your engagement be with the counterparty?** If you're traveling for a 30 min coffee chat with the recruiter, it may not be worth it. If you're doing the final round interview with 5+ meetings, then you should absolutely travel to be there in-person.

In short, I'd say the Staff Engineer should atriculate **more opinions** in a System Design interview compared to a Senior Engineer. These should be evidence-backed judgment calls that are based on past experience or forecasting various problems.

I'd highly recommend going through this course: [The Top Ways People Fail System Design Interviews](https://www.jointaro.com/course/the-top-ways-people-fail-system-design-interviews/)

I don't think a polished profile with links to all your projects will be effective. Instead, I'd do targeted outreach to engage with startups. 

**Startups are always starved of attention**. Genuine outreach and curiosity about the product/mission of the startup will distinguish you from generic applicants.

The other difference between startups and Big Tech cos is that startups want people who can hit the ground running. They likely won't be able to invest in a formal training or onboarding program that you see at larger companies like Meta or Google. So if you could demonstrate how you can **immediately have value** to the company, you'll have a much higher chance of getting the interview. 

Herea are a few ways you can show this immediate value: 

- Familiarity with their tech stack (a demonstrated history with shipping using their programming languages or frameworks). 
  - This is especially valuable if the tech stack is something unique like Perl or OCaml
- Deep understanding of a problem space that the startup cares about, e.g. SEO or mobile performance
- Deep passion for the company's mission, with ideas or research that you can provide from your own experience (e.g. a former founder in the same domain)

Here's a great related discussion on finding interesting startups: [**How to find and connect with scrappy startups?**](https://www.jointaro.com/question/9jFuRj3UymeHsaKIzXia/how-to-find-and-connect-with-scrappy-startups/)

I also put some thoughts here: [Is corporate engineering a dead end?](https://www.jointaro.com/question/yXvZwIjENsx4R8MRXXB0/is-corporate-engineering-a-dead-end/)

I believe Enterprise Systems Engineer is the same as "Enterprise Engineer"? Can you confirm? This [reddit post](https://www.reddit.com/r/csMajors/comments/rw6woy/what_is_fbmeta_enterprise_engineer_position/) explains it well: 

> If you are an Enterprise Engineer, you spend time developing internal tools for FB employees. It can be a simple full stack website for employees to sign up for benefits, claim some benefits, or sth like that.

Enterprise Engineering is the "lite" version of Software Engineer in terms of being less technical: fewer production issues, far fewer users, and less gnarly technical challenges. As a result, **EE will get paid less and will be viewed as the "younger sibling" to a normal SWE job**. 

You'll also have less optionality in the Enterprise Engineering role, since there are fewer of those roles available, and you'd need to re-interview for Software Engineering. All else being equal, I'd definitely prefer the Infrastructure SWE role. 

In terms of exit opportunities, though, the EE role is a great option! If you have been trying to break into FAANG, this could be a great option. You will be a full-on Meta employee, develop your network, and you still can obfuscate whether you were an Enterprise Engineer or Software Engineer for your next job. 

Enterprise Engineering is also likely going to be better in terms of work-life balance.

It's a sign that you haven't been rejected! So that's good 😊

There are two dimensions to a reference check: 

- **How senior is this person?** (e.g. new grad vs VP)
- **How strong is the recommendation?** (e.g. "Best engineer I've ever worked with")

The references can be valuable if you have someone senior giving you a very strong referral. However, not having references is not a bad sign (e.g. Alex didn't have references coming into Meta).

For more discussion about references, see my answer at [Can you please suggest me any names from Meta to put as references?](https://www.jointaro.com/question/uDhzddaD1pxYaWcg1z2y/can-you-please-suggest-me-any-names-from-meta-to-put-as-references/)

Also some good discussion at: [Meta specific question for referrals](https://www.jointaro.com/question/QSKWSO0Js71BbJXma1oj/meta-specific-question-for-referrals/)

It's hard to do something in programming without asking for help, *especially* if you're doing it for the first time.

What I'd recommend which is perhaps not as daunting: after you get help, either from a person or AI tool, redo the whole feature without the help. Forcing yourself to do it again (just checkout a clean branch) will make sure your learning is a lot deeper. 

Looks like you're a Senior SWE already. I would worry less about an ambiguous, hypothetical future and instead make the most of the promising situation you're in. It's too hard for anyone to predict how exactly software engineering will change, and there's a good chance they're wrong. 

The best thing to do is view AI as a tool, and figure out how to plug it into your workflows. Be adaptable to the large number of changes that could happen.

- [How to AI-proof your career?](https://www.jointaro.com/question/3xg5SvXnyTQ0mhNLfbK1/how-to-ai-proof-your-career/)
- [How will advances in AI affect Software Engineering Careers in the near (or forseeable) future?](https://www.jointaro.com/question/iJpayIUPb3vo71fUFEAI/how-will-advances-in-ai-affect-software-engineering-careers-in-the-near-or-forseeable-future/)

Google is notorious for downleveling ([I received an L3 offer](https://youtu.be/FpBvQ-SPSDM?si=62MKPzTkjEba8FUF) with 3 years of experience at similar caliber companies)

If you don't have tier 1 Big Tech experience already, Google is great. It's going to unlock many career opportunities for you in the future. If the promo takes longer than you want (e.g. 2+ years), you can simply leave and you'll be considered L4 (mid-level) by every company you interview at.

With that said, Google promotions are also slower to come by :/ And unfortunately, a lot of this is outside your control: 

- Google culture promotes slowly, with a requirement to show projects landing
- Google (and most of FAANG) has limited scope since they're mature products. 
- You need to build relationships with peers to get promoted which will take time

With that said, your promo to L4 is less reliant on your team/org success, and more to do with completing your work on time with high quality. So that part is in your control!

What is the main takeaway you want when someone watches the video? I'd **much prefer** some engaging/memorable story instead of the list of 10 experiences. Can you pick 1-2 experiences and talk about the narrative behind them? Why you joined, and what you learned, how it shaped you? 

Even better is if you share a unique insight or exceptional story. BTW, this is what Y Combinator looks for in applicants. If a founder tells a story of how they were a record holder in some hobby, that is very powerful even if it's unrelated to their startup. 

Especially since your resume/LinkedIn will cover the list of experiences you've had, I'd double click on your story and motivations.

Is this your first job after graduation? Early in career, job hopping makes sense: 

- You can broaden your network, which will be valuable later
- You force yourself to learn a different tech stack and systems, which will give you valuable perspective as you become more senior
- You can almost always get a pay bump (and perhaps even a promo)

The other dimension is how credible/well-known your current company is. If you're already in a tier 1 tech co, there's less value. If you're in a slower-moving, older company, I think you should absolutely explore externally. Especially in your case since you've been at your current company for 2 years.

Finally, consider the time cost of interviewing. It sounds like you're already getting inbound interest from Meta + Google, so the main time investment on your end will be around interview prep. Given this, it makes sense to do the interview.

There's a similar question with different context that Alex and I replied to here: [Should I actively look for jobs or focus on promotion?](https://www.jointaro.com/question/jrU6ujHoZoVfr9ng4Gtt/should-i-actively-look-for-jobs-or-focus-on-promotion/)

Yes, most tech recruiters will have heard of the quant firms, and they'll recognize that these are competitive jobs to get. I think you can't go wrong with either path: hot tech co vs top quant firm. Honestly, a big factor in my decision-making would be location: 

- **Silicon Valley is the clear leader in terms of tech/startups**. So if you have a network or want to settle here long-term, I'd lean toward startups.
- **New York (and maybe Chicago) is the clear leader for finance**. So if you have a network and want to stay there long-term, I'd lean toward finance. 

I made a video about location here: [Why Location Is CRITICAL For High Performing Software Engineers](https://youtu.be/aEf3brlRrQc?si=sK0swAxzy98KcVEm)

And some good discussion here: [How important is location for software engineers?](https://www.jointaro.com/question/K35C2YRAXVZvj7t85ClU/how-important-is-location-for-software-engineers/)

Keep in mind that this is a "two-way door": you can switch from finance to tech (and vice versa)!

Some discussion about this on Reddit: <https://www.reddit.com/r/linkedin/comments/1bfffyg/does_turning_on_open_to_work_only_appear_for/>. Interesting idea of keeping it turned on always, so you don't have a decision to make.  

I've never turned it on since I feel like I get higher-quality jobs through my network. I have heard that some companies (mostly startups) have a slightly negative association with people who have the open to work label. But for larger tech cos, and esp for recruiters, I think it's totally fine! It gives recruiters an additional signal that you'd entertain a conversation about a company.

Interesting that your team is mostly non-engineers! 

- If you don't feel like you have anything to contribute (and you're not gaining anything), you absolutely should skip.
- On the flip side, since you're the only eng in the room, you have an opportunity to share unique insights. This is actually an expectation as you become more senior, so you could view this as a way to flex that muscle.

Mental health is the most important; if the Amazon jobs gives you more mental peace, take it. 

Main thing I'd say is to optimize for stability -- make a decision quickly and find stable ground. This will help with the mental health as well.

I like this advice from David Pan, VP of Eng: [Figuring Out The Best Company To Join As A Software Engineer](https://www.jointaro.com/lesson/Nqs0U6rt2qFyXKSZurTh/figuring-out-the-best-company-to-join-as-a-software-engineer/). Basically it boils down to "Follow The Talent You Know"

> Should I optimize for learning with an AI legend

This could work, but the main thing I'd want to know is how much interaction you'd have with the legend. Be careful of famous people doing startups, but not actually being very involved in them. 

Do you have a large brand-name on your resume already, or some credibility otherwise? Sounds like you do as a past founder and open source contributor. If you don't fee like you have the logos on your resume, I'd lean toward taking the Big Tech role.

> hold them accountable for some of the requirements?

The goal of these conversations should be to have a **two-way exchange of information (and respect)**. You shouldn't feel the need to hold the leadership team to the fire -- I don't think this will lead to a trusted relationship. 

I'd ask "why" questions about the prioritization of features and what tradeoffs are being made.

Some questions from Igor here: [What should I talk or ask about in a 1:1 with the director of my org?](https://www.jointaro.com/question/IfOMUBWDP5uhYHOxEDVS/what-should-i-talk-or-ask-about-in-a-11-with-the-director-of-my-org/)

1. What are the top priority issues in your Org I can help with?
2. Is there anything about my teams that you want to understand better?

I haven't written documentation for a localization project, but from your perspective: what is unique about documentation for this vs a "normal" project?

One helpful question to ask is about the intended audience: 

- An engineer reading the doc in the computer will want to know how to change the strings in the code and kickoff new jobs for the localization team.
- A PM will want to know about the progress of localization and any associated data. 
- Also consider the leadership team, eng managers, and localization experts.

Some helpful resources:

- [How can I write a great design doc?](https://www.jointaro.com/question/54ys7InWnBvHPf3GORbv/how-can-i-write-a-great-design-doc/)
- [How to write wiki type documents effectively?](https://www.jointaro.com/question/TlzJg7VnzL7bKOwOX5MJ/how-to-write-wiki-type-documents-effectively/)

hmm... I haven't spent much time thinking about my job disappearing due to outsourcing. When I reflect on why: 

1. The companies I joined historically haven't outsourced (Pinterest, Meta) 
2. I felt confident in my network + skills to find another opportunity if needed

In general, *growth solves all problems*. If you join a company focused on growth, e.g. pre-IPO companies like Stripe or OpenAI, the likelihood of you losing your job is minimal. (You might be assigned to different work, but you'll still have a job.)

I like the anon answer here about just ignoring the danger, which is similar to my answer above: [Strategies to Mitigate Outsourcing Risk for Software Engineers](https://www.jointaro.com/question/EQbCSLkCdywAIomWSuV4/strategies-to-mitigate-outsourcing-risk-for-software-engineers/)

Google is notorious for down-leveling people. I would wait to hear the offer and ask about comp + level. 

If you're not happy with it, you can use the fact that you were a Meta E5 (equivalent to Google L5) as a strong negotiation tactic. Google can move a lot on the equity component of their package, so I'd make a strong ask there. (I share a full example in [this YouTube video](https://youtu.be/rceUVaiXQgU))

How different of a role is the internal transfer? If it has a lot of overlap with your current role, you could phrase it as a logical extension of what you're doing now, a job which will let you become more valuable to the business.

You can use your previous 4 year tenure at the company (along with perf ratings or relationships) as additional credibility to support your move.

No, I don't think it's manipulative. 

But I think it's important to communicate and set expectations appropriately. Consider two ways of talking to a hiring manager: 

1. "I am incredibly excited about the work you're doing and I'm eager to join ASAP"
2. "I'm very early in my interviewing process and still trying to understand various roles"

If you say #1 but are actually just using the company for interview practice, that could sour a relationship. 

If you say #2, a good founder/hiring manager will have the attitude of "we are going to impress this candidate and they'll have a hard time turning down our offer." Give the company a chance to showcase themselves as you meet their team. 

Companies **get bought, not sold**. 

Is your concern that you're being taken advantage of since you're getting hired as a regular employee instead of getting acquired? This feels like wishful thinking: 

- Startup founders that get "acquired" often just end up being regular employees at the company. This is the most common exit for a startup is actually an acqui-hire. It's not clear that you'd get significant financial gain from a startup, but you take on much more risk.
- Even if you built something valuable, it may not be valuable on its own. It might require the scale and brand of a FAANGMULA company to increase its value.

> If my goal is to have my own company again someday, should I work somewhere else less related to my expertise (just need it to pay the bills for a few years before trying again)?

I'd do the opposite. Work somewhere very aligned with your expertise. (1) learn from the best people, and (2) build your credibility to make it easier to raise money in your next venture.

We talk a bit more about the common path to start a company here: [What are some strategies of getting started with Entrepreneurship And Tech Startups?](https://www.jointaro.com/question/Kpb6NNSNwHgnhfXbXrzv/what-are-some-strategies-of-getting-started-with-entrepreneurship-and-tech-startups/)

You should absolutely be proactive with interviews and command the timeline! This is the key to gaining leverage, as I discuss in the negotiation course: [Get Other Offers](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/get-other-offers/).

Alex's phrasing is great. You don't need to reveal exactly why you want to delay the interviews (vagueness is your friend). Use the time you ask for to line up other interviews and do more interview prep. 

If it's a company you really care about, you may want to ask the recruiter about open positions at the company in a few months, or to hop on a call now to learn more about the needs.

This session is for early entrepreneurs and *wantrepreneurs* (someone who wants to leave their full-time job and do a company).

Hear pitches from several engineers who are tinkering with various startup ideas. Hear the raw feedback that can make their pitch better, from Rahul and other Taro members.

In the last two decades, more money and attention have gone to early-stage startups. It's easier and cheaper than ever to start a startup, especially if you're an engineer!

Sample discussions:

- Get feedback on the clarity of your idea, along with the opportunity size. Do you want a VC-scale outcome, or a "lifestyle business"?
- Should you get pre-seed funding (generally $100K - $500K) from an accelerator?
- How and when should you launch your product?

Also happy to share honest thoughts and feedback on well-known accelerators: [**Y Combinator,** ](https://www.ycombinator.com/apply)[**PearX,** ](https://pear.vc/pearx-application/)[**TechStars**](https://www.techstars.com/accelerators)

What you get:

- Hear ideas from other ambitious engineers to make your own idea/pitch better.
- Taro (this platform!) is a [**YC-funded startup**](https://www.ycombinator.com/companies/taro) from S22. Rahul can share thoughts about how Taro got in and what he learned.
- Rahul has personally reviewed and recommended 10+ companies that have gotten funding and launched their product.

Relevant resources:

- [**How To Approach "Doing Your Own Thing" -- Startup Discussion And Feedback**](https://www.jointaro.com/lesson/S5qhc6tiEqKEI0pc5bLq/how-to-approach-doing-your-own-thing-startup-discussion-and-feedback/)
- [**\[Taro Top 10\] Entrepreneurship And Tech Startups**](https://www.jointaro.com/playlist/ArtlSzF17v7cad1K6TJG/)
- [**"How did you decide to quit your job and make a startup?"**](https://www.jointaro.com/lesson/beZzIkLUP28WinNQctlP/how-did-you-decide-to-quit-your-job-and-make-a-startup-9132022/) (by Alex)
- [**How To Prepare To Leave Big Tech For A Startup**](https://www.jointaro.com/lesson/muNQH8uZSviN8P60RaKS/how-to-prepare-to-leave-big-tech-for-a-startup/)
- [**Taro at YC's Demo Day (Summer 2022)**](https://www.jointaro.com/lesson/81ACDLKEO9SVX964S1Yx/taro-at-ycs-demo-day-summer-2022/)

This session will ***not*** be recorded. Group Office Hours are a communal way to get the personalized career advice you need.

[Office Hours] Starting A Startup - Idea Feedback And Sharing

The relationship you have with your manager is the most important one in your professional life. So why do so many tech workers **make obvious mistakes** when dealing with their manager?

In this session, Ethan will share strategies and tips to:

1. Build trust with your manager, even if you've had challenges in the past

2. Drive your professional development and earn investment

3. Navigate difficult conversations and manage up effectively.

[Ethan Evans](https://www.linkedin.com/in/ethanevansvp/) managed teams of 800+ while a Vice President (VP) at Amazon. Across 15 years, he grew from manager to Vice President, providing executive leadership for multiple $500M+ businesses. In that process, he's managed hundreds of people directly across dozens of changes in his own management chain.

Ethan is now a career development expert and teacher. Watch his courses on Taro:

1. [Managing Up: Build Effective Relationships With Your Boss](https://www.jointaro.com/course/managing-up-build-effective-relationships-with-your-boss/)

2. [The Growth And Promotion Recipe - Magic Loop](https://www.jointaro.com/course/the-growth-and-promotion-recipe-magic-loop/)

3. [Make The Most Of A Layoff: Maximize Your Severance Package](https://www.jointaro.com/course/maximizing-a-severance-package/)

Learn more: 

- Watch the [interview series with Ethan about eng management on YouTube](https://www.youtube.com/watch?v=V8McoEVUiYQ&list=PLMrAfqhZjqfIkD-0p0tJ_zqvPnBdYsixT&index=4).
- Ethan's live cohort-based course "Stuck at Senior Manager" is open for enrollment now: <https://maven.com/ethan-evans/break-through-to-executive>
- Taro members get a discount to join [Ethan's Level Up community](https://levelupwithethanevans.substack.com/taro25)

Ex-Amazon VP, Leadership Coach

Ethan Evans

Tech Lead @ Robinhood, Meta, Course Hero

Alex Chiou

How To Build A Strong Manager Relationship (From An Ex-Amazon VP)

For over a decade, *Cracking the Coding Interview* has been hailed as the "bible" of interview prep. Now, its high-anticipated sequel, [Beyond Cracking the Coding Interview](https://www.amazon.com/dp/195570600X), is out. While the original delved deeply into coding problems, the sequel shifts its focus to teaching you how to think—both in the context of technical interviews and throughout the job search process.

In this event, the authors of [Beyond Cracking the Coding Interview](https://www.amazon.com/dp/195570600X) will share how tech hiring has changed in the last decade. Ask them anything about interview prep, job stuff, negotiation, or algorithms and data structures. The authors are:

- [Gayle Laakmann McDowell](https://www.gayle.com/), the original author of CtCI
- [Michael Mroczka](https://www.linkedin.com/in/mike-mroczka/), Google engineer and top interview coach on [interviewing.io](http://interviewing.io)
- [Aline Lerner](https://www.linkedin.com/in/alinelerner/), founder of [interviewing.io](http://interviewing.io)
- [Nil Mamano](https://www.linkedin.com/in/nilmamano/), Google engineer and algorithm researcher

Author of Beyond Cracking the Coding Interview. Founder of interviewing.io

Aline Lerner

Primary author of Beyond Cracking the Coding Interview, Ex-Google

Michael Mroczka

CS PhD, Senior Software Engineer. Wrote 'Beyond Cracking the Coding Interview'

Nil Mamano

Author, Cracking the * Interview Series

Gayle Laakmann McDowell

Beyond 'Cracking the Coding Interview': 10+ Years Of Tech Interview Evolution

The Magic Loop of Rapid Career Growth. Taught by Ethan Evans, a former VP at Amazon.

The Growth And Promotion Recipe - Magic Loop

James Pearce is a former Meta Engineering Director, open-source hacker, and sailor.

In his capacity as Head of the Open Source program at Facebook (Meta) from 2013 - 2017, James has deep insight on how to identify promising projects, make contributions, and build strong relationships.

James is currently sailing around the world on his boat!

Become An Open Source Master (James Pearce)

Learn the key strategies for becoming a go-to person in your team as a software engineer and how it can lead to career advancement. Unlock the secrets to getting promoted in tech.

Become A Go-To Person (Jordan Cutler)

James is the founder/CEO of PostHog, a YC-backed product analytics company. What makes a 10x engineer: https://youtu.be/9utyhOMkQGU

James Hawkins (PostHog)

You are being laid off, getting fired, or just want to move on - learn how to get the best package as a part of your transition out of your company.

In this course, Ethan covers topics including the law, termination circumstances, why you should never accept on the spot, how to prepare your case, the mind of the manager, common asks and gives, and if you can sue.

Course link: https://www.jointaro.com/course/maximizing-a-severance-package/

Ethan Evans: Maximizing a Severance Package

In this course, Louie tells you the things your manager wants to tell you, but can't. Either because it would make things awkward, or it would get them in trouble. 

These are things you'd have to learn the hard way. This is the advice Louie wishes he had years ago, that you will get now. This course condenses a year of One on Ones into 1.5 hours.

Timeless Career Advice for Software Engineers

An engineer influencer is an engineer who builds an audience on social media and uses that to kickstart their future startup or business.

The benefits of doing this are massive: meet interesting people, make some money, or start a company. All of these become much more interesting if you have an audience of people who know you and respect you. 

Taught by Michael Lin, ex-Netflix engineer turned engineering consultant and EECS alum at UC Berkeley.

Become An Engineer Influencer

This class contains a systematic, focused process for Managing Up successfully. It covers how to manage up in a variety of situations and to different people such as senior peers and skip level leaders.

Ethan Evans: Managing Up

If I told you that you can get $10,000 with a single email, would you do it? Of course right? Well, that’s what negotiation is, yet so many engineers are afraid to do it.

The Insider's Guide To Negotiating Your Tech Salary And Compensation

Onboarding is the critical period when you first join a new team or company. Use the advice here to learn the codebase and build trust within weeks, not months.

The Complete Onboarding Guide For Software Engineers

Ethan Evans is a retired Amazon Vice President (VP) who now coaches managers to grow into executive roles. 

He became a manager after only six months in an IC role, at a startup in the 90s. He ascended quickly across several startups before taking a "demotion" to be manager when joining Amazon in 2005. Across 15 years at Amazon, Ethan became a VP, a title he held across multiple orgs starting 2013. He left Amazon in 2020.

Ethan Evans: Thriving In Eng Management

I asked every step of the IC engineering ladder a simple question: "What is the most important skill for success at your level?"

The result is an engineer from each of the 7 levels sharing their candid reflections about the most important skill, along with advice. Companies represented: Meta, Slack, Qualcomm, Gusto, Instacart, Cruise, and Pinterest.

Asking 7 Levels Of Engineers The Most Important Skill

In my humble opinion, these are the top 10 resources I have on Taro.

Top 10 - Rahul

The best advice in Taro related to getting more done in less time 🕜

Productivity

The best advice for anyone trying to get to Staff Engineer or higher

Staff Engineer Growth

20 year tech veteran Daniel Tomko (11 years at Microsoft and 8 years at Meta) shares what most engineers get wrong when joining a new team, and what to do instead. 

This is a 4 part series filled with practical insight!