Building in the Gaps: Lessons from an Apple Firmware Engineer

Parth Thakkar’s journey is a reminder that landing a coveted engineering job at a renowned hardware company isn’t built on credentials alone. It’s built on curiosity, persistence, and an almost stubborn commitment to learning by doing. Today, Parth is a HID Firmware Engineer at Apple, working on the embedded code that powers the next generation of Apple accessories.

While earning his bachelor’s degree in India and later a master’s in electrical engineering at the University of Colorado Boulder, Parth spent countless hours teaching himself the practical skills needed to complement the theory taught in class.

Last year, I met him for coffee near campus, where he showed me his custom keyboard (designed and built completely from scratch!). His passion was immediately obvious. He turned curiosity into projects, and projects into a deeper understanding of what it really takes to build reliable hardware and firmware. By consistently going the extra mile, he earned a role at one of the most demanding engineering companies in the world.

I asked Parth to answer a few questions to share his story and, hopefully, inspire anyone currently learning embedded development.

Can you share your current role and what you work on today? How did you break into that position (landing a job at Apple!) and what steps or experiences were most important in getting there?

I’m a HID (Human Interface Devices) firmware engineer working on iPad accessories like keyboards and Apple Pencil, plus Mac trackpads and keyboards. My daily work is mostly designing low-level firmware for resource-constrained hardware. I also review/approve hardware and schematics to make sure the design will work with the firmware.

The biggest factor for me why I got in was projects. Whatever I learned from university courses,YouTube, or books, I tried to turn it into real projects. In interviews, people look at the problems you run into, how you debug them, and the decisions you make while answering a problem. That experience shows up clearly when you have worked on a lot of projects and know detailed reasoning behind your each answer.

In general, strong projects are usually the tie-breaker between two candidates. So keep your projects strong.

Looking back at your path through your traditional university engineering programs (BS and MS in EECE), what parts of your education prepared you well for embedded systems work, and what gaps did you find yourself needing to fill on your own? Were there specific concepts or skills that formal coursework didn’t cover deeply enough?

Honestly, I didn’t have much guidance around me, so early on it was messy, I learned a lot of things I didn’t need immediately and missed some things I did need. University gives you foundations, but it won’t handhold you into the exact skills industry expects.

University courses move fast in 4–6 months, so they can only cover the surface of many topics. The useful part was getting exposure to many areas and learning how to think like an engineer.

The biggest gap was practical depth: debugging real issues, reading datasheets/specs properly, and building systems end-to-end.

What helped me fill that gap was taking course concepts and building ambitious projects around them, even if the class itself didn’t require it.

If your course has projects, treat them like portfolio pieces, not just assignments. If it doesn’t, build your own mini-project per course if possible.

You’ve taught yourself a huge amount outside traditional coursework. How did you approach self-directed learning in embedded engineering? What strategies, habits, or mindsets helped you make consistent progress when the topics became challenging?

I’m big on keeping momentum with small things. I start the day by listing major tasks, and I cross them off once they’re done. It keeps me motivated and makes my progress visible.

I also try to reduce friction: laptop already open, pen ready, and workspace set up so I can start quickly without “warming up” for an hour.

From the very beginning my mindset was to build a “T-shaped” profile: broad knowledge across many topics, but deep depth in one core area (for me it’s firmware – embedded).

I set a simple goal: learn 1–2 new things every day, even if it’s small. Over months, it compounds a lot.

Most of my “1-2 new things everyday” came from writing code alongside tutorials & books, doing independent development, understanding concepts and then modifying it into my own mini-projects.

That way I was just consuming content that I could show and explain later to my colleagues, and interviewers.

You’ve built some impressive personal projects, including your custom keyboard. Could you walk us through that project?

The keyboard project was a real “systems project” because it forced me to deal with both hardware and firmware decisions. like choosing components, doing power budget analyses for MCU, writing Firmware with interrupts, state-machines, DMA for lower consumption, understanding HID and BLE specification.

