Talent · Engineering
Software, data, platform, security, and quality roles on contract, contract-to-hire, or direct hire. Every candidate is screened against the stack you actually run.
01Roles we fill
If the role you need is next to one of these rather than on the list, send it anyway.
02The discipline
A résumé tells you where somebody sat. We ask candidates to walk through a system they built, name a decision they now think was wrong, and describe how it behaved the day it failed. Engineers who have carried the pager answer that question differently from engineers who have not.
A backend engineer who has run a database under real load is not interchangeable with one who has only used an ORM. We take the versions, the scale, and the failure history of your systems at intake. Then we screen against that, not against the words in the job advert.
The distance between a mid-level engineer and a senior one is visible in what they refuse to do. We look for people who push back on scope, name the risk early, and can explain a tradeoff to somebody who is not technical. That is harder to fake than a framework list.
03Screening
The general process is on the talent page. These are the parts that only apply here.
Not a recruiter with a keyword sheet. The screen covers system design at the level the role needs, one code reading exercise, and a walk through the candidate’s own production incidents.
Which database, at what size, under what traffic, and what broke. Answers that stay general do not clear the screen.
For platform, SRE, and security roles we ask what the candidate was paged for, how often, and what they changed so it stopped happening.
Technical references come from the person who read the candidate’s pull requests or ran their design reviews, never a character referee.
04Send the role
2 minutes of detail here saves a discovery call. Attach the job description if you have one.
One intake covers every role. Take a look at the other practice areas, or send them all through the form above.