The Unfiltered Engineer

Shehab Abdel-Salam says too many engineers are snacking at work.

He doesn’t mean the kitchen.

His first job was at Dell during the pandemic, when nobody was coaching anyone. So he started asking questions. That habit became a Substack called The Proactive Engineer, and a clear way to think about being proactive.

Shehab is a Senior Software Engineer at Proofpoint, working on scaling email security products from the Tessian acquisition. Before that he spent three years at Faculty, a London AI company, building a product from the ground up, and nearly two years at Dell Technologies.

In this one:

• Bias for action, initiative, and relationships, and what “high developer agency” means for someone new on a team
• The Magic Loop, a five-step way to get meaningful work from your manager
• Productive versus busy, and the impact and effort graph that helps you choose
• The Python-to-Rust migration he jumped into without any Rust experience
• How initiatives change from junior to senior to staff
• When to ask forgiveness instead of permission, and when to wait
• What to do when you’re handed work that adds no value
• Why AI should be your thinking partner, not the lead
• How to speak up if you’re afraid to

Links from the episode:

• Don’t Snack Too Much at Work: https://www.proactiveengineer.com/p/11-dont-snack-too-much-at-work
• The Magic Loop (Ethan Evans, Lenny’s Newsletter): https://www.lennysnewsletter.com/p/the-magic-loop
• Easier to ask for forgiveness than permission (EAFP): https://realpython.com/ref/glossary/eafp/
• Shehab’s space: https://www.proactiveengineer.com
• Shehab on LinkedIn: https://www.linkedin.com/in/shehab-abdel-salam/

Shehab’s recommendations: Hidden Potential by Adam Grant. For podcasts, The Unfiltered Engineer with Vishakha Motwani , Life Engineered with Steve Huynh, and Gergely Orosz’s podcast. He switches off with walks, running clubs, and books.

He’ll be back for a second conversation on building relationships.

If you’ve ever waited for someone to hand you the next task, this one’s for you.

I’m Vish, a frontend engineer with 10+ years in the industry, currently navigating it myself. I started this show because the conversations I needed weren’t happening anywhere public.

Chapters

00:00 Meet Shehab and the idea of proactive engineering

04:03 Bias for action, initiative, and developer agency

06:14 How to make progress when tasks are ambiguous

09:30 Find problems to solve and use the Magic Loop

13:45 Do work that delivers customer and business value

19:03 The impact-effort graph and avoiding work snacking

22:46 A Python-to-Rust migration as high-impact growth

26:04 What initiative looks like from senior to staff

31:43 Handle low-value assignments and mistimed ideas

39:27 Show the measurable delta behind your initiative

42:32 Use AI as a thinking partner, not the driver

49:56 Speak up through transparency and small steps

54:15 Shehab’s takeaway, recommendations, and ways to disconnect

#softwareengineer #techcareers #proactiveengineer #careergrowth #engineeringcareers

Michael Lee’s wife looked at him one day and said, “something looks off about you today.” He didn’t know what it was. It was burnout.

Michael is an engineering leader with 15+ years in software. He started as a developer, moved through design and a stint as a CTO, and grew into leading distributed teams. Most recently he led three teams at a Fortune 500 company in the beauty space and grew the org from 20 to more than 30 engineers. He says working with people is his superpower.

We talk about the human side of leading engineers right now:

• Why AI can make burnout arrive faster, even when the work looks easier
• What he’ll miss about reading his own old code in a git log
• What leaders at a roundtable told him, and the overnight tech debt nobody asked for
• How to keep a remote team feeling like a team, including a Slack message that says nothing’s on fire
• How to bring a workload problem to your manager in a neutral way, with options
• How to help a junior engineer who’s working hard but off track
• How his youngest described his job

Michael’s recommendations: Cal Newport’s Slow Productivity and Deep Work, plus Cal’s newsletter and podcast at calnewport.com. He switches off with his kids and Lego sets, because a build has a clear start and finish.

If your team is moving fast and you’re feeling it, this one’s for you.

I’m Vish, a frontend engineer with 10+ years in the industry, currently navigating it myself. I started this show because the conversations I needed weren’t happening anywhere public.

Chapters

00:00 Michael Lee’s path from developer to engineering leader

03:09 Why AI’s speed can increase mental load

07:54 Leaders need to model the boundaries they expect

