Often Forgotten Team Considerations

We wrap up with two often-overlooked but highly consequential factors when selecting a team: on-call health and code review speed.

Here are the core points from the lesson:

- We explain that on-call quality can make or break your work-life balance, and many early-career engineers don’t evaluate it; the two key questions are how *frequently* you go on call and how *painful* it is (night pings, fire drills, number of incidents).
- We highlight that not all on-call is equal—middleware teams or teams responsible for triaging other teams’ outages often have disproportionately stressful rotations unless strong runbooks exist.
- We emphasize that code review speed is critical for learning and momentum: slow iterations (1–3 days per review) compound quickly, turning a small change into a week- or multiweek-long process and severely limiting growth for junior and mid-level engineers.
- We define healthy expectations: reviews returned within a day are ideal, &gt;1 day is a yellow flag, and &gt;2 days per revision is a red flag because it throttles how often you ship and how fast you improve.

Finding Scope To Grow

We walk through how to evaluate whether a team offers real *scope for growth*—one of the most important factors for long-term career progression.

Here are the core points from the lesson:

- We suggest assessing a team’s track record of major launches: frequent, meaningful wins signal room for impactful work, while long dry spells often indicate a team that is either too new (unstable) or too mature (no hard problems left to solve).
- We point out that very mature orgs like core Facebook Feed may be so optimized that it’s nearly impossible to produce meaningful results, making promotions extremely difficult; meanwhile, very new orgs offer big scope but come with chaos and uncertainty.
- We recommend examining the level distribution on the team: a healthy mix of engineers more senior *and* more junior than you enables both mentorship (learning) and leadership (scope creation), whereas being the most junior or most senior can severely limit growth.
- We advise deeply evaluating the engineering manager’s track record—whether they have successfully grown people from junior → mid-level → senior → staff—because a strong EM accelerates your development, while a newly minted or unproven EM introduces career risk.

Talk To Engineers

We explain how to get a real, unbiased understanding of a team by talking directly to engineers—not just the hiring manager.

Here are the core points from the lesson:

- We stress that managers have strong incentives to “sell” their team—they’re evaluated on hiring success and growth—so their perspective is inherently biased and overly positive.

- We recommend explicitly asking to meet 1-2 engineers on the team, ideally ICs who have been there for years and are leaving on good terms, as they provide the most honest, nuanced picture of day-to-day culture, challenges, and growth.

- We emphasize that speaking with the tech lead is especially valuable, since alongside the manager, the TL will influence our experience more than anyone else after joining.

Team Importance

We explain how to evaluate whether a specific *team* within a company is a strong place for growth, impact, and stability.

Here are the core points from the lesson:

- We show how to assess whether a team is core to the business by asking whether it’s a profit center or cost center; teams tied to revenue (like Google Ads) offer stability and long-term opportunity, while peripheral or internal-tool teams often limit growth.
- We illustrate how to categorize teams: mature core teams (stable, slower growth), big bets (high upside but real risk of shutdown, like Stadia), and low-impact internal teams (comfortable but slow-growth).
- We recommend questions that reveal real importance: What does success look like? What growth targets matter? Does the CEO mention this product in earnings calls? These signals show whether leadership actually prioritizes the work.
- We show how to “backdoor” the truth by asking leaders their top three priorities; if your team isn’t on that list, it’s unlikely to be a strong engine for your career unless you explicitly want a lower-pressure role.

Interviews Go Both Ways

We open this final section by explaining how to evaluate teams *within* a company—starting with the interview process itself.

Here are the core points from the lesson:

- We explain why “first principles thinking” about company financials is usually unhelpful for engineers: exponential growth makes predictions unreliable, and financial modeling without expertise leads to bad conclusions.
- We highlight that the interview stage is your first and most reliable chance to gather real signal about culture and team fit; you should “reverse interview” the company rather than defaulting to superficial questions.
- We point out common bad questions (e.g., “What’s your favorite thing about working here?” or “How’s the food?”) because they produce biased, obvious answers and don’t reveal anything meaningful about career growth or challenges.
- We recommend instead asking questions tied directly to your top priorities—work-life balance, growth, team culture, on-call load—so that you can evaluate whether the environment actually aligns with what you need.

Ineffective Evaluation Techniques

