I've seen a client rewrite a role several times, with a different hard filter in each version. An earlier candidate, passed over for lacking consulting experience, looked like a possible fit for the final version. The revised brief gave the team a reason to revisit that decision.
That creates a practical question for a hiring team. Are the candidates falling short of the job, or is the team learning that it needs a different job done?
What changed after you saw the candidates?
Start with the last version of the brief that the hiring team agreed on. Compare it with the latest request. Put the change in plain words, including the work it affects.
"We need someone more senior" gives the recruiter little to check. "We need someone who can choose a release approach without daily help from our lead" names a responsibility. That change may affect the level of the role and the evidence you need from candidates.
The U.S. Office of Personnel Management connects job tasks with the skills needed to perform them. That is a useful starting point for revising a brief. Ask which task made the new requirement necessary and what would happen if the person didn't have it on arrival.
Separate a changed job from a changed preference. A new reporting line or responsibility may change who can do the work. A preference for someone who has used the same vendor may be teachable, depending on the assignment and available support.
If the team hasn't settled the work in the first place, use the engineering role brief questions to define responsibilities and success. This guide starts at the next decision, after sourcing has already taught you something.
Should you revise the brief or the assessment?
Revise the brief when the work changes. Revise the assessment when the work is still right but the interviews aren't giving you enough evidence about it.
Use this comparison as a discussion aid. The examples are hypothetical, and each decision depends on your actual role.
The table keeps different problems from producing the same response of "send more candidates." It also gives the recruiter a reason for a change they can explain to the next person they contact.
Who needs to agree before the search continues?
The hiring manager should agree on the revised responsibilities. If the change affects pay, seniority, or reporting, get approval from the person responsible for that decision. Include the recruiter and affected interviewers so the new brief reaches the people using it.
Write a short change note rather than circulating another unexplained job description. Record the old requirement, the new requirement, and the work-based reason. Add who approved the change and which candidates need another look.
Keep the assessment consistent with that note. Google's structured-interview guide describes using predetermined qualifications and a shared scoring approach. A new brief paired with an old interview scorecard leaves the team assessing different jobs.
There may be a genuine disagreement about the role. One leader may need someone to write code while another expects the same person to manage vendors and plan launches. More sourcing won't settle that choice. Name the work that has priority and decide what the person won't own.
Should you revisit candidates you already rejected?
Revisit earlier candidates when the reason for rejecting them no longer applies to the revised job. Use the same revised criteria for anyone you reassess, and check whether they are still interested and available.
The earlier screen may still contain useful evidence. It may also leave questions unanswered. A candidate who has built an integration hasn't necessarily led its rollout, so a change in scope may call for a new conversation about that responsibility.
Review the recorded feedback before asking the person to repeat an interview. GitLab's interviewer guidance asks for job-relevant feedback that makes strengths and weaknesses clear. Specific notes make it easier to see what remains useful after a brief changes.
Explain the change to the candidate. Say which responsibility changed and what you still need to learn. Don't present a restarted process as if their earlier work never happened, or suggest that reconsideration guarantees an offer.
For a separate hypothetical example, suppose a job originally required designing a new internal platform. The revised job is to maintain an existing system with help from the technical lead. Recheck which design responsibilities still belong to the hire, then assess candidates against the work that remains.
What should you send back to the recruiter?
Send a decision they can use. State whether the team is keeping the current role, changing the assessment, or opening a materially different search. Include the revised brief and any earlier candidates who should be reconsidered.
Before work resumes, ask the recruiter to explain the new role back to you through one candidate example. That helps you catch a remaining mismatch before another round of outreach.
If you need outside help, the guide to choosing an engineering staffing agency explains what a useful technical screen should establish. Once your team can explain which work the hire needs to own, bring the latest brief and the reasons it changed to the staffing discussion.
