--- title: "Change the Brief Before You Make the Hire" description: "Let candidates use AI, then change a requirement and assess how they question the brief, verify the result and explain what still needs approval." author: "Gunner Technology" published: "2026-11-01" url: "https://www.gunnertech.com/blog/change-the-brief-before-you-make-the-hire" --- # Change the Brief Before You Make the Hire Interview engineers who use AI by letting them build with it, then watching what they do when a requirement changes. Ask them to explain the decision, test the changed behavior and identify what still needs a person's approval. A polished prototype gives you something to examine. The next decision tells you more about how the candidate works. ## What does the prototype actually tell you? It shows what the candidate brought to the interview; it doesn't show how they will handle your next problem. In his [advice for junior engineers](https://felixrieseberg.com/hunger-beats-tenure-advice-for-junior-engineers/), Felix Rieseberg describes dropping traditional coding interviews and looking at prototypes for signs of product judgment. He also says he hasn't settled on a replacement interview. That's a useful opening for a concrete hiring exercise. Gunner Technology's recommendation is to make a changed requirement part of that exercise. Let the candidate use an AI coding agent, a tool that can inspect files, propose changes and run checks. Give them a small working system and a clear objective. Then change something that makes an earlier decision worth revisiting. You're hiring someone to direct work and judge the result. In an agent-run software factory, routine implementation and repeatable checks belong in the machinery. A coding puzzle alone doesn't exercise the decisions that remain with the person. Neither does a portfolio tour where every failure has already been edited out of the presentation. ## What should you change in the brief? Change a requirement that affects the user's outcome, and tell the candidate what changed. The exercise should reveal their reasoning rather than test whether they can guess a hidden preference. Prepare the change in advance and use equivalent conditions for candidates applying to the same role. Consider a hypothetical appointment tool built with synthetic data. The initial brief lets a customer cancel a booking. The revised brief says cancellation must preserve a record for support staff while removing the appointment from the active schedule. Now the candidate has to distinguish removing something from view from deleting its history. A button that disappears won't settle the requirement. Watch what they ask before they edit. Who needs the history? Can the customer still see the cancelled booking? What happens if cancellation is submitted again? You don't need a surprise security trap or an expanding list of features. You need a manageable decision with consequences they can describe and evidence they can produce. ## What should the interviewer watch for? Watch whether the candidate connects the new requirement to a specific change and a check that could reject it. Ask them to state the expected result before running the agent. Then let them work, including asking questions, inspecting existing behavior and rejecting a suggestion the agent makes. In the appointment example, useful evidence would show that the booking leaves the active schedule, its cancellation remains available to the authorized support role, and another cancellation attempt doesn't destroy that record. Ask the candidate what the checks leave unproven. The important moment may be when they stop calling the feature finished because the evidence doesn't cover the promise. Keep the division of responsibility visible. The agent can write and run a test; the candidate must explain why its expected outcome is right. Our post [Understanding Cannot Wait for Code Review](https://www.gunnertech.com/blog/understanding-cannot-wait-for-code-review) makes the same point about delivery: judging the requirement after the code is finished leaves the consequential thinking too late. ## How do you compare candidates fairly? Use a written rubric tied to the job, give candidates comparable tools and conditions, and record what you observed. A rubric is a set of explicit evaluation criteria. Here, those criteria should cover clarifying the objective, identifying consequences, choosing evidence and explaining a stopping point. Don't quietly turn typing speed into the deciding factor again. Distinguish an unanswered question from a bad decision. Someone who identifies an unknown and explains how to resolve it has shown you something different from someone who confidently ships an assumption. Record the actual question, action and result. Replace impressions such as 'seemed senior' with an account another interviewer can examine. This exercise produces evidence about this task under these conditions. Compare it with the other evidence your hiring process needs. For a developing engineer, keep the expected responsibility appropriate to the role. As we argue in [Junior Engineers Need a Different Ramp](https://www.gunnertech.com/blog/junior-engineers-need-a-different-ramp), learning to own consequences matters more than making someone perform routine implementation without help. ## Hire for the work your factory leaves to people Start with a role and a small exercise drawn from the decisions that role will actually own. Supply the environment, permitted tools and synthetic records. Keep the task bounded enough to complete during the interview, and explain the evaluation criteria beforehand. An unpaid weekend project would mix access to spare time into the evidence you're trying to collect. Afterward, review which parts informed the hiring decision. If interviewers rewarded visual polish but couldn't explain the candidate's reasoning, revise the exercise. If setup trouble consumed the session, repair the environment. If a question repeatedly exposed an ambiguity in your own brief, settle it rather than treating every candidate's confusion as a weakness. The factory can absorb the typing. Hiring has to catch up with the responsibilities people keep: deciding what is worth building and judging whether the result is right. Let the candidate use the machinery. Change the brief. Then ask them to show what changed, why it matters and what would make them stop. In response to [Hunger beats tenure: Advice for junior engineers](https://felixrieseberg.com/hunger-beats-tenure-advice-for-junior-engineers/) by Felixrieseberg. ## Quick answers ### Should candidates bring a personal AI subscription? Provide the permitted tools and access for the exercise. Otherwise access to a particular subscription becomes part of what you are assessing. ### Can a portfolio replace the live exercise? Use the portfolio to choose something worth discussing. A live revision gives you a separate opportunity to observe how the candidate handles an unfamiliar decision. ### What if the agent cannot finish the change? Examine how the candidate diagnoses the block, preserves useful evidence and explains the next step. An unfinished feature and an unexplained failure are different observations.