The Effect of Interest Rates

We walk through how macroeconomic conditions—especially interest rates—directly affect tech companies and tech workers.

- The federal funds rate guides how expensive it is for banks (and ultimately companies) to borrow money, and while near-zero rates felt normal recently, historically higher interest rates are actually the norm.
- When interest rates rise, the cost of borrowing increases, which makes companies far less willing to invest in long-term bets that may not pay off for several years.
- Because the tech industry is heavily driven by growth funded through borrowing and investment, higher rates trigger spending pullbacks, reduced hiring, and ultimately the contraction and layoffs we’re seeing across the market.

Why Layoffs Happen

We explain why layoffs happen and why they’re a recurring reality in the tech industry.

Here are the core points from the lesson:

- Layoffs occur when companies face bad economics, often triggered by unforeseen macroeconomic shifts like the post-COVID slowdown after years of stimulus-fueled growth.
- Overambitious hiring is a major contributor, especially when overly positive economic conditions lead companies to scale headcount faster than the business can sustainably support.
- Fundamentally unsound business models and poor strategic direction also drive layoffs, and in practice, these factors usually overlap—making layoffs inevitable since executives can’t make perfect decisions all the time.

What Are Layoffs?

We break down what layoffs are, how they differ from firings, and why terminology matters in the tech industry.

Here are the core points from the lesson:

- Layoffs are ad hoc, unpredictable events that cut a large number of employees for economic reasons, unlike regular performance-based cuts where low performers are ranked out.
- Being laid off is generally not the employee’s fault and is different from being fired for incompetence, which is why layoffs—especially in tech—typically come with generous severance packages.
- Most recent “layoffs” in tech are technically RIFs (reductions in force), meaning the company has no intention of rehiring those employees, even though the industry commonly uses the term layoff.

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.

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.

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.

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.

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.

Having The Meeting

In this lesson, we walk through exactly how to run a high-impact 1:1 with our EM by using the time intentionally to build trust, surface wins, work through challenges, and create momentum through clear action items.

- We start each meeting with 2–5 minutes of personal check-in to strengthen rapport, since life and work affect each other deeply.
- We share weekly wins to stay visible and ensure our contributions are recognized—while also making future performance review writing much easier.
- We move through our pre-seeded agenda topics (e.g., promotion planning, feedback digestion, team conflicts), which flow smoothly because we prepared them ahead of time.
- We close with clear action items for both sides—then begin the next week’s 1:1 by reviewing whether the previous actions were completed.
- We reinforce that framing wins with a “so what?” (impact or next step) and writing notes live during the meeting both strengthen trust and make the manager feel valued.

Before The Meeting

In this lesson, we dig into how to prepare for 1:1s so they’re consistently high-value and how thoughtful prep not only improves the conversation but also prevents cancellations and protects our time.

- We advise seeding the 1:1 agenda at least 24 hours in advance so our EM can “pre-compute”—arriving prepared instead of reacting on the spot to complex issues.
- We recommend prioritizing agenda items, putting critical topics first in case time runs short, and leaving lower-priority items for follow-up on Slack if needed.
- We highlight that surprising a manager with heavy topics during the meeting leads to wasted time and weaker guidance, whereas advance notice empowers them to think deeply and respond effectively.
- We explain that sending a thoughtful agenda also makes it harder for the manager to cancel or move the meeting, since it clearly shows we’ve invested effort and have meaningful topics ready.
- We reinforce that consistent preparation creates smoother, more productive discussions and helps us extract maximum value from the limited 30 minutes we have each week.

Be Vulnerable

In this lesson, we highlight the importance of vulnerability in building a strong, supportive relationship with an engineering manager—because they can only help us if they understand what we’re going through.

- We stress that EMs can’t read minds; if we’re struggling, whether with a teammate, a project, or something personal, we should tell them so they can protect our well-being at work.
- We explain that good managers act like part-time therapists, and sharing when things are rough allows them to adjust workload, mediate conflicts, or at least offer support.
- We note that vulnerability builds trust, just like in friendships outside of work, and that trust significantly improves how effectively we collaborate.
- We clarify that we shouldn’t overshare, but we also shouldn’t hide everything—sharing selectively helps EMs understand who we are and how to help.
- We reinforce that showing vulnerability increases the “trust meter,” strengthens the partnership, and ultimately unlocks more powerful support from our EM.

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.