Hiring a junior developer? Test whether they can judge code, not type it.
Most of the code in a small company is now written by a tool and approved by a person. The interview should test the approving. Pick a stack and a theme: you get a short change as a coding tool would hand it over, with two faults planted in it, a sheet for the candidate, and a marking sheet and questions for you.
Six exercises, written by hand. Nothing is generated and nothing you pick is sent to us.
1. Stack
2. Theme
Pick the theme closest to what the job touches. The stack matters less than you'd think: a candidate who reads carefully finds these in a language they have used for a month.
How to use it
Send the candidate sheet the day before or hand it over in the room. Allow tools: you would at work. Mark the written review against the sheet, then spend fifteen minutes on the questions. The exercises are public, so a determined candidate can find this page. That is fine: the conversation shows quickly who understood the faults and who memorised them. For a second round, change the names and swap which endpoint has the fault.
Why test this at all: entry-level developer hiring has fallen while the amount of generated code has risen, and what a junior does all day has changed with it. We went through the numbers in the missing junior developer. If the new hire will work from a written brief, the one-page developer brief builder gives them something to build against, and the launch checklist covers the same kinds of fault across a whole app.
An interview aid, not a certification. More free tools: biz59.net/tools.