We close this section by calling out two common but misleading ways people try to evaluate companies and why we should avoid them.

Here are the core points from the lesson:

- We urge you not to judge a company based on how much you liked or disliked your recruiter or interviewers, because you’ll almost never work with them, and your network’s lived experience inside the company is a far better signal of culture and fit.
- We caution against spending lots of time analyzing financial statements and balance sheets unless you’re actually trained in that area; as engineers, we’re likely to misinterpret the numbers and waste time.
- We recommend instead focusing on conversations about the company’s vision, growth, and people, since fast-growing companies can change dramatically in just a few years and those qualitative signals tend to be much more predictive for your career.

General Career Direction Principles

We close with guidance for people who feel completely unsure about where to go next in their tech careers.

Here are the core points from the lesson:

- We suggest that early-career engineers, when possible, start with a big tech company for 1–2 years to gain stability, strong compensation, and a solid learning foundation—then use that platform to explore what they truly want.
- We recommend deliberately experiencing different company archetypes (startup, midsize, big tech) because each environment teaches different skills, exposes us to different cultures, and clarifies our long-term preferences.
- We emphasize that career needs change with age and life complexity—stability tends to matter more in our 30s and 40s—and that most big-tech engineers ultimately transition to smaller companies to find scope and growth.
- We add that when in doubt, choose a company where software engineering is core to the business, not a peripheral function; being in the “engine room” of a product-focused tech company dramatically increases learning, opportunity, and long-term career resilience.

Breaking Down Startups

We break down what it really means to join a VC-backed, high-growth startup and how the experience differs from big tech.

Here are the core points from the lesson:

- We outline the major upsides of early-stage startups: massive technical scope, the highest possible career ceiling, and deep fulfillment from directly shaping a company’s destiny—especially when joining at Series B or earlier.
- We explain the risks: early startups are unstable, resource-constrained, and extremely high-pressure, where production issues can threaten the company’s survival and where chaos is normal, not exceptional.
- We show why growth is the single most important signal when evaluating a startup: growth increases technical complexity, headcount, leadership opportunities, and the likelihood of exceptional financial upside; stagnation is a strong red flag.
- We contrast this with agencies/consultancies, noting they rarely offer strong long-term growth for early-career engineers unless someone is already a world-class expert—making startup or big-tech paths much more reliable career foundations.

Breaking Down Big Tech

We outline the real benefits and drawbacks of joining big tech, focusing on what actually matters for long-term career growth rather than the hype.

Here are the core points from the lesson:

- We explain that the biggest advantage of big tech is prestige. Having Google, Meta, Amazon, or Microsoft on our résumé dramatically increases future job opportunities, recruiter response rates, and long-term career mobility.
- We highlight additional strengths: top-tier compensation, strong and reliable learning environments, and overall consistency in job security, interview success, and career progress, all of which compound after a few years inside a major tech company.
- We walk through key drawbacks: massive company size makes it hard to find meaningful scope, many hard problems are already solved, work-life balance can be demanding, and advancement requires strong communication and leadership skills—not just coding ability.
- We stress that big tech isn’t ideal for everyone; engineers who prefer deep, heads-down coding or highly autonomous environments may struggle in the bureaucracy and stakeholder-heavy nature of these organizations.

How To Do Research

We walk through how to actually evaluate companies and teams, emphasizing that good information is hard to find and rarely lives in public reviews.

Here are the core points from the lesson:

- We stress that big companies aren’t monolithic—cultures vary widely across thousands of teams—so the most reliable way to assess a company or team is to tap into our network, where trusted people can share accurate, firsthand experiences.
- We highlight why building deep relationships in school and at work is invaluable: our network expands our access to real data over time, and meaningful connections (teammates, managers, peers) often shape our opportunities more than technical ability alone.
- We suggest complementary methods—reverse-interviewing during the hiring process, reading engineering blogs, following tech news, and checking curated communities—to gather signal, while warning that Glassdoor skews too positive and Blind skews too negative due to self-selection.
- We show that even venture capital, which allocates billions in tech, runs almost entirely on networks and backchannel references—underscoring that our own career decisions benefit from the same relationship-driven information flow.

Underrated Career Goals

We highlight the qualities engineers consistently underestimate and why these matter far more than most people realize when choosing a company or team.