14:17 Building rapport makes collaboration more human

19:05 How to question an invite from someone senior

23:25 Ask for time back after working late

29:18 The hidden cost of over-escalating a button-copy issue

31:15 Set expectations so every request doesn't feel urgent

32:19 Managers protect engineers' focus and translate across levels

35:00 Managing up and creating space for questions

36:36 Why AI agents can bring burnout closer

38:25 Family boundaries and the human side of work

41:38 Guardrails, urgency, and permission to slow down

44:18 Prioritize incidents with severity levels and response times

46:15 Mentor junior engineers with retrospectives and office hours

49:41 Understand what's slowing an engineer down

54:23 Michael's advice: be human, kind, and inquisitive

55:08 Cal Newport's books and working at a natural pace

56:10 Switching off with family and LEGO builds

58:13 Test meeting boundaries with small experiments

#softwareengineer #techcareers #engineeringleadership #burnout #remotework #theunfilteredengineer

Amruta Akut started preparing for interviews in late May. By mid-July she had multiple offers.

She says she practiced fewer than five system designs. One company quizzed her on 12th grade probability.

Amruta is a software engineer with 15+ years of experience across Dassault Systèmes, Oracle, Roku, and Walmart, and she recently joined Zoox. I worked with her at Dassault. She went through this market in 2024 and again in 2026, and she tells me how different the two were.

In this one:

• What has changed in interviews between 2024 and now
• How she prepared her behavioral stories, and why the most recent project isn’t always the right one
• What interviewers ask once you say “I’d add a message queue”
• The rounds she didn’t see coming
• How she used AI to prepare
• Cold applications versus networking, and what she says mattered most
• How to answer the “how do you use AI?” question

Amruta’s recommendation: the Ryan Peterman show.

If you have an interview coming up, this one’s for you.

I’m Vish, a frontend engineer with 10+ years in the industry, currently navigating it myself. I started this show because the conversations I needed weren’t happening anywhere public.

Chapters

00:00 Meet Amruta Akut and her path to Zoox

02:26 Why she started searching and how quickly offers arrived

04:27 What AI changed in engineering interviews

06:31 Behavioral interviews and telling stronger project stories

10:47 Building a realistic preparation plan for frontend roles

17:04 How to handle coding problems under interview pressure

22:34 Why senior and staff interviews reward technical depth

28:04 Using AI for system design practice and interview prep

32:30 Unexpected interview rounds and level-specific expectations

37:34 AI-enabled interviews are still a mix

39:02 How to talk about your practical use of AI

43:21 Cold applications, networking, resume quality, and timing

48:03 Amruta’s final advice and recommended listening

#softwareengineer #techcareers #interviewprep #jobsearch #engineeringcareers

For ten minutes, Mona’s team couldn’t see what was happening in a whole region. The component that sends out the health data had gone down itself, because it couldn’t handle the scale.

They called it blackout mode.

Monalisha Singh is a Lead Engineer at NetApp with more than 11 years of experience building observability for hyperscale products in cloud native environments. She has a master’s in computer engineering from UMass Lowell and mentors the next generation of women in tech.

In this one:

• Why observability gets treated as a checkbox, and what that costs
• The price of data you didn’t need to collect
• What changes when your output stops being your own code
• Where AI goes wrong when it doesn’t have the context

If you build or run anything in the cloud, this one’s for you.

I’m Vish, a frontend engineer with 10+ years in the industry, currently navigating it myself. I started this show because the conversations I needed weren’t happening anywhere public.

Chapters

00:00 Introduction to Mona Singh and episode overview

01:38 What is observability and why is it crucial from day one

03:19 Telemetry in POC versus full-scale production

04:26 Mona's role in observability and engineering

06:00 Key metrics in cloud native back end systems

07:41 Challenges of scaling in cloud native environments

10:05 Proactive monitoring and failure anticipation

11:30 Systems thinking and designing for failure modes

14:12 Feedback loops and continuous improvement in observability

23:33 Nightmares of hyperscale observability and lessons learned

33:40 AI's role in system monitoring and its limitations

36:38 Key takeaways: observability as a foundational practice

#softwareengineer #techcareers #observability #cloudnative #devops #theunfilteredengineer

Bonus: Is a Conference Worth It? (LDX3 and WeAreDevelopers)

