How we work
Most recruiters begin with a job description and a keyword search.
We start by understanding what you’re building, where this engineer sits in the system, what they need to own and what they genuinely need to know on day one.
Then we decide what kind of search actually makes sense.
Embedded · Firmware · FPGA · Electronics
Australia · New Zealand · USA
Before the search
A job description is rarely the whole requirement.
We want to understand:
What are you building?
Where does this engineer sit in the architecture?
What will they own?
What problems are they expected to solve?
What must they already know?
What can they reasonably learn?
What does success look like six months after they start?
Sometimes the original brief survives that conversation.
Sometimes it doesn’t.
That’s useful.A bad search launched quickly is still a bad search.
Our process
We get underneath the job title and understand the product, architecture, team, constraints and ownership boundaries.
The goal is to understand why this engineer needs to exist, not merely what keywords appear in the job description.
Some briefs are too broad. Some combine two or three jobs. Some demand expertise that isn’t realistic at the available salary.
We’ll tell you before we waste your time searching.
Where necessary, we reshape the requirement around what the business genuinely needs.
A clear hiring target. Not a wishlist.AI can optimise a CV.
It can’t manufacture years of engineering decisions, debugging experience and ownership when you start asking the right questions.
What did you build?
What did you personally own?
What broke?
How did you isolate it?
What decisions did you make?
What would you do differently now?
The questions change with the discipline.
For firmware, that might mean RTOS behaviour, timing, drivers, interrupts, memory or bring-up.
For FPGA, architecture, timing closure, verification and system integration.
For electronics, design decisions, validation, EMC, power, mixed-signal behaviour and failure analysis.
Evidence over keywords.We use direct search, existing relationships, referrals, active applicants and our candidate network to identify engineers who fit the actual requirement.
What changes
You shouldn’t have to interview ten people to find one worth hiring. The goal is a small number of candidates with a clear reason for being there.
We give your engineering team people worth spending time with. Not CVs that happen to match the search string.
If the role, salary or expectations don’t make sense, you should hear that before the search burns six weeks.
What we assess
We don’t use the same interview for every engineer because the work isn’t the same.
Engineering depth
RunTime’s technical assessment isn’t built from recruiter interview scripts. It’s grounded in the same engineering subjects we write and teach about.
I ran Linux, RT-Thread RT-Smart and Apache NuttX on the same Allwinner D1 RISC-V hardware to see what really changes when the OS changes but the hardware does not.
Read Article →
Every embedded software team has lived through a version of the same engineering tragedy. A customer reports a critical edge-case failure on a legacy microcontroller deployed in the field five years ago. A developer is tasked with opening the firmware repository, applying a hotfix, and rebuilding the binary. However, upon checking out the repository, chaos ensues. The project requires a legacy GCC ARM toolchain—specifically version 7-2018-q2-update—alongside a bespoke Python 2.7 build script, a deprecated vendor-specific HAL library, and a precise configuration of GNU Make that only runs correctly under an outdated Linux kernel or an unpatched Windows 7 virtual machine. This fragility is the direct consequence of non-hermetic build environments. For decades, embedded development has relied on locally installed, host-dependent toolchains. Unlike modern cloud-native software development—where applications are packaged alongside their execution runtime—embedded engineering has traditionally treated the host workstation as a dirty canvas of globally installed tools. When build environments are tied to the host operating system's global paths, host library versions, and user configuration settings, bit-for-bit reproducibility across team members and automated build systems becomes virtually impossible.
Read Article →
The software development world has spent the last two decades celebrating the rise of the self-taught developer. Bootcamps, open-source repositories, and interactive tutorials proved that you do not need a four-year Computer Science degree to ship scalable web applications, write clean APIs, or build responsive user interfaces. While hands-on project experience is invaluable, there is a subtle, high-stakes phenomenon emerging across tech hiring: The "Self-Taught" Hardware Engineer Trap. Evaluating hardware candidates strictly by their visible project output while dismissing formal theoretical foundations—or conversely, assuming a theoretical Electrical Engineering (EE) degree automatically guarantees hardware proficiency—creates significant hiring blind spots.
Read Article →Already advertised?
If you’ve already received 50 applications, the first question isn’t:
“Where can we find another 50?”
It’s:
“Is the right engineer already in front of us?”
We can help assess the existing pool before widening the search.
If nobody meets the bar, then we go to market.
Talk About Your RoleFrequently asked questions
No. We start with what you are building, where the engineer sits in the system and what they need to own. We can turn that into a clear, realistic hiring requirement with you.
Yes. We can assess the existing applicant pool before widening the search. If the right engineer is already there, finding another 50 applicants adds no value.
There is no arbitrary quota. The goal is a small, relevant shortlist where every candidate has a clear reason for being presented.
Assessment changes with the role and discipline. We examine what candidates personally built, owned, debugged and decided, then use appropriate technical questioning or testing where the search requires it.
We will tell you early. We may recommend changing the scope, seniority, salary, location or division of responsibilities before launching the search.
Yes. RunTime works with engineering teams across Australia, New Zealand and the USA.
Start with the problem
You don’t need a polished job description.
Tell us what you’re trying to build, where the team is getting stuck and what you think the new engineer needs to own.
We’ll start there.