Here are the core points from the lesson:

- We emphasize that the most underrated factor by far is a truly supportive team: a strong manager, teammates who challenge and care about us, and an environment where we grow—something incredibly rare, worth cherishing, and often more valuable than joining a prestigious brand.
- We explain that growth opportunities don’t come automatically from prestige; even at places like Meta or Google, you can land on a team with poor scope or weak culture, and real growth often requires intentional team selection and proactive effort.
- We stress that stability and sustainable work-life balance are often undervalued by early-career engineers, who assume they can power through long hours, even though sustained 60-hour weeks degrade learning, productivity, and mental health—and that the best creators historically do only a few hours of deep work daily.

Overrated Career Goals

We explain which attributes engineers tend to over-prioritize and why doing so often leads to bad career decisions.

Here are the core points from the lesson:

- We see many early-career engineers chase trendy product spaces (ML, AR/VR, blockchain) without genuine passion, ignoring the high risk that trends fizzle and leave teams stagnant; survivorship bias makes the rare success stories seem more common than they are.
- We highlight a similar trap with technical stacks: engineers often assume “more modern is better,” jumping between new technologies and hurting long-term growth, when stable, proven stacks at strong companies typically offer better learning and career durability.
- We show that over-prioritizing level/title or short-term compensation can backfire, since inflated titles at weak companies and high pay tied to terrible work-life balance rarely lead to long-term career success or well-being; growth opportunities and supportive teams tend to drive compensation naturally over time.
- We stress that compensation is multi-variable (base vs. equity vs. upside potential), and examples like Barnes & Noble illustrate how deceptively high salaries may underperform compared to equity-rich tech roles over a multi-year horizon.

Career Priorities List

We walk through the many different priorities that can shape which company and team are truly right for us, and why this makes the choice so hard.

Here are the core points from the lesson:

- We list 14+ possible priorities—compensation, work-life balance, company prestige, supportive team, growth opportunities, stability, maximum outcome (upside), remote work, product space, company ethics, technical space, title, benefits (like parental leave), and location—showing how many different axes there are to optimize for.
- We explain nuances within each priority: for example, early-stage startups can offer huge upside but high risk, big tech often offers more stability but lower ceiling, and team makeup/scope can make or break growth even inside a good company.
- We emphasize that the macro environment (economy, industry turbulence, company-specific churn) must be considered alongside our personal priorities when evaluating offers and career moves.
- We share that we have strong opinions and heuristics, but the goal is for each of us to examine and “stack-rank” our own priorities, test our assumptions, and disagree deliberately rather than blindly following default paths like “just go to FAANG.”

The First Thing You Must Figure Out

Choosing the right company or team is hard because what’s “great” truly depends on our individual priorities.

Here are the core points from the lesson:

- We emphasize that people differ in life stage, location, responsibilities, and goals, which means there is no universal “best” company or team, only what is best for our personal priorities.
- We caution against blindly chasing FAANG or big tech, noting that while it can be optimal for some, it can be a poor match for others depending on what they value and need at this stage of their career.
- We outline the key first step: listing all potential priorities and stack-ranking them to create a clear, personalized hierarchy that guides the next career move.

Why Team Selection Is So Critical

We open by explaining that choosing the right company or team is one of the highest-leverage decisions we can make in our software engineering careers.

Here are the core points from the lesson:

- We use the “bus on a highway” analogy to show that company choice determines how far we can go; our personal effort only determines where we sit on that bus.
- Even if we perform exceptionally, joining a stagnant or declining company limits our long-term trajectory, while joining a fast-moving, hyper-growth company can accelerate our career dramatically.
- Real-world examples like Marin Software versus Google illustrate how picking the right “bus” can either stall or amplify career outcomes, independent of our individual contributions.

Promotion Expectation Examples (Good vs. Bad)

In this lesson, we show how vague career frameworks aren’t enough for real growth—and how transforming generic expectations into detailed, personalized criteria creates clarity, direction, and stronger promotion outcomes.

