Build a hiring process around the work

Describe what the team will be able to do after the hire that it cannot do now. A senior engineer is not a capability by itself. You might need someone to own a fragile billing subsystem, mentor a growing group, or design a migration while protecting existing customers. Those needs produce different role requirements.

Separate essential evidence from skills that can be learned. Name the support available during onboarding and the constraints that could make the role difficult: time-zone overlap, legacy code, on-call duties, incomplete documentation, or a changing product. If success requires extraordinary independence because nobody can help, first ask whether the organization is ready to hire for that role.

Create a small rubric before meeting candidates. For each capability, define the exercise or conversation that can reveal it, the observable evidence of a strong answer, and what remains unknown. A design discussion may reveal tradeoff reasoning; a debugging exercise may reveal how someone forms and tests hypotheses. Neither proves every dimension of engineering ability.

Use consistent prompts and record what happened rather than labels such as “not senior enough.” Explain what tools are allowed, including documentation and AI assistance when relevant to your working environment. If you restrict a tool, explain which capability the restriction is intended to reveal. Give candidates the information needed to prepare without expecting unpaid production work.

Each interviewer needs a specific assignment so candidates do not repeat the same conversation all day. Agree on duration, prompts, permitted hints, accessibility arrangements, and how evidence will be recorded. Interviewers should write their observations before a group discussion so the most senior voice does not silently determine everybody’s memory.

In the debrief, separate observed evidence, interpretation, and missing information. Resolve disagreement by returning to the role requirements. A new surprise criterion should trigger scrutiny of the process, not an automatic rejection. Keep the final decision owner clear and communicate the outcome within the expectation you set with the candidate.

Candidates are also making a consequential decision. Provide clear information about the team, compensation process, location expectations, interview steps, and the actual work. Let them speak with prospective peers and ask about a recent difficult project. A polished pitch that hides the operational reality creates an onboarding problem later.

Review the process as a funnel, but do not optimize a single conversion number blindly. Look at candidate withdrawals, delays between stages, inconsistent feedback, and the eventual experience of new hires. Ask where the process imposes work without adding evidence. Remove duplicated steps while preserving the checks that matter for the role.