Hiring tests
Practise in
0 XP

Interview mode

Practise first, investigate a fault on this laptop, then talk through the fix with an engineer. The observed work and explanation guide the decision.

Hiring tests are part of the Hiring plan for companies. Talk to us to set them up for your team.

1. Practise10 min · untimed, unrelated task
2. Investigate30–40 min · engineer present
3. Talk it through15 min · explain and adapt
Laptop setup and running order

Before

  • An engineer chooses a task and vendor suited to the role, reads its guide and checks the assigned thresholds and reviewer notes.
  • On the interview laptop, open the academy in a clean session. Check Run, Pause, Inputs, trends and submission; keep the reviewer guide and marking page out of the candidate view.
  • Explain what is recorded and who will review it. Agree any access needs or extra time before starting, and record the agreed conditions.
  • Give about 10 minutes of untimed practice with an unrelated exercise. Show how to press and release buttons, use maintained Inputs overrides, run checks and inspect a trend.
  • Explain the rules: documentation is allowed; AI tools and phones are not. A short clarification of the task is allowed and will be noted.

During

  • Allow 30–40 minutes for one task, using the agreed duration. An engineer stays present; this is not a remote test.
  • Ask the candidate to run the rig, investigate, change the programme and test it. Do not coach the repair; record any clarification or help given.
  • Record useful observations and save the submitted programme and report. A timeout is context, not an automatic rejection.

After

  • Allow 15 minutes for a talk-through. Use the four mission questions, including the observation and small changed requirement.
  • Let the candidate point to the programme, replay or trend. Ask them to make or describe the small change, then predict and test the result.
  • Use Strong, OK or Weak as discussion anchors. Record specific evidence, any help and the candidate’s explanation; test passes alone do not establish understanding.
  • Paste and focus records are optional context only. Documentation use, pasted examples or a focus change are not automatic evidence of cheating; the observed work and talk-through carry the weight.
  • An engineer makes the judgement, considering the role and agreed conditions. Save results for the hiring team under the agreed retention policy, then clear candidate work from the laptop before the next interview.

Prepare this interview

Each interview uses a different version of the task: tag names, setpoints and, for fault finding, the planted fault change. The skill tested stays the same.

Language

What the candidate gets

  • A full-screen, timed workbench with the 3D rig. No academy menu.
  • No hints and no worked solutions.
  • A few public practice checks. A fuller marking set checks the work on submit, in this browser.
  • One or two questions asking them to explain their fix.
  • A clear notice of what is recorded: edits, runs, checks, paste sizes and window focus. No screen, camera or keystrokes.

Documentation is allowed. AI tools and phones are not used during the interview. Keep an engineer present and use the talk-through below; paste and focus records are optional context, not verdicts.

Interviewer only · 15 minutes

Talk through the work

The explanation and live change are the evidence. Accept another correct coding style; test results and activity records do not make the hiring decision.

  1. Why does the pump keep running when you release Start?
  2. What did you observe when Stop was pressed while the pump was running?
  3. Now change the requirement: losing permission must also turn on an alarm. Show where you would add that.
  4. How would you test Start and Stop together, and what should happen?
Strong, OK or Weak: use the evidence

Strong

  • Explains why the pump keeps running after Start is released.
  • Shows Stop and lost permission breaking both request paths.
  • Tests simultaneous requests and explains why Stop wins.

OK

  • Explains the main rule and makes a workable change with minor prompting.
  • Runs the main path but needs a reminder to check a boundary or interruption.
  • Can explain the submitted code and attempt the changed requirement.

Weak

  • Cannot connect the submitted code to the observed equipment behaviour.
  • Removes required protection or hides the symptom without addressing the cause.
  • Cannot explain or adapt the repair, even after the requirement is clarified.

Reports on this device

No submitted tests yet. Reports appear here after a candidate submits on this device.