Linux, RT-Smart and NuttX on RISC-V
Lance’s same-board investigation into bring-up, watchdogs, timers and benchmark validity—not a placement case study.
View evidence ↗For embedded Linux hiring teams
Embedded Linux recruitment
RunTime helps teams hire engineers responsible for embedded Linux platforms: BSP and boot-chain development, kernel and device drivers, Yocto or Buildroot, userspace integration, deployment, field support and technical leadership.
The hiring problem
Using Linux is different from owning an embedded Linux platform.
An application developer may be highly capable without having owned the boot chain, kernel configuration, BSP, drivers or production image.
A strong platform engineer should be able to separate hardware, bootloader, kernel, driver, userspace and deployment faults—and explain which layers they personally changed.
Build reproducibility, resource limits and field maintenance matter as much as getting an image to boot once.
Roles we recruit
Relevant roles
- Embedded Linux engineer
- BSP or board bring-up engineer
- Linux kernel or device-driver engineer
- Yocto or Buildroot engineer
- Embedded Linux systems engineer
- Embedded Linux technical lead
The role determines the required combination. These are not presented as skills every candidate must have.
What we assess
Evidence behind the CV
Depending on the brief, we look for evidence of:
- Boot-chain, device-tree and BSP ownership
- Driver development rather than only configuring existing drivers
- Hardware/software fault isolation across system layers
- Reproducible builds, image creation and deployment
- Resource constraints, observability and field support
- Reasoned trade-offs between Linux, an RTOS and bare metal
How we search
A search built around the actual work.
We establish which layers the hire will own, the target hardware and build environment, current bring-up state and delivery constraints. We then review relevant candidates, approach platform engineers directly and test claimed ownership against the role.
What your shortlist contains
Reasons, evidence and open questions.
- Why the person is being recommended
- Evidence relevant to the brief and personal ownership
- Gaps or claims requiring further technical validation
- Location, work rights, remuneration expectations and availability
Illustrative example — not a real candidate or placement.
Example shortlist assessment
- Role being assessed
- Senior embedded Linux and firmware engineer for a connected industrial controller.
- Relevant experience and ownership
- Owned an ARM-based BSP update, two custom peripheral drivers and the production image build. Worked with the hardware lead during first-board bring-up and maintained the field-update path.
- Evidence of technical fit
- Explained the boot chain, a DMA coherency fault isolated with traces and register inspection, and changes made to produce repeatable Yocto builds. Distinguished personal driver work from vendor configuration.
- Gaps and further questions
- No demonstrated safety-certification ownership. Limited recent bare-metal work. Employer should examine kernel-debugging depth and architecture decisions in the technical interview.
- Practical constraints
- Melbourne; Australian work rights; seeking $175k plus super; four weeks’ notice. Details would be confirmed before presentation.
- Why recommend an interview
- Relevant platform ownership and credible debugging evidence align with the immediate brief. The identified gaps are explicit and can be tested by the employer’s technical team.
RunTime’s assessment provides context for interview; it does not replace the employer’s technical evaluation.
Relevant evidence and engineering insights
Read the thinking behind the assessment.
Linux vs RT-Smart vs NuttX on the Same RISC-V Board
The engineering context and limitations behind the operating-system comparison.
Read more →Choosing Linux, RTOS or bare metal
A discussion of platform choice against actual requirements.
Read more →Frequently asked questions
Practical questions before a search.
Do you recruit Linux application developers as well as platform engineers?+
Yes, when the brief calls for them. The page distinguishes the two because userspace application experience should not be presented as BSP, kernel or driver ownership.
How do you handle Yocto or Buildroot requirements?+
We clarify whether the work is routine image configuration, custom layer and recipe ownership, board support, reproducibility, deployment or long-term platform maintenance, then assess accordingly.
Do we need a finished job specification before speaking?+
No. An initial discussion can clarify the role’s responsibilities, constraints and essential experience before the brief is finalised.
Can RunTime work with our existing interview process?+
Yes. RunTime’s assessment adds evidence and context before interview; it does not replace the employer’s technical evaluation or hiring decision.
What commercial terms apply?+
The applicable engagement model and fee are agreed in writing before a search begins. Current general terms are available on the Terms of Business page.
Discuss your hire
Start with the role and the engineering problem.
No finished job specification is required for an initial discussion.