From Marksheets to Meaningful Skills
Most embedded engineers with 1–2 years of experience ask one question silently:
“Am I really industry-ready, or am I just comfortable with tools?”
In embedded systems, boards don’t lie — but resumes often do.
So instead of certificates and buzzwords, let’s evaluate ourselves using two lenses:
- Skill-based scoring
- Word-based understanding (story test)
🔍 PART 1: Skill-Based Self Evaluation (Reality Check)
Rule:
Give marks only for what you have actually done hands-on.
Theory-only knowledge = 0 marks.
🧠 Programming & Firmware Fundamentals
- Embedded C basics (loops, pointers, bitwise ops) – 2
- Memory concepts (stack, heap, static, volatile) – 3
- Interrupt handling & ISR debugging – 4
- Debugging using debugger / printf – 3
⚙️ Firmware Driver Development
- Driver using HAL only – 2 marks
- Driver without HAL (register-level) – 5 marks
- GPIO, Timer, PWM configuration – 5 marks
- Startup code & linker awareness – 3 marks
👉 If you used HAL but don’t know which register changed, don’t claim register-level marks.
🔌 Communication Protocols (Project-Based)
- UART project (polling / interrupt) – 3
- UART debugging (baud/frame issues) – 2
- I2C sensor project – 4
- SPI project (display / flash / ADC) – 4
- Timing & waveform understanding – 2
⏱️ RTOS (FreeRTOS)
- Task creation & states – 3
- Queue / Semaphore usage – 4
- Mutex & priority inversion – 3
- Timers & delays – 3
- Debugging deadlock/starvation – 2
🔧 Hardware Awareness
- Reading datasheet & pin mux – 2
- Understanding schematic – 2
- Simple PCB design (for learning) – 3
- Power basics (LDO, decoupling) – 2
- Multimeter / logic analyzer usage – 1
🧰 Tools & Professional Skills
- Build systems (Make/CMake/IDE) – 3
- Git basics – 2
- GDB / OpenOCD – 3
- Linux basics – 2
🔢 Total: /100
Interpretation
- <30 → Trainee mindset
- 30–50 → Junior engineer
- 50–70 → Industry-ready
- 70+ → Strong fundamentals (rare at 1–2 yrs)
📖 PART 2: The Story Test (Do You Understand the Words?)
Now comes the most honest evaluation.
If a technical word fits naturally in your thinking → 1 mark
If it scares you → 0 markNote: The technical words used are a mixture from various devices and technologies. They do not belong to a single architecture and may appear in upper case irrespective of their actual use case.
📖 The Day the Embedded System Panicked
The system was running peacefully in Thread mode when a timer Interrupt arrived.
Unfortunately, a wrong memory access caused an Exception.
Now the CPU was handling Interrupt + Exception together.
Luckily, a proper handler existed.
Otherwise, the system would have gone into panic.
Two tasks tried to access a shared buffer — a critical region.
Without synchronisation, data corruption was inevitable.
A Mutex was used to take a lock, while another task waited on a semaphore.
In the background, DMA was snooping the bus silently.
At startup, the linker script placed variables in bss, constants in rodata, and shaped memory correctly.
During execution, registers like RAX and flags like NZCV decided arithmetic outcomes.
After ISR completion, the CPU executed RTI, restoring context using xPSR.
Some default functions were declared weak, allowing safe overrides.
The system survived — not because of tools, but because of understanding.
✅ Word-Based Self Scoring (1 Mark Each)
- Interrupt ⬜
- Exception ⬜
- Interrupt + Exception ⬜
- Thread mode ⬜
- Handle ⬜
- Panic ⬜
- Critical region ⬜
- Snooping ⬜
- Synchronisation ⬜
- Mutex ⬜
- Lock ⬜
- Semaphore ⬜
- Linker script ⬜
- bss ⬜
- rodata ⬜
- RTI ⬜
- RAX ⬜
- NZCV ⬜
- xPSR ⬜
- weak ⬜
Score: __ /20
🎯 Final Reflection
Ask yourself honestly:
- Am I HAL-dependent or hardware-aware?
- Can I explain why a bug occurred, not just fix it?
- Can I work on a board without internet for 2 hours?
- Do these words feel like friends or strangers?
🧠 Closing Thought
In embedded systems,
confidence comes from clarity of words,
and clarity comes from touching the hardware.
Marksheets fade.
Understanding stays.