Two businesses can advertise for a robotics engineer and mean completely different jobs. One needs someone to improve a robot's understanding of its surroundings. Another needs more reliable motion. A third needs a learning approach that works outside a demonstration.
Before deciding which title to use, describe what the system should do and where it currently falls short. That gives you a better starting point for choosing the person, the interview and the evidence you need.
Identify the part of the problem they will own
A useful brief distinguishes between observing the environment, deciding what to do and controlling movement. These responsibilities may overlap, but they are not interchangeable.
Someone working on perception might focus on interpreting camera or sensor data. A controls engineer might concentrate on how the machine responds. A learning-focused role may involve training and evaluating behaviour from data or interaction. State which part is the priority and where other team members take over.
Explain what success looks like outside a demo
'Improve the robot' is difficult to assess. A clearer objective describes a task and the conditions in which it must work. Consider differences in objects, lighting, surfaces or human interaction, where relevant to your product.
Define the practical checks the team uses: repeatability, recovery from failure, task completion and the ability to diagnose what went wrong. The exact measures should come from your engineering requirements. Avoid copying a benchmark just because it is common in another application.
Treat simulation experience as a starting point for discussion
Simulation can be part of development and testing, but using a simulator does not by itself show that someone can deliver on hardware. Ask what they modelled, which assumptions mattered and how they assessed the gap between the simulated environment and the real system.
For a learning role, discuss how the candidate chose an evaluation method and dealt with behaviour that met a training objective but failed the practical task. The aim is to understand their judgement, not to find a particular phrase on a CV.
Decide how much hands-on work the role involves
Be explicit about access to robots, responsibility for experiments and the support available from mechanical, electronics and software colleagues. A research-heavy role and a deployment-heavy role can both be valuable, but the day-to-day work will differ.
- Will the person develop new methods, improve an existing approach or integrate supplied components?
- Will they run experiments on hardware themselves?
- Who owns data collection, labelling and evaluation?
- How will they investigate failures and share results?
- What software engineering standards are expected around the experimental work?
Interview for evidence rather than a perfect keyword match
Ask the candidate to walk through one relevant project at an appropriate level of detail. What was the actual problem? What did they personally change? Which approach did they reject, and why? What failed when the system was tested under different conditions?
An early-career candidate may have strong evidence from a substantial project. An experienced candidate should be able to explain the boundaries of their own contribution. Neither should need to disclose someone else's intellectual property to demonstrate how they think.
A clear robotics brief helps you choose between a specialist in one area and an engineer who can work across several. Secure Consult recruits across robotics, autonomy, software and engineering, helping hiring teams describe the capability they need before starting the search.