A stranger at a bus stop asked me if three days at a conference would be worth taking time off work. I was on my way to one.

So here’s a short bonus episode on the two conferences I attended, LDX3 in New York and WeAreDevelopers in San Jose, so you can decide for yourself.

In this one:

• How I got in: I hosted sessions at LDX3 (my own talk wasn’t accepted), and I volunteered at WeAreDevelopers after Kate, from episode 2, told me about it
• The logistics: tickets, travel, where to stay, and how to save money
• Which conference’s app made it easy to set up meetings, and which one made it hard
• What each day felt like: two stages versus eight to ten, lines for food, and workshops that only run two hours
• Why I’d pick one good conversation over a talk I can watch later
• When the expo hall is worth your time
• What I noticed sitting through the talks: I’m more caught up than I felt
• The books I picked up from authors signing at LDX3: The Software Engineer’s Guidebook by Gergely Orosz and The Manager’s Path by Camille Fournier

Got a question about either conference? Leave it in the comments or send me a DM.

I’m Vish, a frontend engineer with 10+ years in the industry, currently navigating it myself. I started this show because the conversations I needed weren’t happening anywhere public.

Chapters

00:00 Introduction and purpose of the episode

02:04 How Vishakha found and chose her conferences

04:06 Using conference apps for scheduling and meetings

06:07 Food arrangements and logistics at conferences

07:08 Volunteering and its impact on conference experience

08:01 Challenges of multiple stages and sessions

09:12 Balancing talks, networking, and energy levels

10:06 Accessing recorded talks and content after the conference

11:19 Industry insights and personal takeaways

12:34 Final thoughts and encouragement to attend conferences

#softwareengineer #techcareers #LDX3 #WeAreDevelopers #techconferences

I said I’d trust myself more. A weak promise, honestly.

Then I went to a conference talk on loop engineering and inference engineering. I understood the terms. I walked out feeling more behind than when I walked in.

This is my second solo reflection. Every fifth episode I listen back, and this time I start by checking what I promised after episode 5. I did most of it. One I’m still working on, and I say which.

Then Sumit, Kshitij, Joy, and Raj: what I’m changing because of each, and where I’d push back.

In this one:

• The job search metric I dropped because it was stressing me out
• The thing I measure on this podcast now.
• Why I stopped dumping my thoughts into AI to write my posts
• The system design mistake I keep making: I assumed every requirement was fixed, and it was a wish list
• Why “think about how it breaks” is a system design skill too
• Why I stopped trying to keep up with everything
• What I’m reading, what I’m watching, and how I switch off

I’m Vish, a frontend engineer with 10+ years in the industry, currently navigating it myself. I started this show because the conversations I needed weren’t happening anywhere public.

Chapters

00:00 Introduction to personal reflections and episode goals

01:51 Trusting myself more through interview experiences

03:58 Shifting impact measurement to podcast views

06:03 Writing thoughts without AI to build confidence

07:50 Questions to ask in system design interviews

10:01 The value of visual sketch noting in interviews

12:08 Understanding system failure and design for robustness

13:52 Building trust and understanding customer needs

16:01 Managing learning and staying current without overwhelm

17:47 The importance of being a beginner and enjoying the process

19:52 Personal growth, reading Bhagavad Gita, and relaxation tips

#softwareengineer #techcareers #reflection #engineeringcareers #careergrowth #theunfilteredengineer

A developer asks how to make it work. QA asks how it breaks.

Rajakumaran Gowthaman has spent his career on the second question, from QA and test automation at Cisco and Avaya to Principal Engineer in Cloud Security at Palo Alto Networks.

In episode nine, I sit down with Rajakumaran Gowthaman, a Principal Engineer in Cloud Security at Palo Alto Networks. He spent nearly five years there moving from Senior QA Engineer to Principal, after building his foundation in QA and test automation at Cisco and Avaya. Raj and I did an internship together out of Northeastern, and this was his first podcast.

We talk about what QA taught him that a straight developer path wouldn't have, and how that thinking shows up in cloud security today:

