Our technical screening process
01
1. Role brief
With your hiring manager we pin down the actual work, standards, tools, target hardware, seniority and the problems the engineer will face in the first months.
02
2. Targeted sourcing
We search for specific experience, such as an MCAL vendor, a DAL, a tester platform or a kernel subsystem, not keyword matches.
03
3. Recruiter pre-screen
Availability, notice period, location, compensation expectations and a check that the CV's projects hold up to basic questions.
04
4. Technical interview by a practising engineer
An engineer working in the same discipline interviews the candidate on design, debug and standards scenarios drawn from real work.
05
5. Written assessment
Where the role calls for it, a short written task: a code review, a configuration problem, a test design or a safety requirement to refine.
06
6. Reference and background checks
References from former leads on the work claimed, plus employment and education verification to the depth agreed with you.
07
7. Shortlist pack
You receive the CV, the screener's notes and assessment summary, then run your own interviews and make the decision.
Scenario questions by domain
Examples of the practical ground our screeners cover. Questions vary by role and seniority.
| Domain | What we probe | Example scenario |
|---|---|---|
| AUTOSAR Classic | BSW and MCAL configuration, RTE, ComStack, OS | A CAN signal reaches the bus but not the SWC: walk through the COM, PduR and RTE configuration you would check |
| Functional safety (ISO 26262) | HARA, safety goals, ASIL decomposition, work products | Derive technical safety requirements for a given safety goal and explain the ASIL decomposition you would allow |
| Design verification (UVM) | Testbench architecture, coverage closure, debug | Coverage is stuck short of the goal on a FIFO: explain how you would find the holes and what you would change in the sequences |
| DO-178C software | Requirements-based testing, structural coverage, DAL objectives | Explain what MC/DC coverage requires at DAL A, and how you would handle code that tests cannot reach |
| HIL testing | Rig configuration, I/O mapping, plant models, fault insertion | A HIL test passes on one rig and fails on another: describe how you would isolate model, I/O and timing causes |
| Embedded Linux and firmware | Bring-up, drivers, concurrency, memory | A board hangs during boot after a device-tree change: describe your debug sequence with a JTAG debugger and serial console |
| ATE test engineering | Test programs, pattern debug, correlation | Yield drops on one tester site only: explain how you would separate hardware, program and device causes |
What you see before you interview
- The candidate's CV, with the projects and standards the screener verified in conversation
- Screener notes on strengths, gaps and the tools and platforms the candidate has used hands-on
- A summary of the written assessment where one was set
- Notice period, likely joining date, location preference and compensation expectations
- Any ramp-up the screener expects on your specific toolchain, stated plainly
Why we screen this way
Standards-driven engineering roles are easy to misread from a CV. A candidate can list ISO 26262 or DO-178C without having produced a safety case or coverage evidence, or list AUTOSAR having only used generated configurations. Asking someone who does the work to probe the work is the most direct way to tell the difference.
The same screeners look at the roles we fill through staff augmentation, contract-to-hire, permanent recruitment and dedicated teams. Role-specific skills are listed on each role page, for example AUTOSAR engineers, VLSI engineers, avionics engineers and test engineers. Engineers looking for roles can start at careers.
Frequently asked questions
How do you vet AUTOSAR, ISO 26262 or DO-178C experience?
A practising engineer in the same discipline asks the candidate to work through scenarios: tracing a signal through COM, PduR and RTE configuration, deriving safety requirements from a safety goal, or explaining MC/DC objectives at DAL A. We also ask which work products the candidate owned and how they were reviewed or audited.
Who conducts the technical interviews?
Engineers who work in the same discipline as the role, for example an AUTOSAR integrator for BSW roles, a verification engineer for UVM roles or a test engineer for HIL roles. Recruiters handle availability and expectations; technical judgement comes from engineers.
Do candidates take a written test?
Where the role calls for it. Written tasks are short and practical, such as reviewing a code snippet against MISRA C, solving a configuration problem, designing test cases from a requirement or refining a safety requirement. We do not use generic aptitude tests.
Can we add our own technical rounds?
Yes, and most teams do. Our screening is designed to save your engineers time on unsuitable candidates, not to replace your interviews. You can also share your own questions or a take-home task for us to include at screening stage.
Which tools should our engineers know, and do you check them?
It depends on the role: Vector DaVinci and CANoe for AUTOSAR, dSPACE or NI for HIL, Lauterbach TRACE32 for embedded debug, Synopsys, Cadence or Siemens simulators for verification, Advantest V93000 or Teradyne UltraFLEX for ATE. We confirm hands-on use in the interview and flag where ramp-up on your tools applies.
Do you run reference and background checks?
Yes. We take references from former leads on the work the candidate claims, and verify employment and education history to the depth you need. Additional checks your security policy requires are agreed with you before the search starts.
Tell us the roles, seniority and start date. A practice lead replies with matched profiles.