One lesson from an assessment I ran was that I had assumed more experience than the candidate had. The exercise left questions about their fundamentals that I hadn’t explored directly.
If I interviewed them again, I’d start with smaller, more concrete questions about the language and frameworks they were using. I’d want to understand where they were comfortable, where they needed help and how they approached something unfamiliar.
The senior full-stack assessment guide assumes someone can take broad responsibility for delivery. A junior role needs its own assessment, with expectations that reflect the work and guidance available.
Agree what they should know already.
Start with the tasks you expect them to handle in their first few months. Perhaps they will fix small bugs, extend existing components and add tests with a more experienced engineer reviewing their work.
Write down the knowledge they need on arrival and what you are prepared to teach. If you plan to teach a particular framework, don’t reject someone simply because they haven’t used it yet. If the job requires them to work in it immediately, explore their understanding directly.
Ask how they have used the relevant tools in work, study or a project. Years of experience can provide context, but the conversation should establish what they actually did and how much guidance they had.
Be equally honest about your side of the arrangement. A junior hire needs someone with time to help. If you need a person who can work independently from the start, revisit the level and responsibilities of the role.
Explore the language and framework through real code.
Use a small example and ask them to explain what happens. Keep the questions connected to code they would encounter in the job. For a TypeScript and React role, you could explore:
- Data and types: “This function expects a user. What happens if the API returns nothing? What does the type checker tell us, and what still needs checking when the application runs?”
- Asynchronous work: “Walk me through what happens while this request is loading. Where would you handle a failed response?”
- Framework behaviour: “Where does this component get its data? What happens after the user changes this state?”
- Debugging: “The page shows the wrong result. What would you inspect first, and what would that tell you?”
TypeScript’s types are removed when code is compiled, so a type annotation alone won’t validate an API response. React’s state model gives you another concrete topic to explore. Use the equivalent concepts for your own stack.
Let them explain in their own words, look something up and test an idea. You want to see whether they can use the concepts. Recalling an obscure method name tells you much less about that.
Give them one manageable piece of work.
Provide a working application and a narrow change. For example, a form already submits data, but a failed request leaves it stuck in a loading state. Ask them to investigate, improve the behaviour and show how they checked it.
Agree a short time limit and pilot the task first. Leave room for them to read the code and ask questions. Don’t automatically carry over the senior guide’s four-to-six-hour exercise with a deliberately oversized backlog.
Ask them to describe the current behaviour before changing it, explain what they expect their change to do and check the result afterwards. This gives you several chances to explore their understanding without asking them to design an entire system.
Keep their understanding visible when they use AI.
State the AI rules in advance and apply them consistently. If they will use AI in the role, let them use it in the practical task. Ask what they requested, what the suggestion changed and how they checked it.
If an agent produces a working fix, choose one relevant part and ask the candidate to explain it. Change a small condition and explore what they expect to happen. If they don’t know, give them room to investigate.
A working result and a confident explanation can still leave gaps. Watching them trace the code, check a claim or correct an assumption gives you more to discuss. Avoid turning a gap into a surprise ban on tools midway through the session.
Notice what changes when you offer help.
If they get stuck, clarify the task or offer a small hint. Record what they could do independently, what help you gave and what they managed afterwards. Keep comparable guidance available to other candidates.
Explore whether they can explain the hint and apply it to a similar part of the problem. That gives you a practical observation about how they worked with support in this session. It isn’t proof of how quickly they will learn everything else.
Compare the evidence with the junior role you described. You may find a solid foundation with a teachable gap, or a need for more support than your team can offer. Neither conclusion requires judging them against the independence you would expect from a senior engineer.
Misjudging the level of an assessment is something you can learn from. Tighten the brief, ask better questions next time and make the expectations clearer for both sides.
Research and further reading
The session described here is a practical proposal to adapt and pilot for your role. These sources support choosing relevant skills and distinguishing entry requirements from knowledge you plan to teach.
- OPM: job analysis. Connects the tasks of a job, the competencies they require and training needs.
- OPM: work samples and simulations. Emphasises assessing competencies candidates are expected to possess on entry; a task testing work they will be taught later may be inappropriate.
- TypeScript handbook: erased types.
- React: state as a snapshot.