Understanding The Role

If you want direct interview support from Alex and Uzair, take their live Maven course with discount code **TARO10**: <https://maven.com/alex-kliotzkin/acing-em-interviews>

This part of the course explains why becoming an engineering manager (EM) is not just a promotion—it’s a **career pivot**. Understanding the differences in scope and responsibilities between individual contributors and managers is essential to succeed in EM interviews and in the role itself.

- **Role Shift:** Transitioning from engineer to EM means moving from primarily technical tasks to handling broader responsibilities involving people and strategy.
- **Scope vs. Focus:** Senior engineers focus on deep technical problems, while EMs begin to balance both technical and organizational concerns; directors and VPs go even further toward people/strategy.
- **Career Tracks Diverge:** Staying on the IC track keeps you focused on technology, but switching to EM roles sets you on a path toward executive leadership (e.g., director, VP).
- **Lack of Preparation:** Most engineers aren’t trained to manage people or lead strategically, which causes difficulties when transitioning into EM roles.
- **Wrong Reasons:** Some pursue management purely to climb the ladder, which can result in disengaged or ineffective leaders who use their teams as stepping stones.

What You’ll Learn

If you want direct interview support from Alex and Uzair, take their live Maven course with discount code **TARO10**: <https://maven.com/alex-kliotzkin/acing-em-interviews>

This course is designed to give you a tactical, insider-level understanding of how to succeed in engineering manager interviews. It focuses on aligning your preparation and responses with what senior leadership is actually looking for in candidates.

- **Understand EM Hiring Criteria:** Learn exactly what directors and senior leaders expect when evaluating EM candidates.
- **Persuasive Interviewing:** Develop strategies to convincingly present yourself to hiring managers at the director level and above.
- **Leadership Storytelling:** Discover which leadership stories to craft and practice to demonstrate your readiness.
- **Answer Optimization:** Learn how to elevate your responses from “good” to “unforgettable” by tailoring them for impact.
- **Practice-Based Learning:** Apply concepts through hands-on exercises to reinforce learning and improve real-time performance.

Why Engineering Manager Interviews Are Hard

If you want direct interview support from Alex and Uzair, take their live Maven course with discount code **TARO10**: <https://maven.com/alex-kliotzkin/acing-em-interviews>

Many engineers find EM interviews difficult because they lack direct experience with the interview process, often having been promoted internally or being out of practice. The expectations for EM roles center around leadership, strategy, and stakeholder management rather than technical execution.

- **Limited Interview Experience:** Most engineering managers either transition through internal promotions or haven't interviewed for years, leading to a lack of familiarity with the process.
- **Different Decision-Makers and Focus:** Unlike IC roles, EM interview decisions are made by senior leadership who prioritize business strategy, people management, and stakeholder alignment over technical details.
- **Behavioral Focus:** Behavioral rounds dominate the EM interview process (about 80%) because they assess how candidates handle adversity and complex interpersonal dynamics.
- **No “LeetCode” for EM Interviews:** The subjective nature of these interviews makes it difficult to prepare using standard methods—there’s no one-size-fits-all approach to practicing answers.
- **Feedback is Rare and Vague:** Candidates often don't receive clear rejection reasons, leaving them uncertain about what to improve or how well their responses aligned with expectations.

Hi, I’m Alex

If you want direct interview support from Alex and Uzair, take their live Maven course with discount code **TARO10**: <https://maven.com/alex-kliotzkin/acing-em-interviews>

In this video, I introduce myself and share my mission to help tech leaders thrive, which is a passion of mine.

- I have over 18 years of experience in the tech industry, including more than 8 years in leadership roles, and I graduated with a bachelor's in software engineering from the University of Waterloo.
- My goal is to assist individuals in becoming better versions of themselves through effective leadership. I encourage viewers to engage with me on this journey of growth and development.

Well Roundedness

Working in Big Tech expands far beyond engineering; it shapes individuals into well-rounded professionals by pushing them to develop skills in communication, leadership, and cross-functional collaboration.

