About

Five years ago, two friends and I — junior engineers who had graduated from UCLA not long ago — were trying to figure out how to prepare for embedded systems interviews. We had already learned most of what we thought we needed — C, operating systems, microcontrollers — but when it came to interviews, everything felt oddly fragmented. The information existed, but it didn't come together in a way that made sense as a process. There wasn't really a path, just pieces. So we started putting things together ourselves.

That became a GitHub repository we called embeddedNewTestament.io. It wasn't anything polished. It was just where we collected concepts, interview questions, bits of algorithm practice, and whatever patterns we were starting to notice. Some parts were structured, some parts were messy, and some were just half-finished thoughts. We weren't trying to build something for other people. It was just something that made the process feel a little less random for us. And somehow, it worked.

All three of us ended up landing roles at the companies we had been aiming for. Then we stopped updating it and moved on.

I assumed that was the end of it, but over time I started getting messages from people I didn't know — mostly on LinkedIn — saying the repo had helped them prepare, or even helped them land a job. At first it felt like a coincidence, but it kept happening. Eventually I went back and looked at it again. It was still exactly as we had left it — unorganized, incomplete, full of rough notes and random comments — and yet it had quietly grown to hundreds of stars. That was when it really clicked for me that there are a lot of embedded engineers going through the same experience we had, not because they lack ability, but because the process of preparing for interviews just isn't very clear.

Since then, I've been working as an embedded engineer at a FAANG company and have spent a lot of time interviewing candidates. What stands out isn't a lack of knowledge. Most candidates are actually quite strong. The difficulty is something else. Interviews now tend to evaluate how you think more than what you know — how you reason about a system, how you talk through trade-offs, how you structure your thinking out loud. That's not something most people are explicitly trained to do, and there's a gap there. I've seen the same pattern across candidates from different places — the U.S., Taiwan, India — it doesn't seem tied to any one background.

At some point it started to feel like I was looking at the same problem from the other side, so I decided to rebuild what we had originally put together, just in a more intentional way. That became Embedded Interview Lab. It's not meant to replace existing resources or be another collection of tutorials. It's more about making the process feel a little more structured and a little more aligned with how interviews actually work. There's also a part of this that's about community. Embedded engineering can feel specialized and isolating — this is, in some sense, an attempt to bring back a bit of that guild spirit: engineers who share knowledge, hold each other to a standard, and make sure the craft survives as a shared inheritance, not a product.

In the post-AI era, we are freed from mastering the tools. What remains — and matters more than ever — is how we think. We are engineers who design and implement complex systems that address non-trivial problems. Not coders moving building bricks around.

That's the vision behind what this is becoming. Not just another interview prep site or a collection of coding problems — but an AI-powered, interactive platform that helps embedded engineers learn to think, reason, and approach real-world systems the way engineers actually do. To work through trade-offs, justify decisions, and understand why a design is the way it is — not just how to implement it. The goal is to help people become better engineers, not just better at interviews. This project is still early, and I'm figuring it out as I go — but that's what it's built around.