Cyber-Physical Systems Engineer interview scorecard
Evaluate Cyber-Physical Systems Engineer candidates across 4 weighted areas: technical depth, work that shipped, diagnosis under uncertainty, and working across the org. Technical depth leads at 35%, so check depth in real-time control and embedded stacks: RTOS scheduling and jitter budgets, CAN or EtherCAT buses, Simulink or ROS 2 models, state estimation. Use the rubric to compare role-specific evidence consistently.
engineering applied scienceembedded controlhardware in the loopreal time systemssensor fusion
TL;DR
For technical depth, look for evidence the candidate explains control loop timing margins, bus arbitration behaviour and estimator tuning with numbers from systems they personally wrote firmware for. For work that shipped, look for evidence the candidate names deployed cyber-physical platforms, their role in each, HIL coverage achieved, and how the system behaved after months of field operation.
Apply the written 1–5 anchors to every answer, record the evidence behind each rating, and use the factor weights to reach a consistent overall assessment.
Complete evaluation framework
What to assess and how to score it
Review the evidence signals before interviewing. Then use the anchored descriptions—not instinct alone—to choose the score that best matches each answer.
01
Evaluation factor
Technical depth
35% weight
Check depth in real-time control and embedded stacks: RTOS scheduling and jitter budgets, CAN or EtherCAT buses, Simulink or ROS 2 models, state estimation and sensor fusion.
Evidence to listen for
Explains the physics or mechanism behind their work, not just the tooling
Names the standards, tolerances, and constraints they designed against
Can defend a design decision under follow-up questions
Distinguishes what they personally engineered from what the team delivered
Five-point scoring guide
1
Poor
Cannot explain the fundamentals of their own stated specialism.
2
Needs Improvement
Knows the vocabulary but not the underlying mechanism; struggles under follow-ups.
3
Satisfactory
Solid working knowledge for the role; depth thins out on edge cases.
4
Very Good
Strong command of the domain; explains trade-offs and defends decisions well.
5
Excellent
Explains control loop timing margins, bus arbitration behaviour and estimator tuning with numbers from systems they personally wrote firmware for.
02
Evaluation factor
Work that shipped
30% weight
Probe systems they took from model to deployed hardware: HIL rigs, PLC or microcontroller targets, field trials, safety cases under IEC 61508 or ISO 26262, unit counts in service.
Evidence to listen for
Names specific programmes, parts, or systems that reached production or field use
States their own scope inside the project
Can give measured outcomes: yield, cycle time, cost, failure rate
Explains what went wrong and what they changed
Five-point scoring guide
1
Poor
No delivered work; experience is coursework, lab-only, or purely observational.
2
Needs Improvement
Contributed to projects but cannot say what shipped or what their part was.
3
Satisfactory
Has delivered real work; outcomes described without numbers.
4
Very Good
Names shipped work and their scope, with some measured results.
5
Excellent
Names deployed cyber-physical platforms, their role in each, HIL coverage achieved, and how the system behaved after months of field operation.
03
Evaluation factor
Diagnosis under uncertainty
20% weight
Test how they chase faults spanning software, electronics and mechanics: intermittent sensor dropouts, clock drift, EMI, race conditions found via logic analyser, oscilloscope or trace logs.
Evidence to listen for
Describes a real failure they chased to root cause
Shows a method: isolate variables, reproduce, measure, eliminate
Distinguishes correlation from cause
Says what they ruled out and why, not only what the answer turned out to be
Five-point scoring guide
1
Poor
No diagnostic method; guesses or escalates immediately.
2
Needs Improvement
Trial and error with no structure; cannot explain how they narrowed the cause.
3
Satisfactory
Reasonable method on familiar problems; less structured on novel ones.
4
Very Good
Clear systematic approach with a real root-cause story.
5
Excellent
Walks through an intermittent cross-domain failure, the instrumentation used to isolate it, and the evidence that confirmed root cause rather than a workaround.
04
Evaluation factor
Working across the org
15% weight
Assess work with firmware, mechanical, security and operations teams: interface control documents, requirements traceability, patching constraints on OT networks, handover to field service crews.
Evidence to listen for
Explains technical constraints to non-technical stakeholders without condescension
Has negotiated scope, cost, or timeline with manufacturing, product, or suppliers
Documents decisions so others can act on them
Takes review feedback without defensiveness
Five-point scoring guide
1
Poor
Cannot communicate outside their specialism; dismissive of other functions.
2
Needs Improvement
Communication gaps cause rework; avoids stakeholder contact.
3
Satisfactory
Works adequately with other teams; documentation is thin.
4
Very Good
Communicates clearly across functions; reliable collaborator.
5
Excellent
Describes negotiating interface specs and OT patch windows, giving concrete examples where their documentation prevented integration or downtime problems.
Evidence-led prompts
Interview questions for a Cyber-Physical Systems Engineer
Use these prompts to surface evidence for the weighted factors above and compare candidates against the same role-specific criteria.
01
Can you explain how you have applied this knowledge in a practical setting?
02
Can you explain challenges you met in integration and testing, and how you resolved them?
03
Do you have experience with connected devices in these systems?
04
Can you discuss designing control algorithms for these systems?
05
What techniques and tools do you use for system modelling and simulation?