- **Development of cross-functional skills**: Navigating product launches or technical changes in a large organization requires coordination across many stakeholders, honing project management, communication, relationship-building, and system design abilities.
- **Environment fosters personal growth**: Operating within a large, complex structure forces individuals to adapt, influence, and lead through collaboration—skills less emphasized in smaller, more agile companies.
- **Preparation for an AI-driven future**: As coding becomes more automated, the remaining 80% of a top engineer’s job like communication, strategy, and leadership becomes even more valuable. This environment equips engineers for longevity in their careers.
- **Transferable experience for career switchers**: Even those new to tech can succeed by leveraging skills from prior careers (e.g., hospitality, education, operations). Communication and stakeholder management experience, in particular, translate well.
- **Resilience through versatility**: Focusing on foundational skills that transcend tech stacks or tools creates career durability, avoiding dependency on niche or outdated technologies.

Big Tech Is Not A Monolith

Although Big Tech is often discussed as if it's a uniform experience, that assumption doesn't hold up under scrutiny. The lesson clarifies that these companies, and even teams within them, can differ dramatically in culture, structure, and day-to-day work.

- **Big Tech is not a monolith**: Companies like Google, Amazon, Meta, Apple, and Microsoft may appear similar, but each has distinct norms and quirks. For example, Apple and Amazon differ significantly in operating style.
- **Team-level variation is substantial**: Within any large company - especially one with thousands of engineering teams—there’s huge internal variability. At Google, for instance, it’s unrealistic to expect all teams to operate the same way.
- **Meta as a case study in divergence**: Meta operates almost like four separate companies due to its major acquisitions (Instagram, WhatsApp, Oculus), each with its own leadership structure and internal culture.
- **Caveat for the audience**: The content that follows reflects common experiences shared by 70–80% of Big Tech engineers, but there will be outliers. Some parts may resonate; others may not - and that’s normal.

What Exactly Is Big Tech?

While many people associate "Big Tech" with the largest household names in the industry, the definition can, and should, be broader. This lesson provides a useful lens for identifying companies that operate like Big Tech, even if they’re not part of the traditional FAANG group.

- **Traditional Big Tech**: Commonly refers to the largest companies by market cap - *Microsoft, Google, Amazon, Apple, and Meta*. Sometimes Netflix is included (as in “FAANG”), but it's structurally different, e.g. Netflix historically had no engineering levels and treated everyone as senior engineers.
- **Critique of the FAANG Acronym**: Netflix is singled out as not entirely representative of "Big Tech" norms, being smaller in scale and structurally more unique than the others.
- **Broader Definition**: Companies with *$50B+ market cap* and *2,500+ engineers*, along with similar performance expectations, leveling systems, and engineering culture as the Big Five, should also be considered Big Tech. This includes companies like *Uber, Airbnb, and Stripe*.
- **Why This Matters**: Focusing only on the top 5–6 companies can be limiting. Many other companies now offer equivalent opportunities in terms of compensation, growth potential, and engineering culture, especially as they reach scale.

This broader perspective is helpful when evaluating job options and team culture - not all Big Tech companies are the usual suspects.

Machine Learning System Design Ask & Learn

**Event description**

Join us remotely for an interactive Q&A with Ilya Reznik—Founder of MLEPath, veteran ML engineer with nearly 15 years at Meta, Twitter, and Adobe, and interviewer of hundreds of real-world ML system design (MLSD) interviews (plus nearly 1,000 mock sessions in the last two years). Whether you’re tackling your first MLSD interview or leveling up for senior roles.

- **Core frameworks & approaches**: how to structure your end-to-end design, balance scalability, latency, cost, and reliability
- **Key components & trade-offs**: data pipelines, model serving, feature stores, monitoring, and A/B testing
- **Real-world insights**: pitfalls Ilya’s seen candidates fall into—and what top performers do differently
- **Live feedback**: get tailored advice on designing everything from recommendation systems to real-time anomaly detection

