Every interview leaves you with two choices.
You can move on to the next opportunity, or you can treat the feedback as your next project.
A few months ago, during an embedded systems interview, Bluetooth Low Energy (BLE) came up. I was honest—I didn’t have professional experience with it.
Walking out of that interview, I wasn’t disappointed.
I was excited.
It reminded me why I enjoy embedded systems so much. Every new technology is another opportunity to become a better engineer than I was yesterday.
Instead of hoping another opportunity would come along, I decided to create one for myself.
Turning a Knowledge Gap into a Project
My goal wasn’t to build the biggest or most impressive BLE application.
I wanted to understand BLE well enough that I could confidently explain every decision I made.
I picked up an ESP32-C3 and started building a small environmental sensor that advertised over BLE, exposed a custom GATT service, and sent temperature data to a mobile application.
The custom GATT service, seen from a generic BLE client.
At first, BLE felt overwhelming.
GAP. GATT. Characteristics. Descriptors. Advertising. Pairing. Bonding. Notifications. UUIDs.
Most tutorials showed me how to make something work, but very few explained why it worked.
That became my goal.
Whenever I learned something new, I asked another question.
Why does advertising only begin after the BLE host synchronizes?
What actually happens during pairing?
Where is the passkey generated?
How does a client subscribe to notifications?
Why are there multiple storage configuration functions?
One answer always led to another question.
Telemetry notifications arriving once a client subscribes.
Slowly, BLE stopped feeling like a collection of APIs and started feeling like a system I could reason about.
Learning by Building
I’ve always found that I learn best by building.
Reading documentation helps me understand the theory, but building something forces me to understand the details.
Every bug became a lesson.
Every design decision made me stop and think.
Every feature forced me to understand another part of the system.
Without realizing it, the project stopped being about BLE.
It became about learning.
That realization has stayed with me ever since.
Engineering Is More Than Writing Code
As the project grew, something unexpected happened.
The code became only one part of the work.
I found myself writing documents before writing features.
I documented the project vision, requirements, architecture, design decisions, security model, test plan, issues I encountered, and lessons I learned.
At first, I thought documentation was something you created after finishing a project.
Instead, I discovered that documentation improved the project itself.
Writing things down forced me to challenge my assumptions, think more carefully about trade-offs, and explain my reasoning clearly.
It made me feel like I wasn’t just building a hobby project anymore.
I was practicing engineering.
Using AI as an Engineering Partner
This project also changed how I think about AI.
I never wanted AI to build the project for me.
I wanted it to challenge my understanding.
Whenever something worked, I asked why.
Whenever I made a design decision, I wanted another opinion.
Whenever I didn’t fully understand a concept, I kept asking questions until I did.
Instead of treating AI as a code generator, I treated it like another engineer sitting beside me—someone I could discuss ideas with, challenge my assumptions, review my thinking, and explain concepts from different perspectives.
That changed the speed at which I could learn.
AI didn’t replace the engineering.
It accelerated the feedback loop.
The understanding still had to be mine.
Looking back, that may have been the biggest surprise of the entire project.
The Day Everything Came Together
A few weeks later, I was invited back to present the project.
I expected to explain the architecture and demonstrate the BLE application.
Instead, the discussion quickly became hands-on.
The team gave me a real temperature sensor and asked me to integrate it into the project.
This wasn’t something I had prepared for, but it turned out to be the most valuable part of the entire experience.
The sensor didn’t respond during an I²C address scan.
My instinct wasn’t to start changing the firmware.
Working in embedded systems has taught me that hardware and software are partners. If the hardware isn’t behaving correctly, changing perfectly good firmware won’t magically fix the problem.
One idea has become part of the way I approach debugging:
Hardware doesn’t validate firmware. It enables it.
So before questioning the firmware, I gathered evidence.
I checked the wiring with a multimeter.
I scanned the complete range of valid I²C addresses.
I tried the available address configurations.
Nothing responded.
Everything pointed towards the sensor itself.
The team replaced it.
The new sensor responded immediately.
I completed the integration, demonstrated the live temperature data over BLE, and thought the presentation was over.
Live temperature data over BLE, in the companion app.
Then they handed me a logic analyzer I had never used before and asked me to capture the I²C communication and identify where the temperature values were being transmitted.
Like everything else that day, I approached it one step at a time.
Understand the tool.
Capture the data.
Interpret the results.
By the end of the presentation, I realized something interesting.
They weren’t simply evaluating whether I knew BLE.
They were watching how I approached unfamiliar problems.
The Drive Home
The interview eventually came to an end.
I packed everything up, thanked the team, and started driving home.
Like she always does after an important interview, my wife called me and excitedly asked,
“So… how did it go?”
As I walked her through everything that had happened, something suddenly clicked.
Just a few weeks earlier, BLE had been a gap in my knowledge.
Now I had built a working project around it.
I had documented it.
Shared the code for review.
Presented it to experienced embedded engineers.
Answered detailed technical questions about the architecture and design decisions.
Integrated a real sensor into the project.
Systematically debugged a faulty sensor.
Used a logic analyzer I had never touched before to inspect the communication.
And I had done all of it independently.
Halfway through the conversation, I remember stopping for a moment and thinking,
“Wait… I actually did all of that in just two or three weeks.”
That was the moment this project stopped being about BLE.
Throughout my career, interviews had pointed out areas where I could improve.
This was the first time I had taken one of those gaps, turned it into a real project, gone back, and used that project as evidence that I had learned something new.
That realization changed something for me.
Before that interview, I sometimes questioned whether I was ready to take on technologies I hadn’t worked with before.
Driving home that day, I felt different.
Not because I suddenly believed I knew everything.
Not because I had mastered BLE.
But because I finally had evidence that I could learn something completely new and become productive with it.
During the presentation, the engineers asked detailed questions about BLE, my architecture, and the decisions behind the project.
I didn’t answer every question perfectly.
I hadn’t mastered BLE.
But I answered most of them because I genuinely understood what I had built.
Then came the practical challenges.
I integrated unfamiliar hardware.
I trusted the debugging process instead of guessing.
I adapted to a logic analyzer I had never used before.
Every one of those moments reinforced the same idea.
I can take on unfamiliar challenges.
I can learn new technologies.
I can get the job done when I commit to it.
Finding My Learning Process
Looking back, BLE wasn’t really the lesson.
The lesson was discovering my own learning process.
Find the gap.
Build something real.
Ask “why” until it makes sense.
Document your decisions.
Prototype quickly.
Test it with real hardware.
Reflect on what you’ve learned.
Repeat.
For me, AI became part of that process—not by replacing the work, but by making the learning loop faster. It helped me prototype more quickly, challenge my thinking, and spend more time understanding instead of searching.
The next challenge probably won’t be BLE.
It might be Linux device drivers, USB, UEFI firmware, or something I haven’t even heard of yet.
That’s okay.
I no longer worry as much about whether I already know the technology.
I trust the process I’ve built for learning it.
And I think that’s the most valuable thing this project has given me.
If there’s one thing I hope someone takes away from this story, it’s this:
Interviews don’t just evaluate what you know today.
Sometimes they reveal what you’re capable of learning tomorrow.
Continue Exploring This Project
📘 Technical Case Study – for readers who want to dive into the architecture, design decisions, and implementation details.
💻 GitHub Repository – for readers who want to explore the source code.