You are hiring your first security engineer. The job description lists fifteen domains, asks for a decade of experience, names four certifications, and describes a person who does not exist and would not want the job if they did.
The role you actually need is narrower and harder to write down: someone who can decide what matters when everything is on fire, build the two or three things that fix it structurally, and be told no without becoming an obstacle.
This post is how to hire that person. For whoever is writing the requisition.
Decide which of three jobs it is
"Security engineer" covers roles with almost nothing in common, and hiring the wrong one is the most expensive mistake available.
A builder. Writes code, sets up the pipeline gates, builds the service template, automates the triage. What a company with a hundred engineers and no security function needs first, because the only interventions that scale are the ones built before anyone writes code.
A breaker. Finds vulnerabilities. Valuable, and a poor first hire, because a company with no controls does not need more findings. It needs the controls, and a stream of findings with nobody to act on them makes things worse.
A programme person. Policy, compliance, audits, vendor review. Necessary if a certification is the forcing function, and unable to fix the engineering problems that produce the findings.
Most first hires should be a builder who can do enough of the third to satisfy an audit. Very few job descriptions say that, because they were assembled from other companies' descriptions.
Write the description for one person
Three or four responsibilities, the real ones. Not a list of every domain in the field.
Say what the first year looks like, concretely, because a serious candidate is evaluating whether the job is possible. "Build our AppSec function" tells them nothing. "You will inherit 4,000 unread scanner findings, a SOC 2 audit in April, and no security tooling in the pipeline" tells them everything, and the people it scares off were going to leave in six months anyway.
Drop the certification requirements unless a customer contract demands one. They filter for people who collect certifications, which is orthogonal to whether someone can prioritise.
Be honest about the constraint. One person per hundred engineers is the reality, and a candidate who understands that and still wants it is the candidate you want.
What to test
Four things, and none of them is trivia.
Prioritisation with bad information. Give them a realistic mess: a list of findings of mixed severity, partial context, a compliance deadline, and limited time. Ask what they would do first and why. You are listening for whether they reason about reachability, blast radius and effort, or whether they sort by severity label.
Can they build. If the role involves automation, have them write or read code. Not a puzzle, something resembling the work: review a diff for an authorisation bug, or sketch how they would enforce a control in a pipeline.
Can they explain. Have them describe a technical risk to someone non-technical, and watch for whether they translate to consequence or retreat into vocabulary. This is most of the job at a small company.
Can they be overruled. Ask about a time their recommendation was rejected. The answer you want involves understanding why, finding a smaller version, or accepting the decision and documenting it. The answer that should worry you is a story where everyone else was wrong.
Avoid the trivia interview
Asking someone to define a vulnerability class tests recall, which is the least scarce thing about a security engineer and the easiest to look up.
Take-home exercises are contentious and the honest position is that they are acceptable if short and paid, and that many strong candidates will decline them regardless. A ninety-minute working session on a real problem tells you more than a weekend project, and it respects the candidate's time, which is itself a signal about your company.
The signals worth weighting
They ask what the constraint is. A candidate who asks about headcount, budget, and whether engineering leadership is supportive is evaluating whether they can succeed. That is the right question and few ask it.
They have shipped something. A tool, a control, an automation that changed how a team worked. This distinguishes people who have done the job from people who have advised on it.
They can say what they would not do. A candidate who wants to implement everything is a candidate who will burn out or stall. The good ones name what they would deliberately leave until year two.
The mistake that outlasts the hire
Hiring one person and expecting a programme.
A single security engineer can build defaults, fix the worst exposures, and make the audit pass. They cannot review every change, be on call permanently, own every vendor assessment, and drive a cultural shift, and expecting it produces a resignation in eighteen months and a role that is harder to fill the second time because the last person left.
Decide before hiring what they will not be responsible for, and tell them in the interview. It is the single most useful thing you can offer a first security hire.
The concession
There is a real case for a breaker as the first hire: if your product is a target, if you have no idea what your exposure is, and if the finding itself is what will unlock budget. A credible internal assessment can do more to change priorities than any amount of building.
If that is the situation, hire the breaker, and be clear with them and with yourself that the second hire is a builder. The failure is hiring a breaker while expecting a programme, which is the same mismatch in the other direction.
The implication
The first security hire is a prioritisation problem disguised as a recruiting problem. What you write in the description determines who applies, and most descriptions describe a person who cannot exist.
Write down the three things they will own and the five they will not. That document is both your job description and the first honest conversation you will have with whoever takes it.