Perfect for ML engineers aiming to land roles at FAANG, startups, or anywhere that demands rock-solid system design chops. Come ready with your toughest questions—and leave with a clear, actionable roadmap for your next MLSD interview.

Learning From Mistakes

In this section, we reflect on how **mistakes and operational defects** became valuable sources of new input metrics at Amazon. Through a disciplined **Correction of Errors (CoE)** process, we turned setbacks into opportunities for learning, system improvement, and metric discovery.

### Key Takeaways:

- **We embraced mistakes as learning opportunities**: We openly discussed errors and failures—not to assign blame, but to understand what went wrong and how to prevent it next time.
- **We asked predictive questions**: For every defect, we asked: *What metric could have predicted or prevented this?* Often, the answer revealed a missing input metric that we needed to start tracking.
- **We built systems to measure what we were missing**: Once we identified a critical input metric, we prioritized building the tools and infrastructure to capture it—and ensured it was reviewed in our Weekly Business Review (WBR).
- **We used a structured CoE process**: The CoE included five steps—identifying the error, documenting and responding, root cause analysis (often using the “Five Whys”), developing corrective actions, and then implementing and monitoring those changes.
- **We integrated input metrics into operational reviews**: Many of the metrics that emerged from the CoE process became part of our regular metric reviews, helping us catch future problems early and improve reliability across systems.

This practice helped us create a culture where **defects became a trigger for innovation and deeper operational control**, not just patchwork fixes.

To dive deeper into Input Metrics Mastery and learn more from Bill and Colin, follow these links:

- Take the full course at their website: <https://workingbackwards.com/>
- Buy the book: <https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595>
- Bill's LinkedIn: <https://www.linkedin.com/in/bill-carr/>
- Colin's LinkedIn: <https://www.linkedin.com/in/colinbryar/>

Mine Customer Support Data

We expand beyond metrics mapping and customer experience mapping by introducing **additional, nuanced techniques** to help us continuously refine our input metrics. These customer- and defect-driven approaches give us real-world signals that are often overlooked—but are rich with opportunities for improvement.

### Key Takeaways:

- **We believe customer and shareholder interests are aligned**: At Amazon, we were driven by the conviction that obsessing over customers naturally serves the long-term interests of shareholders. This philosophy shaped our approach to metrics and improvement.
- **We treat every customer interaction as a source of insight**: Whether the "customer" is a buyer on Amazon or an internal team we support, we use their feedback to uncover meaningful input metrics that help us improve service and outcomes.
- **We mine customer support data as a diagnostic tool**: We tracked the top reasons customers contacted support—questions like “Where’s my stuff?” or complaints like “You sent the wrong item”—and used these to create new metrics such as “the switcheroo,” which measured item mix-ups.
- **We made problem frequency visible and actionable**: These contact reasons and metrics were reviewed weekly in our WBR, ensuring we remained focused on resolving the most impactful customer issues.
- **We talked directly to customer-facing teams**: We routinely engaged with customer support representatives to gather firsthand insights about recurring pain points by category—adding human intelligence to our data-driven approach.

These additional techniques may not generate as many metrics as mapping exercises, but they provide powerful context and depth to our understanding of what truly matters to customers.

To dive deeper into Input Metrics Mastery and learn more from Bill and Colin, follow these links:

- Take the full course at their website: <https://workingbackwards.com/>
- Buy the book: <https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595>
- Bill's LinkedIn: <https://www.linkedin.com/in/bill-carr/>
- Colin's LinkedIn: <https://www.linkedin.com/in/colinbryar/>

Amazon Metrics Map Example

In this lesson, we walk through **two core techniques—Metrics Mapping and Customer Experience Mapping**—that helped us systematically discover and define the input metrics that truly matter. These methods gave us a more granular, customer-focused way to understand and improve our business performance at Amazon.

### Key Takeaways:

