Why pre-screen human-robot interaction specialists before the technical panel
People behave around robots in ways no specification anticipates. They step into a path assuming the machine will stop, they stand still when the system expects movement, and they interpret a pause as a fault. A robot can be compliant with every safety standard and still be dangerous because its intentions are unreadable. Specialists worth hiring have watched people and been surprised. A short screen asks what surprised them.
What actually matters when screening Human-Robot Interaction Specialist candidates
- 01
Theoretical command
Probe command of human factors theory behind HRI: trust calibration in automation, situation awareness models, legibility and intent expression, proxemics, NASA-TLX and SUS instrumentation.
- 02
From theory to hardware or code
Test whether they build, not just publish: ROS 2 nodes, MoveIt, Unity or Gazebo study harnesses, teleoperation interfaces, logging pipelines for gaze and intervention data.
- 03
Research judgement
Assess study design judgement: within versus between subjects, Wizard of Oz use, deception debriefs, IRB or ethics approval, sample sizing, and knowing when a lab result will not survive deployment.
- 04
Explaining it to non-specialists
Look for translation to product and safety teams: turning study findings into interaction specs, ISO 10218 or ISO/TS 15066 collaborative limits, and briefing engineers who want a number, not a paper.
Pre-screening questions to ask Human-Robot Interaction Specialist candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Systems people used
3 questions01Can you describe a human-robot interaction project you have worked on?
Listen forA system that real people interacted with, with their own role and how it behaved outside the laboratory.
Projects tested only with the team, or systems that never met an untrained user.
02What types of robots have you worked with?
Listen forPlatforms named with the interaction context, since a collaborative arm and a mobile robot differ entirely.
Robot types listed with no interaction context, or simulation-only experience.
03Tell us about a challenge you faced in a project and how you overcame it.
Listen forA difficulty at the human boundary, such as unexpected behaviour or an interaction people misread.
Challenges described as purely technical, or no problem that involved actual people.
Safety for real behaviour
3 questions04How would you ensure safety in the design and operation of these systems?
Listen forSafety designed for what people actually do, with speed and separation monitoring rather than instructions.
Safety relying on people following signage, or standards cited with no behavioural consideration.
05How familiar are you with sensing and perception for interaction?
Listen forHuman detection understood with its failure modes, including people who are still, partly occluded or seated.
Detection assumed reliable, or no consideration of who the sensing might miss.
06Do you have experience designing and implementing control algorithms?
Listen forControl implemented with compliant behaviour near people and a defined safe state on uncertainty.
Control described without any consideration of proximity to people, or no defined safe behaviour.
Evaluated with people
3 questions07Tell us about quantitative evaluations you have performed on these systems.
Listen forStudies with real participants and measures beyond task success, including trust and perceived safety.
Evaluation limited to task completion, or studies run only with the development team.
08What steps do you take when prototyping an interaction scenario?
Listen forLow-fidelity prototyping including simulated control, so interaction is tested before the system is built.
Interaction tested only once the robot is complete, or no prototyping before implementation.
09How do you approach the design of an effective interaction?
Listen forDesign starting from what the person needs to understand, with the robot's intent made visible.
Design starting from robot capability, or interaction treated as an interface layer.
Legible behaviour
3 questions10Can you explain your experience planning robot behaviour?
Listen forBehaviour designed to be readable, so a person nearby can predict what the robot will do next.
Behaviour optimised only for efficiency, with legibility to bystanders not considered.
11How would you improve communication and understanding between people and robots?
Listen forIntent signalled through motion, light or sound appropriate to the environment and the noise in it.
Communication designed as screens or speech in an environment where neither would be noticed.
12Do you have experience working with cross-functional teams on these projects?
Listen forWork with safety, mechanical and software colleagues, including a finding that changed the mechanism.
Interaction work delivered as recommendations, or no change to the robot that came from their findings.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Theoretical command
35%5Cites specific constructs such as trust repair after robot error or legible motion planning, and names where each theory breaks down.
From theory to hardware or code
30%5Describes a robot behaviour or interface they coded, deployed on real hardware, and iterated after participants misread it.
Research judgement
20%5Explains a design choice they reversed after piloting, and distinguishes findings robust in the field from lab-only artefacts.
Explaining it to non-specialists
15%5Converts nuanced behavioural findings into concrete design requirements and defends them to hardware leads without jargon or hedging.
A robot can meet every safety standard and still be dangerous because its intentions are unreadable. A one-way video screen asks what people did that surprised them.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for this role take?
Fifteen minutes across eight to ten questions, answered async. Enough to establish systems people used, test their safety thinking, and hear how they evaluated with real participants.
Is this a research or an engineering role?
It sits between them and candidates lean one way. A research-leaning specialist evaluates well but may not build; an engineering-leaning one builds and may not test with users. Decide which gap you have.
Evaluating answers
What is the strongest signal when screening this role?
What people did that surprised them. Specialists who observed real interaction describe behaviour nobody anticipated. Anyone whose users behaved as designed has tested with colleagues who knew the intent.
How do I judge their safety thinking?
Ask what happens when a person does something unexpected near the robot. Sound answers describe designing for the behaviour rather than instructing against it. Signage is not a safety measure.
