- We explain that most companies’ career matrices are extremely generic (“have broad influence in code review”), making them nearly useless for understanding what to *actually* do to reach the next level.
- We demonstrate how to replace vague statements with concrete, customized expectations that clearly outline the **delta** between current level and next level.
- We give an example from Meta: mid-level engineers (E4) typically review code only in their domain, while senior engineers (E5) are expected to review code across unfamiliar modules, broader systems, and even sister teams—showing multiplicative impact.
- We highlight that this level of specificity makes it far easier for us to understand, track, and execute on what “the next level” actually requires.
- We emphasize that crafting a detailed plan also has a perception benefit: it signals seriousness, ownership, and thoughtfulness—making managers more likely to advocate for our promotion.

Create A Promotion Plan

In this lesson, we explain why creating a written promotion plan is essential and how treating it like a living contract dramatically increases our chances of moving up, even though perfection or guarantees don’t exist.

- We emphasize getting everything in writing: building a promotion plan that outlines exactly what “performing at the next level” looks like, so expectations are clear and aligned.
- We note that even with a solid plan, promotions can fall through due to org politics or director-level decisions—but having a plan still increases success odds by 10x compared to “just doing good work and hoping.”
- We highlight the need to maintain the plan monthly, updating it as org priorities, reorgs, or company conditions shift—especially crucial at senior or staff levels where project selection matters.
- We explain the importance of defining the delta between your current level and the next—clarifying what skills, behaviors, or scope need to improve.
- We recommend structuring the plan around the company’s evaluation axes (e.g., engineering excellence, direction, project impact, people) to clearly identify which “stats” need leveling up.

Promotion Dialog Examples

In this lesson, we examine how *not* to ask for a promotion, then show how to reframe the conversation in a way that aligns incentives, builds trust, and opens up productive dialogue with our EM.

- We highlight that asking “Can I get promoted?” is a poor approach because it’s self-focused, lacks evidence, feels transactional, and corners the manager into a yes/no response.
- We break down why this framing fails: it signals entitlement, doesn’t show impact, ignores team goals, and provides no data or context for advocacy.
- We offer a better alternative: expressing commitment to the team, desire to increase impact, and asking what steps are needed to reach the next level—an open-ended, collaborative question.
- We explain that managers value signals of long-term commitment and team-oriented motivation, not demands based on tenure or frustration.
- We reinforce that smart framing aligns our goals with the manager’s incentives: helping us grow increases team impact, which helps them succeed too.

Framing The Dialog

We cover how promotions actually work, why they’re not guaranteed even if we’re performing well, and how to talk about them with our EM in a way that aligns incentives and builds trust.

- We explain that promotions require **both** performing at the next level **and** an organizational need for someone at that level—otherwise even great performers can’t move up.
- We note that promotion discussions require trust; bringing up promotions too early (e.g., in week one) backfires because the manager doesn’t yet know our work or commitment to the team.
- We warn that reorgs can derail promotion momentum when a new manager must advocate for us without shared history; coordinating between old and new managers helps mitigate this.
- We highlight that promotions are meant to signal that we already operate with higher scope, independence, and cross-org trust—not something to wish into existence.
- We emphasize framing promotion goals in terms of **increasing team impact** rather than title or compensation, since managers (especially in tight-budget environments) prioritize engineers who help them deliver more impact, not those who simply want advancement.

Be Upfront About Your Goals

In this lesson, we emphasize the importance of sharing our performance goals openly with our EM so they can effectively advocate for us during performance reviews, which are human-driven, subjective, and highly dependent on manager alignment.

- We highlight that performance ratings are not generated by an objective system (i.e. they’re decided by people), so managers need clear insight into what rating we’re aiming for to advocate properly.
- We stress that “no negative feedback” does *not* mean we’re on track for a good rating or promotion; assuming this is one of the most common and costly mistakes ICs make.
- We reinforce that 1:1s are the central place to share our target rating or promotion timeline, whether we’re aiming for “meets,” “exceeds,” or a promotion, so we can then build a plan with our EM.
- We note that even if our goal is simply to maintain solid performance (e.g., a 3/5), we should still say so explicitly to avoid slipping into a low rating unexpectedly.
- We share a story illustrating how unchecked assumptions about performance can lead to disappointment—and how early, honest conversations could provide clarity and opportunities to improve.

Tech Career Growth Videos

Our instructional videos provide software engineers with insights needed for career growth. Masterclasses go incredibly in-depth on a specific tech topic while case studies are real examples from established engineering leaders.