Junior Embedded Software Engineer

About the role

You will join a smart-home device company where a growing firmware team ships connected products to millions of households. You will start on well-scoped tasks with direct mentorship from senior engineers, and your growth path is explicit: within a year you will own a driver or feature end to end. This role matters because the team is scaling fast, and engineers who learn the hardware-software boundary deeply here become the senior firmware leads of the next product cycle.

What you will achieve

• Ship your first production driver (for example a sensor or display peripheral) within your first three months, reviewed and merged into the main firmware branch with passing unit tests
• Build a bench test setup that validates your components against a written test plan, catching regressions before code review and documenting results so teammates can rerun them
• Reduce your average code-review iteration count by half over your first two quarters by internalizing the team's style guide and static-analysis rules
• Own at least one small feature (such as a button-sequence behavior or LED indication scheme) from spec to field release, including the verification evidence
• Contribute five accepted improvements to shared documentation (bring-up guides, register maps, or FAQ entries) in your first year, each reviewed by a senior engineer

What you will bring

Must-haves

• 0-2 years of experience with C, including at least one substantial project such as an internship, co-op, capstone, or personal hardware project you can walk through
• Basic understanding of how microcontrollers work: GPIO, timers, interrupts, and at least one serial protocol you have actually used
• Comfort with a breadboard or dev board: you have flashed firmware and watched it do something physical in the real world
• Willingness to read datasheets and reference manuals, not just tutorials, when the behavior you see does not match what you expected
• Familiarity with Git basics (clone, branch, commit, pull request) and the discipline of small, reviewable changes
• Curiosity and persistence: you debug by measuring with instruments, not by guessing and reflashing
• Clear written communication for asking questions and documenting what you learn so the next person learns faster

Nice-to-haves

• Coursework or projects in digital logic, computer architecture, or signals and systems
• Any exposure to an RTOS or bare-metal scheduling you wrote yourself, even for a toy project
• Python for quick test scripts, data plotting, or parsing serial logs