IT Recruiter

Keyword matching rewards whoever wrote the longest tool list. Signal sits elsewhere. Look at what the person owned rather than what their team used: whether they are named on a migration, whether they carried on-call, whether the systems described were built or inherited. Look at the shape of the environment, because someone who has only worked at one scale may not transfer to another. Read tenure alongside what shipped during it. Then hand the shortlist to the engineering manager with your reasoning attached, so a wrong read gets corrected rather than repeated.

By owning everything around the screen and being explicit about the one part they do not own. The recruiter decides who reaches it, briefs the engineer running it on what to probe for, protects the slot so it happens promptly, chases the outcome, and turns the verdict into a decision the candidate hears quickly. What the recruiter must never do is reinterpret the engineer's verdict or overrule it on instinct. Where the screen keeps producing surprises in both directions, the fault usually lies in the brief rather than in the grader.

Build when technology hiring is continuous and central, because the accumulated knowledge of your systems, your teams and your past rejection reasons is the real asset and it cannot be rented. Buy when the need is a burst, a first hire in an unfamiliar specialism, or a market where you have no presence at all. A common middle path is one in-house technical recruiter plus suppliers for the scarcest profiles, which keeps internal knowledge growing without paying a permanent salary for occasional searches.

The process is not the problem. A generalist who runs excellent searches elsewhere still stalls here, because almost every judgement in a technology search is a technical one. Which of two backgrounds is closer to what the team needs. Whether a gap in a named tool is trivial or disqualifying. Whether a person describing a system they maintained actually built any part of it, or inherited all of it.

Without that judgement the recruiter falls back to matching words. Shortlists arrive full of people whose documents contain the right terms and whose experience does not fit, the engineering manager rejects them without being able to explain why in a way that transfers, and the search restarts on the same footing. The stall rarely presents as a technical gap. It presents as a manager who is never satisfied.

Stack literacy is knowing enough about how software is built to hold a real conversation and to reason about substitution. It means understanding what a language, a framework, a datastore and a deployment layer each do, which of them are close cousins, and which combinations signal a particular kind of team or a particular era of engineering. It does not mean being able to write the code.

The boundary matters because recruiters who overreach lose credibility faster than those who admit the limit. Anyone claiming to evaluate architecture will be found out in a single conversation. A recruiter who says plainly that technical depth is the engineer's call, and then asks a sharp question about scale or team structure, keeps the room. Aim for literacy, and treat expertise as somebody else's contribution.

Engineers in demand receive constant approaches and filter them in seconds. What survives is specificity: a message showing the sender read something the person actually built, naming the problem the team is working on, and being honest about the parts that might not appeal. Volume templates fail not because they are automated but because they are interchangeable, and an interchangeable message is indistinguishable from every other one that arrived that morning.

Two things sink an approach immediately. Getting the technology wrong, which signals the sender does not understand the role and will waste the reader's time. And withholding the basics, particularly the pay range and whether the work is remote, which reads as a negotiating tactic before a relationship exists. Practice on pay transparency differs by jurisdiction and some places now require disclosure, so check the local rules where you hire.

Calibration is a working habit, not a single meeting. The productive version is a short review of a small batch of real profiles early in the search, where the manager says yes, no or maybe and, crucially, gives the reason in terms the recruiter can reuse on the next hundred profiles. Two or three rounds of that convert a vague brief into a working filter.

The failure mode is a manager who rejects without reasons, or gives reasons that are unwritten preferences. Push for the underlying criterion every time: not that someone is weak, but which part of the work they would struggle with and why. A recruiter who leaves calibration holding a set of decision rules can run the search alone. One who leaves holding a list of rejected names cannot.

Assume anyone worth hiring is in several processes at once and that yours is being compared on speed as much as on substance. A slow feedback loop is not a neutral delay, it is a decision to lose the people with the most options. Sequence the process so the expensive stages happen only once both sides are genuinely interested, and protect the gap between stages harder than the stages themselves.

Expect a counteroffer at resignation and prepare during the search rather than after, by understanding what would actually have to change for the person to stay where they are. Contract and permanent hiring also behave differently: contract markets move in days and price on availability, permanent searches move in weeks and price on progression, and a recruiter fluent in one will misjudge the other.

A US IT recruiter fills technology requisitions for the United States market, and a large share of that work is delivered by teams in other time zones working US hours. Requisitions often arrive through a client's vendor management portal rather than directly, carrying a submission deadline, a rate ceiling and several suppliers working the same role — so submission speed and quality decide outcomes more than sourcing reach does.

The vocabulary of that market is distinctive, and most of it concerns how a worker is engaged and paid rather than recruiting technique. Which engagement type may lawfully be used, who carries which obligation, and what documentation is required are employment, tax and immigration questions that differ by state and change over time. They are settled with qualified counsel for the specific arrangement, not from a recruiting glossary.

Technology roles age for a small number of repeated reasons. The requirement list carries every technology anyone on the team has touched, so it describes nobody. The compensation band was set before anyone tested it against the market the role actually competes in. The interview loop has more stages than in-demand candidates will sit through. And feedback after a technical screen takes days, by which point the strongest candidate has closed elsewhere.

Unblocking is usually a conversation with the hiring manager rather than more sourcing. Split the requirements into what the person must have on day one and what they can acquire, and hold the first list to a handful of items. Re-test the band against live offers rather than last year's structure. Collapse stages that assess the same thing twice. Then agree a feedback turnaround the panel can genuinely meet.