A lot of learning came from debugging: PCB issues (some of the routing was not correct, forgot to add pull ups on scan lines) and a lot of FW issues like architecting true wireless keyboard with master, slave and host. how to sync up two halves and so forth. It was troubleshooting and iterating until it worked reliably.

It also taught me how to read documentation properly and not guess when something isn’t working. Small mistakes in embedded projects become big big time sinks, so you learn to be methodical.

Alongside that, I built other projects that made my thinking more “low-level” like 8-bit CPU, Pong on the 8051 in assembly, a real-time “face shooting robot” project with a monotonic scheduler with hard realtime deadlines, and a ray tracer engine in C++. You can find my portfolio with these projects here: parththakkar.studio.

Those projects helped me learn architecture, timing, and low-level constraints in a way coursework never fully did.

Are there any specific courses or creators you’d recommend to someone starting today (GitHub, YouTube, Udemy, etc)?

Most of my learning came from a mix of YouTube, hands-on projects, and reading documentation. The channels that helped me a lot were:

• Core Dumped
• GreatScott!
• Shawn Hymel
• Phil’s Lab (PCB design)
• Eric Bogatin (signal integrity / PCB fundamentals)
• Alaska Linux User (device tree)
• Ben Eater (architecture, networks)
• Electronoobs
• EmbeddedExpertIO (baremetal)
• James Sharman (his CPU project is great)
• Low Byte Productions
• Low level learning (now just “Low Level”)
• Motriz Klien (analog designing)
• Paul Programming
• Psychogenic Technologies

Udemy (great  courses for FreeRTOS, Linux Programming(like device drivers, and qemu, and other stuff).

Coursera courses for embedded Linux development.

The Build Your Own X GitHub repository.

Also, reading real specs (USB, PCIe, USB-PD, etc.) is painful because they’re huge PDFs, but it’s totally worth it if you build a project around them.

A lot of engineers talk about “learning from first principles.” What did that actually look like for you? Can you share an example of something you built from scratch (an RTOS, USB HID stack, etc.) and how that hands-on process helped you internalize the concepts?

For me, first principles means understanding what’s happening at the low level, because then higher-level frameworks stop feeling like magic and you understand “it’s all about manipulating memory”. Once you know the “why,” you can build or debug almost anything faster.

For example:

• I wanted to understand RTOS context switching, so I built a small RTOS from scratch on an M4 core to see exactly what the scheduler and stack switching are doing.
• I wanted to understand what happens before main(), so I wrote a bare-minimum program using startup code and linker scripts to see the full boot path. and now i understand what happens

This will help you make nets around topics and connect them.

Motivation and momentum can be the hardest part of self-learning. When you hit resistance (mentally or technically) what helped you push through? Do you have routines, tricks, or mindset shifts that help you get back into productive mode (even small things like reducing the friction to start)?

I use sticky notes and simple daily task lists to keep progress visible. I try to follow an “ideal schedule” most days and adjust when life happens. I’m not motivated every day, and I don’t pretend I am. When I’m exhausted, forcing it usually backfires, so I switch contexts: work on a hobby, change topics, or go for a run. Physical activity helps me reset mentally, and it’s one of the most reliable ways I’ve found to get unstuck. I run every Sunday and try to keep some kind of regular movement going.

One mindset shift that helped me: unmotivated days are normal — you just can’t let them become multiple days or weeks. You have to “fight you” and restart.

Is there anything I didn’t ask that you wish more engineers knew about teaching themselves embedded systems? This could be advice, warnings, good habits, or even thoughts on balancing tech with non-tech hobbies.

The biggest thing is consistency beats talent. I was never the smartest in the class, but I kept learning and kept building. Try to balance learning with life: hanging out with friends, physical training, and hobbies. That balance matters because burnout kills progress faster than difficulty does.

How to explain your project: projects should be built in a way that you can explain them clearly, what problem you solved, what tradeoffs you made, and what you’d do differently.

And yeah, if I can get into Apple, you can too. Stick to daily effort, build projects people want to see, and always, always keep learning.