How I Delivered My First Zephyr RTOS Workshop and Got 4.88/5 Rating

How It Started

Imagine yourself standing in front of an opportunity you always wanted to seize. An opportunity you always wanted to happen. Well, if you did, you would feel like me when I first heard about teaching others what I’d learned about Zephyr.

I have participated in many trainings in my life, but always as a trainee. These trainings were about both technical and soft skills. I had some thoughts about what worked and what needed improvements. Still, I didn’t know in practice if they were correct - I needed to check them out.

Three months later, I stood in front of 8 engineers, delivered my first 2.5-day Zephyr workshop, and got feedback that surprised me: 4.88/5 average rating with 87.5% of participants giving the maximum 5/5 score.

Here’s what I learned about turning my embedded experience into actual training that people found valuable.

What I Remembered from Being a Trainee

When the customer came asking about Zephyr training for their team, I started thinking about all the workshops I’d attended. What did I like? What annoyed me? Here’s what I recalled:

The Environment Setup Problem

You know this situation - you come to a hands-on training, excited to learn, and then spend 2 hours debugging why your toolchain doesn’t work. Half the people get stuck on some random Docker issue, the other half have different compiler versions. By lunch, you’re already behind.

I decided this wouldn’t happen. I prepared development boards for everyone and sent Docker devcontainers beforehand. Result: 40 minutes to get everyone working instead of half the day wasted on setup.

The “Perfect Path” Trap

Most trainers show you the elegant solution immediately. But here’s the thing - when you’re working on your own project later, you don’t start with the perfect solution. You make mistakes first.

So I let people make common mistakes on purpose. For some configuration, I’d first show the manual approach, let them struggle for 10 minutes, then show the better way. This way they understood why the solution was better, not just how to use it.

The Detachment Problem

Ever been in a training where you copy-paste commands without understanding what’s happening? I wanted to avoid that. Each exercise built a story - we started simple and added complexity step by step. When something broke, we debugged it together instead of just giving the fix.

My Training Structure

Day 0: Theory Introduction

I started with a half-day presentation open to more people (up to 20), not just the hands-on participants. This served several purposes:

• Managers could see what their team would learn
• Participants came to the practical days with context
• I could check the knowledge level and adjust if needed

Days 1-2: Hands-on Workshops

Each exercise followed the same pattern:

• Start with something simple to build confidence
• Add one new concept at a time
• Create problems intentionally to practice troubleshooting
• End with real-world application

The key insight I had: exercises that build on each other work better than isolated tasks. When people succeeded with “Hello World”, they felt ready for sensor integration. When sensors worked, they were excited to try custom board integration.

The Numbers - What Actually Worked

Most Valuable Topics:

• Custom board integration (6/8 participants)
• Troubleshooting tips (5/8 participants)
• Device tree & Kconfig explanation (4/8 participants)
• Zephyr overview and architecture (4/8 participants)

Key Insight: People didn’t want to copy solutions - they wanted to understand how to solve problems they hadn’t seen before.

What I Got Right

Live Demos That Actually Help

Every single participant said the live demos were helpful. But here’s what made them work - when something broke during the demo, I debugged it live instead of switching to backup slides.

People learned more from watching me solve unexpected problems than from seeing perfect presentations. One time the device tree wouldn’t compile, and I spent 10 minutes finding a typo. The participants said later this was more valuable than the planned content.

Hardware Preparation

Giving everyone their own board made a huge difference. No waiting, no sharing, no “it works on my machine” problems. Everyone could make mistakes and fix them at their own pace.

Documentation Cards

I prepared reference cards with links to documentation for each participant. During exercises, people could quickly find what they needed without googling or asking me to repeat URLs. This was one of those small things that made a big difference.

What I’d Do Differently

The Expert Assumption

Twice I glossed over things that seemed obvious to me but weren’t to participants. The feedback mentioned that some exercises needed “one simpler step at the beginning.” Next time I’ll ask more often: “Does this make sense so far?”

Reflection Time

I rushed from one exercise to the next. People needed more time to process what they learned. I should have added explicit breaks for questions and discussion after each major topic.

Exercise Difficulty

Two exercises jumped in difficulty too fast. I designed them to start simple and build complexity, but I still missed the mark twice. The feedback helped me see exactly where.

The Practical Results

The training generated immediate follow-up questions and requests. More importantly, it showed me which parts of embedded development training are actually valuable in the market:

• Practical troubleshooting methodology (not just “here’s the command”)
• Real-world integration challenges (not just demo board examples)
• Understanding the system architecture (not just copying configurations)

What’s Next

The 4.88/5 rating was nice, but the real success was what participants said they valued most: troubleshooting methodology and custom board integration. These aren’t topics you usually see in generic Zephyr tutorials - they’re the real-world problems that block projects.

I’m already working on improvements based on the feedback. The next training will have better exercise progression and more reflection time.