Become An Engineer Influencer [Part 8] - Bottom-Funnel Channels

Become An Engineer Influencer [Part 5] - Top-Funnel Channels

Become An Engineer Influencer [Part 4] - Strategy #2: Social Media is a Sales Funnel

Learnings from SWE to Senior SWE at LinkedIn

*If you're not part of Taro Premium, join with Paras's link to receive a discount: [**https://www.jointaro.com/r/parass876/**](https://www.jointaro.com/r/parass876/)*

Jumping into Software Engineering from a non-technical background can be challenging, but it’s far from impossible. Join us for an inspiring session with [**Paras Sidhu**](https://www.linkedin.com/in/paras-sidhu/), who not only transitioned from mathematics into software engineering, but also cracked big tech in just 2 years and earned a promotion to Senior Software Engineer within another 2 years.

### **What to Expect**

1. **Actionable Tips**: Paras will share his experiences and actionable tips on his journey from Software Engineer to Senior Software Engineer, providing practical examples that you can apply to your own career path.
2. **Insightful Learnings**: Gain valuable insights into how to navigate and excel in big tech, even if you come from a non-technical background.
3. **Q&A Session**: Don’t miss the chance to ask your burning questions and get personalized advice from someone who has successfully made the transition and accelerated his career.

Mark your calendars and prepare to be inspired! Don’t miss out on this chance to learn from Paras' unique journey and gather tips that could propel your own career forward.

Looking forward to seeing you there!

Taro Book Club: Designing Data Intensive Applications - Chapter 6 (Partitioning)

Topic: Chapter 6 - Replication

Session led by: [Bhavana Gannu](https://www.linkedin.com/in/bhavanagannu/) and [Suraj Singh](https://www.linkedin.com/in/suraj-singh-495b192b/)

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

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!

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

Senior Managers Adam Admires

In this lesson, **Adam Ernst**, Software Engineer at **Meta**, reflects on the engineers he most admires throughout his career and the qualities that set them apart. Rather than attributing success to a single skill, Adam highlights how exceptional engineers excel in different ways—from writing code and debugging complex systems to communicating ideas, launching new initiatives, and aligning teams. He emphasizes that there is no single blueprint for becoming a high-impact Individual Contributor.

- **Exceptional Engineers Have Different Superpowers:** Adam highlights colleagues who excel in distinct areas, including high-volume coding, deep debugging, launching ambitious projects, technical communication, and organizational alignment. There is no single path to becoming an outstanding engineer.
- **Leverage Your Strengths While Appreciating Others':** Adam recognizes that his own strengths lie in hands-on engineering, while others surpass him in areas such as cross-team leadership, strategic communication, and stakeholder management. Great engineering organizations thrive because individuals bring complementary skills.
- **Learn from Role Models, Not Copies:** Rather than trying to emulate one person completely, Adam encourages engineers to study the specific qualities they admire in others—whether it's technical depth, problem-solving, writing, or leadership—and incorporate those strengths into their own unique career path.

Original podcast link: [**https://www.youtube.com/watch?v=YA_OYJF3Mmw**](https://www.youtube.com/watch?v=YA_OYJF3Mmw)

How To Handle a Failed Project

In this lesson, **Adam Ernst**, Software Engineer at **Meta**, reflects on the difficult decision to end **ComponentScript** after realizing it was not achieving the impact it was designed for. He discusses how performance reviews provided honest feedback, why responsibly shutting down a project can strengthen rather than damage your reputation, and the importance of recognizing when persistence becomes counterproductive. Adam offers valuable advice for engineers navigating ambitious projects that may not succeed.

- **Performance Reviews Should Inform, Not Define You:** Receiving a "Meets Most" performance rating helped Adam recognize that ComponentScript was no longer delivering the expected impact. Rather than viewing the feedback as a failure, he used it as a signal to reassess the project's direction.
- **End Projects Responsibly:** Instead of abandoning ComponentScript, Adam personally helped teams migrate to alternative solutions, removed the framework entirely from the codebase, and documented the lessons learned. Taking ownership of the cleanup earned trust and demonstrated strong engineering leadership.
- **Listen to Early Warning Signs:** Looking back, Adam realized he had sensed for nearly a year that the project was losing momentum. His instinct was to write more code in hopes of turning things around, but he later learned that recognizing when to pivot—or stop altogether—is just as important as technical execution.

Original podcast link: [**https://www.youtube.com/watch?v=YA_OYJF3Mmw**](https://www.youtube.com/watch?v=YA_OYJF3Mmw)

The Story Behind Component Script

In this lesson, **Adam Ernst**, Software Engineer at **Meta**, reflects on one of the most ambitious—and ultimately unsuccessful—projects of his career: **ComponentScript**, a cross-platform UI framework designed to unify iOS and Android development. Although the framework was technically sophisticated and solved many engineering challenges, it failed to gain widespread adoption. Adam shares the key lessons he learned about product strategy, developer adoption, and why technical excellence alone is not enough to ensure success.

- **Technical Success Doesn't Guarantee Product Success:** ComponentScript delivered strong technical capabilities—including type safety, seamless integration with native frameworks, and bidirectional interoperability—but these strengths were not enough to drive widespread adoption.
- **Know Your Users and Focus Your Strategy:** One of the project's biggest shortcomings was failing to identify a clear target audience. By trying to appeal to both native mobile engineers and JavaScript developers, the framework ultimately resonated with neither. Adam also learned the importance of concentrating efforts on winning over a single committed team before attempting broad adoption.
- **Embrace Failure as a Learning Opportunity:** Adam openly documented ComponentScript's failure through a detailed postmortem, using the experience to share hard-earned lessons with the engineering community. His reflection highlights the value of transparency, continuous learning, and recognizing that successful engineering requires balancing technical excellence with usability, adoption, and organizational alignment.

Original podcast link: [**https://www.youtube.com/watch?v=YA_OYJF3Mmw**](https://www.youtube.com/watch?v=YA_OYJF3Mmw)

Getting Promoted to Senior Staff Engineer

n this lesson, **Adam Ernst**, Software Engineer at **Meta**, shares the story behind **ComponentKit**, the declarative UI framework that played a pivotal role in his promotion to **Senior Staff Engineer (E7)**. Faced with a rapidly growing Facebook News Feed that was becoming difficult to maintain, Adam and his team reimagined iOS development by adapting the core ideas of React for native mobile applications—years before SwiftUI and React Native became mainstream. He also discusses how he overcame resistance to a radically new approach and the leadership lessons he learned while driving large-scale technical change.

- **Reinventing UI Architecture at Scale:** To address performance issues, crashes, and increasing complexity in Facebook News Feed, Adam developed **ComponentKit**, a declarative UI framework inspired by React that improved maintainability, rendering performance, and developer productivity long before similar technologies became industry standards.
- **Winning Adoption Through Evidence and Collaboration:** Convincing engineers to embrace a new programming paradigm required more than technical excellence. Adam demonstrated tangible improvements through cleaner code and better performance, leveraged trusted allies to advocate for the framework, and found compromises that incorporated ideas from competing internal projects.
- **Strong Conviction with Practical Flexibility:** Adam remained confident that ComponentKit was the right solution for Facebook's highly dynamic feed while acknowledging that no architecture is universally optimal. His experience highlights the importance of understanding trade-offs, tailoring solutions to the problem at hand, and leading innovation through collaboration rather than ideology.

Original podcast link: [**https://www.youtube.com/watch?v=YA_OYJF3Mmw**](https://www.youtube.com/watch?v=YA_OYJF3Mmw)

What Are Advanced Concepts I Should Know?

In this lesson we talk about how to effectively prepare for AI-assisted coding interviews, with a focus on shifting your study habits to match what these interviews actually test.

- **Learn the "why" before the "how"** — rather than drilling implementations, focus on understanding the canonical problem each data structure solves and practice explaining it in one sentence out loud; with AI handling the code, being unable to independently identify the right approach is now much harder to hide or compensate for.
- **Know the common gotchas for each pattern** — every classic structure has a specific edge case trap (e.g. the `is_end` flag in a trie, recency updates in an LRU cache, off-by-one errors in sliding windows); getting familiar with these upfront dramatically speeds up your ability to verify AI-generated output during the interview.
- **Practice reading code, not just writing it** — since interviews now involve more time spent reading starter code and verifying AI output than typing from scratch, deliberately train yourself to mentally trace logic quickly by reading existing solutions online or having AI generate code for problems you already understand, then tracing through them by hand.

How Should I Practice For These Interviews?

In this lesson we talk about how AI is making previously time-prohibitive advanced data structures and algorithms newly relevant in coding interviews, and what that means for how you should prepare.

- **AI unlocks harder concepts by handling the boilerplate** — complex structures like tries, heaps, and LRU caches were rarely testable in a 45–60 minute interview because implementation alone could eat up 15–20 minutes; with AI generating that scaffolding in seconds, interviewers can now reasonably include them, making them worth studying once you've solidified the fundamentals.
- **What you actually need to demonstrate has shifted** — since AI handles much of the implementation, your value lies in recognizing when a given data structure is the right tool, clearly articulating *why* it helps (e.g. "a trie eliminates the factor of M by checking all patterns simultaneously through shared prefix traversal"), and writing precise prompts that reflect that understanding.
- **Master the basics first, and don't over-rotate on this** — the vast majority of interviews (roughly 95%) will not require these advanced concepts, so treat this as the final 5–10% polish layer, not the foundation; verification of AI output remains just as critical here as everywhere else in the interview.

How Do I Talk Without Sounding Chaotic?

In this lesson we talk about how to communicate effectively during an AI-assisted coding interview without sounding scattered, frantic, or going completely silent.

- **Avoid the two extremes** — narrating every single keystroke comes across as junior, while going silent for several minutes leaves the interviewer in the dark; the goal is to sound controlled and intentional somewhere in between.
- **Choose the communication model that fits your thinking style** — Model A is light, continuous commentary as you work ("I'm pulling the date out of each event to populate the per-day set"), while Model B is stating your high-level intent upfront, working silently for 60–90 seconds, then summarizing what you did before repeating the cycle.
- **Practice talking while you work before the interview** — like touch typing, verbalizing your thought process while solving a problem is a skill that needs to be rehearsed, not figured out on the spot; a few mock sessions with a friend or mentor can make a significant difference.

How To Debug Effectively with AI As My Partner?

In this lesson we talk about how to debug effectively with AI as a partner during a coding interview, and when to use it versus when to rely on your own judgment.

- **Use AI to generate more test cases, but step through code yourself** — AI can rapidly produce test cases that would take much longer to write manually, but since it predicts words rather than executing code, it can reproduce the same bugs it originally introduced, making it unreliable for tracing logic line by line.
- **Avoid leaning on AI for debugging, but use it strategically when stuck** — rather than asking AI to find or fix a bug directly, prompt it to brainstorm multiple possible causes, which keeps you in the driver's seat, surfaces hypotheses for you to validate with your own judgment, and reduces the risk of confidently wrong AI suggestions.
- **Always rerun all tests after a fix, not just the failing one** — thorough test coverage lets passing tests serve as reliable verification; if your test suite is thin, compensate with more manual code inspection to avoid introducing regressions you won't have time to track down later.

What Should I Do In The First 10 Minutes?

In this lesson we talk about how to strategically approach the first 10 minutes of an AI-assisted coding interview to set yourself up for success.

- **Resist the urge to dive in immediately** — instead of jumping straight into coding or prompting the AI, start by restating the problem in your own words and doing a strategic skim of the codebase to understand existing functionality and function signatures.
- **Uncover hidden requirements** — as you explore the code, actively look for things like bot user filtering, non-active event handling, or data normalization that may not have been spelled out in the prompt, and clarify these with your interviewer.
- **Turn requirements into tests early** — unlike traditional interviews, convert each discovered requirement into an executable test case upfront (using AI to help generate them if needed), since verifying AI-generated code is a core part of the assessment.

Take Some Time To Reflect

We wrap up by reframing layoffs as a rare opportunity to pause, reflect, and intentionally design the next chapter of your career. Here are the core points from the lesson:

- A layoff often comes with severance and time, which is an incredibly valuable resource that gives you space to step off the hamster wheel and think clearly.
- Taking days or even weeks to reflect is worthwhile, since deep self-introspection about career direction, values, and long-term goals is difficult but high leverage.
- Being laid off can surface important questions you may have ignored while grinding, including whether you enjoy your role, your function, or even the tech industry at all.
- Boredom and distance from day-to-day work can spark creativity, learning, and exploration that are nearly impossible when you’re constantly shipping and firefighting.
- With persistence, reflection, and conversations with trusted people, a layoff can become a pivot point that leads to a more aligned, fulfilling next step—even if that path looks very different than before.

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.