- **We used Metrics Mapping to break down strategic goals**: Starting with broad objectives like lowering cost structure, we recursively drilled down to discover the specific drivers (e.g., shipping cost, pick cost, forecast accuracy) and converted them into measurable input metrics.
- **We cast a wide net during brainstorming**: In the early stages of metrics mapping, we didn’t worry about whether we could measure something yet or whether it was immediately useful. Our priority was to be comprehensive.
- **We built Customer Experience Maps to capture every user touchpoint**: From site entry to search, checkout, and delivery, we identified every customer interaction and defined metrics for speed, quality, and cost—measured both from the customer's and Amazon’s point of view.
- **We stayed grounded in the customer’s perspective**: Instead of focusing on internal outcomes like revenue per page view, we measured how intuitive, fast, and helpful each experience was for the customer, ensuring our metrics aligned with long-term value creation.
- **We operationalized customer obsession**: These techniques gave us a structured, measurable way to uphold our customer-obsessed culture. Other companies have found these frameworks to be transformative in how they assess and improve their own customer experience and operations.

To dive deeper into Input Metrics Mastery and learn more from Bill and Colin, follow these links:

- Take the full course at their website: <https://workingbackwards.com/>
- Buy the book: <https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595>
- Bill's LinkedIn: <https://www.linkedin.com/in/bill-carr/>
- Colin's LinkedIn: <https://www.linkedin.com/in/colinbryar/>

Define

In this section, we explain how we at Amazon adopted the **DMAIC process**—a structured Six Sigma methodology—to bring clarity and control to our increasingly complex operations. This approach helped us stay focused on what drives business performance, even as we scaled globally and diversified our offerings.

### Key Takeaways:

- **We turned to Six Sigma to manage complexity**: As Amazon grew from a book retailer into a multi-product, international company, we needed a structured way to measure, monitor, and improve our processes. Six Sigma’s DMAIC framework offered exactly that.
- **DMAIC became our operational foundation**: The five steps—**Define, Measure, Analyze, Improve, Control**—allowed us to break down complex systems into manageable parts, identify input metrics, and drive improvements with precision.
- **We embraced Donald Wheeler’s philosophy**: Following his principle that understanding variation is key to improvement, we focused on how changing inputs affects outputs, aligning our culture around continuous improvement.
- **We built clarity into invisible systems**: Since much of Amazon’s operations (software, fulfillment, logistics) were either virtual or distant, we created standard definitions and measurements to make the system’s performance tangible and actionable.
- **We aligned every part of our system to inputs**: From product selection and pricing to software reliability and delivery speed, we learned that managing the inputs across all departments ultimately shaped our outputs like revenue and customer satisfaction.

To dive deeper into Input Metrics Mastery and learn more from Bill and Colin, follow these links:

- Take the full course at their website: <https://workingbackwards.com/>
- Buy the book: <https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595>
- Bill's LinkedIn: <https://www.linkedin.com/in/bill-carr/>
- Colin's LinkedIn: <https://www.linkedin.com/in/colinbryar/>

System Design Meeting Non-Participation

In this exercise, we examine a common team dynamic issue: several team members remain silent during design review meetings. This scenario challenges us to improve team engagement and collaboration—core to a manager’s ability to create sustainable performance change.

- We can **create psychological safety** so team members feel comfortable speaking up. This might involve setting new norms, encouraging questions, or addressing interpersonal dynamics that suppress contribution.
- We may need to **facilitate structured participation**, such as assigning roles, using round-robin feedback formats, or pre-assigning topics so everyone has time to prepare and contribute.
- We should **investigate root causes**—whether it's confidence, lack of clarity, or a dominant voice in the room—and address them through coaching or team norms.
- This is a chance to **foster inclusion and amplify diverse perspectives**, making the team more effective and innovative in its design process.
- By creating a culture of engagement, we **raise the overall output quality** and ownership across the team—an impactful and sustainable delta.