• A developer asks how to make it work. QA asks how it breaks. Why that split matters
• Why he widened his scope past test cases, to architecture, deployment, and what a release does to the customer
• What it's like to test a SaaS product in a setup where a failure could be anywhere, across microservices, distributed systems, and Kubernetes pods
• What a Principal Engineer in cloud security worries about day to day: is the infrastructure ready for what we're about to roll out
• How AI changed his work, from builds that took weeks now taking days to predictive failure analysis, and the trap of assuming the AI must be right
• Why he thinks jobs are evolving, not disappearing
• His one ask of developers: bring QA in at the design phase, not after development is done
• His advice for anyone second-guessing themselves: don't self doubt

Raj's recommendations: he follows AI creators on Instagram to stay current, including @the.datascience.gal (https://www.instagram.com/the.datascience.gal) and @vaibhavsisinty (https://www.instagram.com/vaibhavsisinty), plus @vee_daily19 for job search content (https://www.instagram.com/vee_daily19). To learn and experiment with different models, he suggests Hugging Face's LLM course: https://huggingface.co/learn/llm-course/en/chapter1/1

He also listens to audiobooks and podcasts on tech, spirituality, and mental strength.

If you've ever shipped something and found out later how it broke, this one's for you.

I'm Vish, a frontend engineer with 10+ years in the industry, currently navigating it myself. I started this show because the conversations I needed weren't happening anywhere public.

Chapters

00:00 Introduction to Raj and his career journey

01:40 Transition from QA to principal engineer in cloud security

04:14 Systems thinking in testing and security

06:38 Testing in complex cloud environments

09:22 Impact of AI and automation on QA

12:11 Failure analysis and predictive tools

15:50 Understanding testing harnesses

19:24 QA as a vital career path

25:19 Day-to-day security concerns in cloud infrastructure

29:56 Measuring success in deployment

34:33 Iterative testing and automation in stages

37:26 Evolution of QA from manual to AI-driven

40:23 Collaboration between development and QA

41:19 Key takeaways from the discussion

#softwareengineer #techcareers #qa #cloudsecurity #engineeringcareers

In episode eight, I sit down with Joy, a senior software engineer, tech lead, digital artist, lifter, and professional anime binger. She finds joy in figuring out how complex things work, whether that's software, anatomy, or building a physique. We talk about visual thinking as a skill, not as art, as a technical tool.

• Why drawing a problem out, even a messy scribble, surfaces gaps that talking through it never does
• The rubber duck technique, but visual, and why a drawing gives people something to literally point at instead of relying on memory
• The real test for whether you actually understand your own solution, can you explain it to someone non-technical
• Why there's no one correct way to think or problem solve, and what happens when you try to force your process onto someone wired differently
• How to build visual thinking as a skill, even if it's never come naturally to you

Joy's recommendations: Huberman Lab, Modern Wisdom, and Diary of a CEO, plus a serious anime habit, My Hero Academia, Demon Slayer, and Jujutsu Kaisen.

If you've ever wished you could explain a technical decision more clearly, to your team or to yourself, this one's for you.

I'm Vish, a frontend engineer with 10+ years in the industry, currently navigating it myself. I started this show because the conversations I needed weren't happening anywhere public.

#softwareengineer #techcareers #visualthinking #engineeringcareers #communication

Chapters

00:00 Introduction to Joy and Visual Thinking

03:51 Using Sketching to Clarify Technical Problems

04:47 Vishakha shares how visual cues opened her mind

05:56 The Rubber Duck Technique for Fresh Perspectives

07:52 Drawing as a Problem-Solving Tool

08:20 The concept of supplements versus complete information

10:02 Communicating Visually in Remote Work

12:00 Tools and Simplicity in Visual Thinking

12:09 Using doodling and visual tools to enhance conversations

14:01 Training Yourself in Visual Thinking Skills

15:46 Relaxing the atmosphere in meetings to improve communication

15:58 Explaining Technical Concepts to Non-Technical People

18:06 Abstracting Technical Details for Different Audiences

20:05 The Importance of Clear Communication

20:33 Joy discusses visualization techniques in bodybuilding

22:06 Techniques to Confirm Understanding

23:48 Using Visuals to Organize and Clarify Ideas

25:34 The mind-to-muscle connection and internal visualization

26:01 Integrating Visual Thinking into Daily Problem Solving

28:00 Different Thinking Styles Among Engineers

29:58 Embracing Flexibility in Problem-Solving Approaches

30:05 Verbal cues for effective exercise and muscle engagement

32:01 Getting Started with Visual Thinking as a Beginner

