Taro Book Club: Designing Data Intensive Applications - Chapter 5 (Replication)

Topic: Chapter 5 - Replication

Session led by: [Rohit Katyal](https://www.linkedin.com/in/rohitkatyal/)

In this #taro-bookclub discussion, we'll be talking about Chapter 5 of [**"Designing Data-Intensive Applications"**](https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321) by Martin Kleppmann.

Here's the agenda:

- Let’s get to know each other with some quick introductions.
- We’ll break down and discuss the key concepts from Chapter 5.
- There will also be time for any questions and answers you might have.

Please send your questions ahead of time to [**Rohit Katyal**](https://www.linkedin.com/in/rohitkatyal/) in the [**Taro Premium**](https://www.jointaro.com/membership/) Slack, so that they can be included in the discussion.

Get ready for another engaging and informative session!

Paper Reading: Self-supervised Vision Transformers (Foundational Model)

Session led by [Mandar Deshpande](https://www.linkedin.com/in/mandardeshpande1995/)

Dino is a self-supervised learning approach for computer vision tasks. It leverages vision transformers without using any labeled data. Dino v2 introduces several improvements over its predecessor, enhancing performance and scalability. It achieves state-of-the-art results on various benchmarks. Notably, Dino v2 demonstrates strong performance on downstream tasks such as image classification and object detection.

We will be walking through

- Basics of computer vision
- Self supervised learning
- ViT (vision transformers)
- DINO
- DINO v2 model

Paper link - [**https://arxiv.org/abs/2304.07193**](https://arxiv.org/abs/2304.07193)

[Event link](https://www.jointaro.com/event/paper-reading-dino-v2-ie-foundational-model-for-computer-vision/)

Taro Book Club: Designing Data Intensive Applications - Chapter 3

Topic: Chapter 3 - Storage and Retrieval

In this #taro-bookclub discussion, we talk about Chapter 3 of [**"Designing Data-Intensive Applications"**](https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321) by Martin Kleppmann.

Here's the agenda:

- Let’s get to know each other with some quick introductions.
- We’ll break down and discuss the key concepts from Chapter 3.
- There will also be time for any questions and answers you might have.

Thanks to [**Suraj Singh**](https://www.linkedin.com/in/suraj-singh-495b192b/) and [**Sangavi Pari**](https://www.linkedin.com/in/sangavi-pari/) for leading this session!

Ace Your Tech Interview As A Software Engineer [Part 18] - The 3 Core Interview Stages

So a tech company has decided to not throw your resume straight in the trash and are giving you a chance. How does the interview process work? This lesson teaches you:

- What the first round of *screeners* is
- What the second round of *phone screens* is (and the history behind the term)
- What the final round of onsites is (and the history behind the term)

Life After PIP: The Ultimate Guide To Navigating A PIP

One of the biggest concerns for anyone who has received a PIP is about how it may effect their future job prospects. The answer is, no, a **PIP does not need to follow you around**. You can (and will) find a fresh start and a thriving career if you want it. 

Remember, a PIP is about **both** employee and employer. When you change jobs, your employer is changing, so the situation leading to the PIP is very different.

As you reflect on your next role, it’s worthwhile to allocate some time to reflect: 

- Collect feedback from others: at the minimum, save a copy of your PIP and figure out what feedback there is transferable to another job.
- Collect feedback from yourself: Write down your reflections: what did you enjoy (or not) about your past work experience. What types of projects and people were fun for you?

Successful Disagreements for Software Engineers

[**Ryan Alexander Wiens**](https://www.linkedin.com/in/ryan-wiens/) is an experienced English communication coach who has worked with more than 70 SWEs. In this workshop, he shares the nuances of expressing disagreement in a constructive and respectful manner. With years of coaching under his belt, Ryan understands the challenges faced by engineers when English is not their first language.

**Key Takeaways:**

- Understand the phases of a diplomatic disagreement.
- Interactive exercises including breakout rooms and real-time Q&A.
- A phrase bank for participants to use in their daily communications.
- Practice scenarios on common workplace topics for SWEs.

Ryan discussed the importance of including the right words and phrases, clear thinking, defined outcomes, and effective communication frameworks. He underscored the need for skills such as active listening, presenting new ideas, building rapport, and confidence in practical application. Ryan also led a discussion on the topic of successful disagreement at work, suggesting that the level of comfort with disagreement might depend on the situation and culture of the workplace.

**Disagreement's Importance in the Workplace**

Ryan emphasized the importance of expressing disagreement in the workplace, as it leads to better decision making, avoids useless work, and creates opportunities for learning and growth. They stressed the need for disagreement to be done respectfully, keeping it impersonal and listening to others before forming a response. Additionally, they suggested picking battles wisely and staying calm and respectful. 

**Constructive Disagreement Framework**

Ryan introduced a framework for constructive disagreement that emphasized respect, evidence-based opinions, and softening disagreements. He encouraged attendees to suggest phrases to use when expressing disagreements respectfully. Instead of using the word "but" in conversations, Ryan suggests alternatives to soften disagreements. At the same time, you should own your disagreements and remove bias from the message. In situations of imbalanced authority, Ryan advised picking battles carefully and being strategic about which battles to pursue.

Ryan led a group activity aimed at fostering disagreement resolution skills. Find the [worksheet here](https://drive.google.com/file/d/1G0As8QS7MZ4O0PTCeDEPeSborW9ahU_m/view?usp=sharing).

Additional resources: 

- [\[Masterclass\] How To Build Deep Relationships Quickly In Tech](https://www.jointaro.com/lesson/tyaPFMXPoz2pmzB7OVzt/masterclass-how-to-build-deep-relationships-quickly-in-tech/)
- [\[Masterclass\] How To Work Better With Your Engineering Manager](https://www.jointaro.com/lesson/2PbJb2fuqF3iMHy57eEg/masterclass-how-to-work-better-with-your-engineering-manager/)

Why Being A Good Interviewer Is So Hard

Every software engineer know what it's like to be interviewed, but few know what it's like being on the other side of the table giving the interview. It's important to understand this flipped perspective as it will help you resonate with the interviewer.

Here are the core points from the video:
- A good interviewer has 2 core goals:
  - Get signal on the candidate's abilities
  - Provide a great candidate experience
- Unfortunately, these 2 things usually conflict. In order to get good signal, the candidate often times has to struggle to solve a tough problem. Struggle is generally not associated with good experience.
- *A truly good interviewer makes it so that the candidate enjoyed their round even if they didn't pass.* This means that you need to get signal in a positive way by building the candidate up and bringing out their true skills without solving too much of the problem for them.

Related resources:
- [[Taro Top 10] Effective Interview Prep](https://www.jointaro.com/playlist/HLBYxJI7D1j8STolrwum/)
- [[Masterclass] How To Ace Your Big Tech Interview - Data Structures And Algorithms](https://www.jointaro.com/lesson/V4sTACzfOh22nMVcUV3w/masterclass-how-to-ace-your-big-tech-interview-data-structures-and-algorithms/)
- [[Masterclass] How To Ace Your Big Tech Interview - System Design](https://www.jointaro.com/lesson/J3I9fTW9ulr6T9KjxpqY/masterclass-how-to-ace-your-big-tech-interview-system-design/)
- [How Alex Got Into Meta With 0 Prior LeetCode Experience](https://www.jointaro.com/lesson/ZYiTbN21FsqFxFdpwt5a/how-alex-got-into-meta-with-0-prior-leetcode-experience/)

The Cardinal Sin Of Management: Micromanaging

This segment outlines why micromanagement is a hallmark of poor engineering leadership and how effective managers empower their teams instead of controlling them. It offers a comprehensive look at how hands-off, trust-based leadership enables better team performance and growth.

- **Micromanagement is a red flag**: Hovering over engineers’ work or constantly asking for status updates wastes time, erodes trust, and stifles ownership.
- **Effective managers lead through trust and empowerment**: Autonomy allows engineers to make decisions and own outcomes, with structured check-ins (e.g., weekly or bi-weekly) to stay aligned.
- **Staying out of technical weeds is critical**: A manager's role should focus on people, not code reviews, engineering meetings, or day-to-day task assignments—those should be handled by tech leads or the engineers themselves.
- **Micromanagement creates systemic risks**: It builds dependency, slows down team velocity, and makes the manager a single point of failure. If the manager leaves, the team may lack the tools or confidence to function independently.
- **Lack of trust leads to poor career growth**: Engineers under micromanagement are less likely to take initiative or learn leadership skills, hindering their path to promotion and long-term development.

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/>

Building A Metrics Map

In this lesson, we explore **practical techniques** for identifying the input metrics that matter most. Through methods like **metrics mapping** and **customer experience mapping**, we gain a clearer, more quantitative view of what drives our business forward—especially from the customer’s perspective.

### Key Takeaways:

- **We prioritize input metrics and customer interactions**: Too often, businesses rely heavily on output metrics. We recommend looking deeper into input metrics—particularly those tied to customer behavior and experience.
- **Metrics Mapping helps us discover drivers of key metrics**: We start with a business goal or known metric, then recursively ask what drives it and how we can measure those drivers. This technique reveals a broad and useful set of input metrics.
- **The process is recursive and comprehensive**: We drill down from each metric or goal until we can’t go any further, building an extensive network of quantifiable drivers. Repeating metrics across branches is fine—what matters is completeness.
- **The end goal is a flat, exhaustive list of metrics**: While the mapping exercise may begin as a hierarchy, we ultimately compile all the discovered metrics into a single, non-hierarchical list for practical use and monitoring.
- **Finding input metrics is an ongoing process**: This isn’t a one-time task. We continuously revisit and expand our metric set as our business, goals, and customer needs evolve.

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/>

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/>

Notebook Interview Example: Ad Click Prediction

In this final part of the section, we bring all the core concepts together through a realistic, end-to-end ML interview example. The walkthrough demonstrates how to apply best practices across the entire notebook round—from EDA to model evaluation—with clarity, intention, and real-world relevance.

- In **EDA**, we go beyond surface checks by exploring unique value counts, visualizing target distribution, spotting class imbalance, and identifying trends like CTR by device type—ensuring every insight informs downstream modeling.
- In **feature engineering**, we thoughtfully create new features (e.g., age buckets, time-of-day flags), handle multicollinearity, and tailor transformations based on domain intuition, not just standard recipes.
- During **model training**, we justify our choice of random forest for its robustness and interpretability, apply cross-validation and stratified splits, and run grid search for tuning—demonstrating intention behind every step.
- In **evaluation**, we use metrics that align with the problem (precision, recall, F1, AUC-ROC, confusion matrix) and interpret results in context, showing we understand the real-world stakes of false positives and negatives.
- For **follow-up questions**, we proactively discuss improvements (e.g., deeper models, richer features), production monitoring (CTR by segment, drift detection), and handling class imbalance—proving we think like end-to-end ML practitioners, not just coders.

This example illustrates how to move from “checking boxes” to demonstrating thoughtful, production-aware problem-solving under real interview conditions.

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/>

Feature Engineering

In this part of the course, we focus on **feature engineering**, a critical area where interviewers differentiate between average and exceptional ML candidates. This is our opportunity to show not just technical skill, but creativity and judgment.

- **Mediocre feature engineering** relies on basic, mechanical steps—like one-hot encoding categoricals or normalizing numericals—without much customization.
- **Stellar candidates go further**, creating new features from raw data (e.g., extracting time-of-day from timestamps, or combining variables into meaningful interactions).
- We show thoughtfulness by **dropping irrelevant features**, checking for **multicollinearity**, and aligning features closely with the problem's objectives.
- We demonstrate versatility by handling **complex data types**—such as transforming freeform text, working with embeddings, or aggregating time series effectively.
- Ultimately, we recognize that **feature engineering can matter more than the model itself**, and our job is to shape the data so that the model can truly learn from 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/>

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.