If you want to learn more from Gilad, he shares free leadership advice daily on [LinkedIn](https://www.linkedin.com/in/giladnaor/?utm_source=taro&utm_medium=course&utm_campaign=cta) and weekly on the[ δeltas newsletter](https://posts.managementdeltas.com/?utm_source=taro&utm_medium=course&utm_campaign=cta)

Missed Estimates

In this segment, we’re challenged with a new scenario: an individual contributor consistently misses their own estimates. This is our opportunity to apply the essence of management—creating positive, sustainable change in organizational performance.

- We frame the issue not just as a problem to fix, but as an opportunity to **create a delta** in this person’s effectiveness and the team’s overall reliability.
- Our goal is to **understand the root cause**—is it due to optimism bias, poor time management, lack of clarity, or systemic issues in the planning process?
- We can introduce **structured changes**: better estimation techniques, mentoring, regular retrospectives, or adjusting sprint planning to account for variability.
- We aim for improvements that are **sustainable**—equipping the individual with tools or frameworks they can continue to use independently.
- As always, our success isn’t in reacting to the problem but in **proactively shaping a better outcome** that would not have happened without our involvement.

If you want to learn more from Gilad, he shares free leadership advice daily on [LinkedIn](https://www.linkedin.com/in/giladnaor/?utm_source=taro&utm_medium=course&utm_campaign=cta) and weekly on the[ δeltas newsletter](https://posts.managementdeltas.com/?utm_source=taro&utm_medium=course&utm_campaign=cta)

Gilad’s Take: Motivated IC Auto-Didact

In this video, we deepen our understanding of the manager's role by applying it to a scenario with a high-performing, self-motivated team member. The key takeaway is that our value as managers lies not in the growth that would happen without us, but in the change we actively create.

- We remind ourselves that our **job is to create a delta**—a positive, sustainable improvement that wouldn’t have happened otherwise.
- We can influence growth in **two major ways**: by increasing its **efficiency** (helping the individual grow faster) and its **effectiveness** (guiding them toward more impactful areas of development).
- Efficiency may involve assigning growth-aligned projects, introducing mentors, or curating resources that accelerate learning.
- Effectiveness may require **redirecting energy** toward skills with greater business impact, such as shifting from technical specialization to leadership development.
- Ultimately, we commit to **seeking out and enabling the deltas**—changes we directly cause—because that's where our impact as managers truly lies.

If you want to learn more from Gilad, he shares free leadership advice daily on [LinkedIn](https://www.linkedin.com/in/giladnaor/?utm_source=taro&utm_medium=course&utm_campaign=cta) and weekly on the[ δeltas newsletter](https://posts.managementdeltas.com/?utm_source=taro&utm_medium=course&utm_campaign=cta)

What Do Managers Do?

Part Two of the *Essence of Management* course invites us to deeply reflect on the core question: **What do managers actually do?**

- We are encouraged to pause and **write a one-line summary** of the manager’s role—not our personal job, but the purpose of the managerial function itself.
- This section emphasizes **active engagement**, urging us to think, reflect, and put ideas into our own words rather than passively consuming content.
- The reflection exercise sets the foundation for the next module, where we’ll compare our answers to a more structured definition of management.

If you want to learn more from Gilad, he shares free leadership advice daily on [LinkedIn](https://www.linkedin.com/in/giladnaor/?utm_source=taro&utm_medium=course&utm_campaign=cta) and weekly on the[ δeltas newsletter](https://posts.managementdeltas.com/?utm_source=taro&utm_medium=course&utm_campaign=cta)

For SWE To ML Transitioners

In this final section on preparation strategy, we focus on how to transition successfully from software engineering into machine learning. Drawing on real experiences, we highlight practical, effective ways to stand out.

- **Lead with your strengths**: We already bring strong system design, coding, and production skills—qualities ML teams highly value. Hiring managers often prefer engineers moving into ML over scientists moving into engineering.
- **Leverage your current role**: Instead of relying only on side projects, we can grow by contributing to ML efforts at work—like model deployment, pipelines, or feature engineering.
- **Be selective with side projects**: One well-scoped project with clear business impact is far more compelling than several small tutorials.
- **Demonstrate your learning journey**: Show, don’t just tell—mention coursework, hands-on coding, and real applications of ML in your work.
- **Be honest and self-aware**: Interviewers appreciate curiosity and a growth mindset more than perfection. Let’s share where we are, what we’re learning, and how we’re applying it.

If you want to learn even more from Yayun:

- Book 1 on 1 career guidance with her here: <https://calendly.com/your-friend-yayun/1on1>
- Follow her on LinkedIn: <https://www.linkedin.com/in/yayunjin/>

ML System Design Framework

In this segment, we’re introduced to a powerful **5-part framework** for approaching ML system design interviews. This structured method ensures we address both technical depth and strategic thinking—key traits interviewers look for in strong candidates.

- **1. Problem Navigation**: We start by asking clarifying questions to understand functional and non-functional requirements, product goals, infrastructure constraints, and user experience. We define success metrics, state our assumptions, and frame the scope clearly.
- **2. High-Level Design**: We map business goals to ML objectives, walk through core system components (data ingestion, processing, modeling, inference, monitoring), and identify what needs to run in real-time versus batch.
- **3. Data Strategy & Feature Engineering**: We explain how data is collected and labeled, ensure data quality, and outline our approach to creating, storing, and updating features—including how we handle feature freshness and online/offline processing.
- **4. Modeling Approach**: We present specific model choices with trade-offs in interpretability, scalability, and accuracy. We detail training methods (batch, online, hybrid), address data distribution shifts, and outline infrastructure needs.
- **5. Evaluation, Deployment & Monitoring**: We describe offline evaluation strategies, deployment infrastructure (latency, model size, caching), and our plan for monitoring model health (drift, degradation) while tying results back to business KPIs.

Using this framework helps us think like **system-level ML engineers**, ensuring we cover everything from high-level goals to production-readiness with clarity and confidence.

If you want to learn even more from Yayun:

- Book 1 on 1 career guidance with her here: <https://calendly.com/your-friend-yayun/1on1>
- Follow her on LinkedIn: <https://www.linkedin.com/in/yayunjin/>

Role-Specific System Design Focus

In this part of the system design section, we explore how **ML system design interviews vary depending on the role and level** we’re applying for. Knowing what’s emphasized helps us tailor our preparation strategically.

- For **product-focused ML roles**, we focus on modeling choices, feature engineering, and connecting ML decisions to tangible business impact.
- **ML infrastructure roles** emphasize architecture, scalability, reliability, and serving systems—including distributed training and feature stores.
- **Research-oriented roles** dive into experimentation frameworks, novel modeling techniques, and how to transition prototypes into production.
- In **ML generalist roles** (common at startups or smaller teams), we’re expected to demonstrate a balanced understanding across the full ML lifecycle.
- Importantly, **interview expectations are tied more to seniority level than company size**—a senior role at a startup may involve deeper system questions than a junior role at a large tech company.

Next, we’ll learn a system design framework that can flex across these scenarios and help us organize our thinking effectively.

If you want to learn even more from Yayun:

- Book 1 on 1 career guidance with her here: <https://calendly.com/your-friend-yayun/1on1>
- Follow her on LinkedIn: <https://www.linkedin.com/in/yayunjin/>

Model Training

In this segment, we cover **model training**, a phase where many candidates fall into autopilot. To stand out, we need to show thoughtfulness, adaptability, and a clear connection between our choices and the problem at hand.

- **Mediocre performance** involves picking a default model (e.g., logistic regression or random forest), using out-of-the-box settings with no tuning or justification.
- **Strong candidates** choose models deliberately, explaining how their selection fits the **data characteristics, business goals, or system constraints**.
- We improve performance through **hyperparameter tuning**, using techniques like grid search or informed manual adjustments based on EDA insights.
- When appropriate, we apply **ensemble methods** (e.g., boosting, bagging, stacking) to push performance further.
- Most importantly, we demonstrate that our modeling choices are **intentional and grounded in context**, not just rote or random experimentation.

If you want to learn even more from Yayun:

- Book 1 on 1 career guidance with her here: <https://calendly.com/your-friend-yayun/1on1>
- Follow her on LinkedIn: <https://www.linkedin.com/in/yayunjin/>

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.