34:01 The Role of Informal Sketching in Daily Life

35:00 The role of mental cues and visualization in injury prevention

35:58 The Power of Visuals as a Supplement, Not a Substitute

39:53 Joy's favorite educational podcasts and YouTube channels

45:31 The impact of visualization on learning complex movements

49:58 Joy's personal routines for decompression and relaxation

In episode six, I sit down with Kshitij Saxena, a Senior Product Engineer at epilot in Munich. Before that, he spent nearly four years at NewStore, growing from Software Engineer to Software Engineer II, building systems like an asynchronous message delivery pipeline and a historical order import system on AWS.

We talk about the difference between shipping a feature and actually knowing if it worked, and why the best engineers refuse to just take orders:

• Why a product engineer isn't good at accepting solutions, even when they're handed one, and digs into the why instead
• Output versus outcome, and the exact moment a phone number field taught him the difference
• Why he doesn't just ask why, he asks why now, and what that's taught him about timing and prioritization
• When AI got good enough to trust running overnight, and when it still makes expensive mistakes
• Why almost nothing is a failure if you stop, acknowledge it, and actually reflect

Kshitij's recommendations: The Vegetarian by Han Kang, and the Huberman Lab podcast.

If you've ever shipped something and never checked whether it actually mattered, this one's for you.

I'm Vish, a frontend engineer with 10+ years in the industry, currently navigating it myself. I started this show because the conversations I needed weren't happening anywhere public.

Chapters

00:00 Introduction to Kshitij Saxena and his background

01:19 What is product engineering and how does it differ from traditional software engineering?

02:13 The importance of asking 'why' before building a feature

03:52 Focusing on outcomes rather than just outputs

06:22 Deciding when enough information has been gathered to proceed

08:22 Distinguishing between output and outcome in feature development

09:47 Thinking in problems, not just solutions

11:26 Balancing user feedback, data, and experimentation

14:36 Using metrics to guide product iterations

16:18 The role of experimentation and learning from failure

18:30 Leveraging AI agents and prompt engineering in product work

24:44 From idea to shipped feature: the lifecycle and challenges

28:53 Prioritization, impact, and timing in product development

32:48 Dealing with uncertainty and learning from mistakes

38:26 The importance of asking 'why now' in feature development

42:16 Key takeaways: impact over output and continuous learning

#softwareengineer #techcareers #productengineering #engineeringcareers #AI

In episode six, I sit down with Sumit Mudliar, who leads Customer Success at iceDQ, a role built entirely on influence rather than authority. Before that, he spent years as a software engineer, moving from engineer to his current leadership role.

We talk about what influence without authority actually means, and how to get people on board when you can't just tell them what to do:

• What influence actually means, when I hear the word I still picture Instagram influencers before anything else
• Why listening, not solutions, is the real strategy, meeting people halfway before you tell them what you want
• The moment he got pulled into a room at Morgan Stanley he wasn't technically supposed to be in, and what it taught him
• Why avoiding speaking isn't always weakness, sometimes it's giving someone else room to think
• His book recommendations

If you've ever had to get buy-in from someone who doesn't report to you, this one's for you.

I'm Vish, a frontend engineer with 10+ years in the industry, currently navigating it myself. I started this show because the conversations I needed weren't happening anywhere public.

Chapters

00:00 Introduction to influence without authority

02:05 What influence without authority really means in practice

04:06 Sumit's journey from engineer to customer success

05:56 Listening and understanding before proposing solutions

08:08 Building trust through research and expertise

09:59 The importance of empathetic listening and story behind problems

11:58 Prioritizing stakeholder needs and managing expectations

13:54 Influencing without authority in technical decisions

15:52 The role of proof of concept and visual demonstrations

17:51 Aligning solutions with organizational vision and future state

20:01 Changing perspectives: from possessiveness to openness

22:05 Learning from humility and embracing change

24:03 Effective communication with internal teams and stakeholders

26:09 The significance of understanding and addressing priorities

28:03 Handling pushback and resistance in influence

29:53 The importance of continuous research and preparation

32:00 Common mistakes in influence without power

33:48 Leveraging stakeholder priorities for better influence

36:00 Key takeaways: openness, listening, and humility

38:05 Personal habits for disconnecting and recharging

#softwareengineer #techcareers #leadership #influence #engineeringcareers