One high-level piece of advice I have is to lower the stakes of this decision. This job is just a starting point for your career: it will not define your career unless you let it.

You can (and will!) quit the company at some point when you decide to move on. So don't feel like you're trapped in this company.

How big is the company you're joining. In a large enough company (e.g. FAANG), you'll find wildly different levels of skill, mentorship, feedback, etc. I'd optimize for finding a good team with people you enjoy working with while also having senior people to learn from.

Tech Lead/Manager at Meta, Pinterest, Kosei

Rahul Pandey

One tip I'll share from the course: be very clear about expectations for your first 1 month, 3 months, and 6 months. [Write it down](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/create-an-onboarding-doc/) and discuss with your manager!

IQ tests are like astrological tests in India.

The astrologer will say that you will have a good/bad year, or you'll marry someone of a specific type, or anything else they feel entitled to 'predict.' The issue becomes that you start to consciously or subconsciously change your behavior based on these predictions.

You can see that they're made up since different astrologers will give you different predictions, and you can change the answer by paying a bit more 😅

If you take multiple IQ tests, you'd probably get very different results. Especially if the assessment is done by a company that will then charge you for being part of the 'high IQ club.'

There is probably some validity in IQ tests, but they don't have much practical value, and it could hurt you if you find the score higher/lower than what you expect.

I'm leaning toward studying Leetcode ([aim for mastery](https://www.jointaro.com/course/crash-course-data-structures-and-algorithms-concepts/)!) because:

- A side project with 1000 users is already quite impressive, and you can talk about how it's continuing to grow. Getting to 10K users probably won't change the narrative much.
- The skills needed to grow the side project won't be applicable to your next job. Like you said, the **distribution** is the hard part now to grow your app. If you're optimizing for climbing the career ladder, you won't need the marketing/video making skills as much. 
  - As a side note, this is why I recommend SWEs to build pure utility apps that can don't require a social network or upkeep. The utility apps can continue to grow on their own through search traffic in app stores or Google search. 

Once you're landing interviews, your side project has had the intended impact -- get your foot in the door. The reason to continue building the side project after that is: 

- You enjoy it
- You're learning from it
- You want to monetize it
- You think it could become a "real" business

Amazon is a much stronger brand than PayPal, and will likely put you in a high-functioning team with smart people. This means the "exit opportunities" -- your next job after your current one -- will be much better at Amazon.

Since you get paid more at Amazon anyway (a minor consideration for you at this point), I'd jump to Amazon.

The nuance here is what exactly you're working on: if there's a specific tech domain that you have access to at PayPal, or an exceptional manager, that may be a reason to stick around.

You don't have to be too concerned with job hopping since you're early in your career, as I explain here: [When To Properly Leave Jobs So Your Career Doesn't Get Punished](https://www.youtube.com/watch?v=RYY3maOhSWI)

For *the best employees*, high-frequency trading firms pay more than top tech firms, but there are a few important differences: 

- **Equity**: You're much more cash-heavy in HFT since the majority of your compensation will be in a bonus. This can be quite good, but also means you don't see the magical 10x or 100x increase in wealth by holding equity in a growing startup.
- **Job stability**: I've had close friends get laid off in an HFT firm in a bad year. In finance, there's much less stable, recurring revenue compared to a tech company. You might even be able to assign a PnL (profit and loss) on each employee in trading, which adds to the stress. (This is means work-life balance is worse).
- **Your "rank" in the company**: This may not matter if you're purely optimizing for cash, but I know at some trading firms, the traders/quants are the most important employees, and SWEs are playing a support role. This is very different from Facebook/Google, where engineers are clearly the most important job function. 

In my experience, there's a *reasonable* solution that you're expected to code within the interview. For some questions, there may be some advanced data structure that allows you to do things more efficiently, but it's unreasonable to expect that most interviewees have seen that pattern before. 

As a candidate, one way to get part of the way there is to present and implement the 'good-enough' solution. But spend 5 min at the end talking about your intuition for something better. The awareness of something better gives you points. Something like: 

> Red-black trees have a self-balancing property which might be useful if applied here, due to X. If I had more time, I'd explore how that might fit in here.

We have a 10 hour crash course on Data Structures & Algorithms by Alvin: [Crash Course: Beginner Data Structures And Algorithms Concepts](https://www.jointaro.com/course/crash-course-data-structures-and-algorithms-concepts/)

This course focuses on **mastery** -- if you have mastery, you're much more likely to arrive at the optimal solution.

There are two broad approaches here: 

1. **First principles thinking**: Look at the data and come up with reasonable assumptions about how much you can save costs or grow revenue based on a project. 
   1. You can compute things like bug prevention, user growth, revenue growth, time savings, etc. This requires looking at code, dashboards, or historical data.
2. **Second principles thinking**: Identify past projects that are similar to what you're proposing, and 'borrow' their metrics. 
   1. Make the argument that "They achieved X, we should achieve something similar." Or something like "They failed due to Y, but this project will avoid that and achieve what was promised."

Your question is focused on #1, so I'd encourage you to also spend some time on approach #2. This can be much easier, since you're leveraging the past work of your teammates, which means it already has a lot of credibility. 

Another consideration is to understand what metrics your company cares about, both at the company-level and for your individual performance review: [Is it normal for a company to track performance related metrics and use it as input for promos/bonuses?](https://www.jointaro.com/question/7UVfzybdKCS9Jgyqefix/is-it-normal-for-a-company-to-track-performance-related-metrics-and-use-it-as-input-for-promosbonuses/)

I'd like to comment specifically on the "process is bloated" point. I felt this too at some points when I was Tech Leading a re-architecture initiative on Portal. It's very draining to field questions and status requests from multiple people per day...

So I have two recommendations: 

1. Can you change the process around **how** people receive information? The two obvious solutions that come to mind are a special view/board in the tasks tool, or just a weekly Workplace update post. So when someone asks you a question, you either say (1) I've addressed it &lt;here&gt; or (2) I will address in the next update. 
2. Can you work on a project which has a lot less red tape or bureaucracy? I found that when I was able to write and ship code unencumbered, I was a lot happier as an engineer, and that made my other work more tolerable. In general, I think it's nice to work on at least 2 projects: 
   1. One which is your main XFN effort where you'll probably get lots of pings
   2. Another which is more developer or internal focused, so there's less scrutiny and you can move faster. 

I talk about the internal tool I built at Meta here: [\[Case Study\] Building A Meta Internal Tool To Empower An Entire Org: Staff Promotion Story](https://www.jointaro.com/lesson/qvp2quodqAEWSkN7sayt/case-study-building-a-meta-internal-tool-to-empower-an-entire-org-staff-promotion-story/)

(I would definitely try to stick around to the 1 year mark at Meta)

I would make the team switch. There may be a short-term dip in your momentum to get to Staff, but the new team feels like the clearly better choice for longer-term growth.

### Manager strength and relationship

To get promoted to Staff, you need a strong manager. Even if your manager likes you, they may not have enough context or political sway in the organization to get you promoted. That's my worry with your current manager. 

It sounds like your new manager doesn't have as many question marks about their stability in the company.

### Tech domain

I love that you're excited about the technologies you'll be able to learn in the new team. Not only is this good because of your excitement levels, but being able to move around the codebase makes you more valuable to the company.

[Depth is more important than breadth early in your career](https://www.jointaro.com/question/QG8K97uU9YjuoDUc9pCE/breadth-vs-depth-as-a-junior-engineer/), but for a Staff engineer, being able to dabble in backend as a frontend engineer makes you very powerful!

### Questions to ask

Talk about what you'd work on in the new team, and what a path to promotion might look like.

- I highly recommend going through question: [What questions can I ask to my to-be manager about the team I'll be joining?](https://www.jointaro.com/question/CalZngDF480CWrrTKD58/what-questions-can-i-ask-to-my-to-be-manager-about-the-team-ill-be-joining/)
- In addition to talking to the manager, I'd talk to high-level ICs who have previously worked with this manager. They'll give you more unbiased answers about what it's like to work with them.

I wouldn't treat a System Design round as a behavioral interview for two reasons: 

- Mid-level engineers should be able to have reasonable conversations with system design. I recommend starting the basic design done relatively quickly, as Guarav recommends in his course: [Building The Basic Design](https://www.jointaro.com/course/how-to-crack-system-design-interviews-as-a-software-developer/building-the-basic-design/)
  - Then you can check with the interviewer on what domain or area to explore more deeper.
- Many companies use system design to determine your level. So it may not be established to the interviewer that you are an L4, mid-level. If you do well enough, you could come in at a higher level.

I like option 2 (*Do the Google interview, and if I get the offer, go to Google for an internship before joining Amazon full time*) if you're ok with spending the time for the interview. 

This gives you an "insurance policy" if Amazon rescinds their offer. You also get to expand your network to Google engineers, which is very valuable.

It's unfortunately not really an option to say "*I don't want to do this.*" Instead, you need to share a viable alternative: 

- **You have an idea for a higher-priority project** that you are uniquely equipped to tackle.
- **You think a shared ownership model would be better for this project**. You could argue that it's better for knowledge sharing and team resiliency. 

If you can't avoid it completely, remember that you can allocate time for another project as well. Something that is more greenfield, doesn't need a bunch of permissions, and doesn't have the legacy issues.

I talk about this a bit in the negotiation course: [Don't Overshare (Level, Passion, Timeline)](https://www.jointaro.com/course/the-insiders-guide-to-negotiating-your-tech-salary-and-compensation/dont-overshare-level-passion-timeline/)

**Vagueness is your friend**. Some sample dialog you can use: 

Just refuse to answer: 

> I'm more interested in getting to know the company and evaluating the mutual fit. I'm sure we can figure out the appropriate level later on.

Talk about how your scope/work is effectively at a mid-level:

> I've been the owner for this workstream for the past X months and I'm the point person for this feature.

Focus on the future instead of the past:

> I'm targeting mid-level engineering roles. I'm in the interview loop for mid-level at the other companies I'm interviewing at

One of the benefits of working at a large tech company is that you have access to people who are experts in all sorts of different domains. 

I definitely would explore internally before leaving the company for a new tech area. Two benefits of doing this: 

- **You can gather lots of valuable info "on the side."** I'd be deliberate about reading notes and [scheduling 1:1s](https://www.jointaro.com/lesson/FEK6JZqW2Jg3rdN9yeGn/masterclass-how-to-have-impactful-1-on-1-meetings/) with people who are working in the area that you care about? Test your assumptions about what the job is like and if you'd like it.
- **You can more easily reverse the decision once you make it**. If you have good ratings, you can likely go back to a team where you have enough context and impact.

A related question that is specific to ML: [How can I successfully transition my career into the data and ML side?](https://www.jointaro.com/question/h7D7zSTRgGCgajg6Dz0P/how-can-i-successfully-transition-my-career-into-the-data-and-ml-side-and-ensure-long-term-relevance-in-my-chosen-field/)

What really matters is **business value**.

Code can certainly create business value, but it's possible to write tons of code and still end with nothing. So I'm interested to hear if product velocity went up. Also, how maintainable is the code? 

Relatedly, the 25% stat is interesting since I made a video called [50% Of Engineering Is Now Easy - How To Integrate AI Into Your Workflow](https://www.youtube.com/watch?v=y8hpTRllvZY)

How much of a rush are you in? If you have other opportunities, I'd wait, but it's hard to say without knowing the opportunity cost. 

When you say your friend can refer you if he gets an offer, he'd have to wait until he actually joins the company, right? So that could take weeks/months. 

And even once he gets in, the referral will help, but it won't magically elevate your profile. The strength of the referral depends on: 

- How well does this person know you?
- How senior is this person?

Your friend who just joined won't be senior, but hopefully they can put in a strong referral.

\+1 to what Alex said. I'd also avoid anything that is on the critical path for a launch since there is high variability for their competency and productivity.

Can you look at past intern projects on the team? Usually at a Big Tech co there are plenty of intern projects around dev tools, experiment ideas, or new project launches that could be a good intern project.

Also see this guide I wrote about how interns should succeed, it could inspire some ideas about a good project: <https://blog.jointaro.com/the-ultimate-software-engineer-internship-survival-guide/>

I would **choose to interview in November**. Think about interviews like money. In the same way that "*money now is better than money later,*" locking in interviews now is better than scheduling interviews later.

The world changes rapidly (and tech cos in particular). As you alluded, headcount might change, the presidential election might change priorities, or anything else could derail your entry into the company. 

The other benefit is that you likely have a clear deadline for hearing back since all hiring will stop by mid-December at Meta. You'll be able to wrap up the process before the holidays. 

\[Side note: If you were a new grad, I would absolutely choose the earlier option. There are a limited number of slots for interns or new grads, so you need to interview ASAP. Since you're a senior engineer, it's a bit more complicated, but I still think November is better.\]

You still have more than a month before you enter the dangerous slowdown from holidays. In that time, I recommend: 

- You schedule the Meta interview and aggressively study for it
- Schedule many (3+ companies) other interviews as well to be before Meta
- Communicate to companies that you are making a decision by mid-December about which company to join.

You attitude should be "**I will have an offer I'm excited about by mid-December**." (Even if it's not Meta) That confidence will put you in a stronger position when talking to companies and you'll be able to make it happen!

What is the purpose of the introduction? How well do you know the person making the introduction? 

If you're in the position of asking for something, the burden is on you to follow up in a timely manner, provide brief but relevant context, and make a clear ask (don't say something like "*Can you be my mentor?*" or "*I'd love to get to know you!*"

Something like this is much better: 

> I noticed you worked at company X. I actually had a friend who worked there and loved it, but thought it was fast-paced. Did you have a similar experience? I'm interested in learning more for Y reason. Do you have 20 min sometime next week to discuss it? I am free on these dates, or you're welcome to pick a convenient time here.

If you're working in cloud services, e.g. GCP, AWS, Azure, there are a huge number of moving pieces and services. 

This could be a rare instance where simply reading about these services and having a basic familiarity is valuable. It's hard or impossible to build something that involves all the 100s of services. However, as you read about them, you should not try to just regurgitate what the service is used for. Try to answer these questions: 

- What are the new features or changes coming to this service? 
- What is the developer sentiment of this service? 
- How important is this service to the company overall?

This will make you **much** more valuable than simply parroting the technical definition of Amazon Athena, Inspector, Beanstalk, etc. (I wonder how they come up with these names...)

Do you know which team you'll be on? It's probably worth building something or writing code with the product/service you'll be working in.

> I want to be ramped up after a week

Where did you get this timeline from? One thing I'd do is be **very explicit** with your manager your ramp up timeline and how that will be measured.

Ideally, this is something you can add (or your manager can add) into the onboarding doc, as I talk about in this lesson: [Create An Onboarding Doc](https://www.jointaro.com/course/the-complete-onboarding-guide-for-software-engineers-succeeding-when-youre-new/create-an-onboarding-doc/)

How you spend your time: code, meetings, 1:1s, design docs, etc will depend very much on your team, level, etc.

This is a very deep question and one that actually came up quite a bit as we navigated the idea maze for Taro in 2022! A very common question that a CTO or eng lead will get is: 

> How effective is our eng team compared to other teams of a similar size? Is our engieering team effective given our investment in them?

Turns out, this is very hard to measure. The most "obvious" answer to look at things like lines of code or number of PRs submitted is riddled with problems. But questions about the health of the overall business are too disconnected from the engineering team.

A common theme I heard from the answers I got was that answering the above question was too difficult. Instead, a **good approximation for developer effectiveness was simply developer satisfaction**. So we could simply look at the survey results of developers asking them questions like how productive they feel and how they enjoy their work.

I'd also point you to <https://getdx.com/>, which is a fairly well-known company now that does research into developer experience and productivity. 

FWIW, I think your answer is solid.

The most important thing is whether the startup has product-market fit (PMF). Everything is downstream of this. If the company has PMF and growing rapidly:

- Your equity will become very valuable
- You will be give more opportunities, scope, and career growth
- You'll work with other smart people who are attracted to a high-growth environment. 

If the company has clear PMF, I wouldn't worry about the age of the founders. Ask them if they have PMF and how they measure it. 

Elliot mentions this in terms of what metrics the company needs to hit: "*If it's a Series A startup, ask what the milestones are to hit Series B and where the team is at in regards to that.*" This is very good advice. 

James Hawkins, CEO of Posthog, talks about the questions he wishes more candidates would ask 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/?playlistId=pgtNMJzQCVMJ8an9LgQc)

> it feels like I lack cool stories for promotion packages and behavioral interviews

This is probably not true. You can connect the dots between your work and what you think is interesting or important. This somewhat reminds me of the [famous janitor story at NASA](https://fromthegreennotebook.com/2017/11/04/the-janitor-who-help-put-a-man-on-the-moon/): 

> The President then casually asked the janitor what he did for NASA, and the janitor replied, 'I’m helping put a man on the moon.'

Your work are likely contributing to the key priorities of the company in some way, even if they're one or two hops removed. Can you figure out what those connections are, and then talk to the people who are closer to what you consider "important" work?

Once you talk to them and build a relationship, figure out what contributions can improve their life, e.g. fixing bugs, asking good questions, or tackling something well-defined in scope.

Once a Senior+ engineer wants to work with you on something important, you don't even need to *ask* your manager. It should be more of an FYI: 

> I'm working with respected person X on this critical project. Here's the timline and here's why it's important -- lmk if you have feedback!

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). 

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?

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)

Group Office Hours are a very simple event type with a very important goal in mind: *Get you the career support you need in a safe, communal setting*. This means:

- These sessions are **never** recorded
- All AI summary and note-taker bots will be kicked out
- If you want to ask your question 100% anonymously, just change your display name and ask it in the chat

So how does it work? Easy: Drop in whenever, raise your hand 🤚 to ask a question (or put it in chat), and leave at your own convenience. *For the sake of fairness, Alex will only answer 1 question at a time per person.*

Can't make the event? No worries, just ask your question anonymously in the Taro forum: [**https://www.jointaro.com/questions/create/**](https://www.jointaro.com/questions/create/)

Group Office Hours With Rahul - Get Personalized Career Advice Privately

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](https://interviewing.io/?c=taroama)
- [Nil Mamano](https://www.linkedin.com/in/nilmamano/), Google engineer and algorithm researcher

Get $100 credit toward a mock interview using the link <https://interviewing.io/?c=taroama>

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!