Why pre-screen smart contract auditors before the technical interview
The stakes are unusual: deployed code is immutable, funds move irreversibly, and the interesting vulnerabilities are economic rather than syntactic. Automated tools catch the known patterns and miss the logic flaw in how a contract prices something. Auditors worth hiring find those and are candid that an audit reduces risk rather than removing it. A short screen asks what they missed on a past engagement.
What actually matters when screening Smart Contract Auditor candidates
- 01
Technical depth
Probe depth in Solidity and EVM internals: reentrancy patterns, delegatecall proxy storage collisions, signature replay, oracle manipulation, plus tooling such as Foundry, Slither, Echidna, and Halmos.
- 02
Real incidents and findings
Ask for specific audits shipped: protocol names, lines of code reviewed, critical and high findings, Code4rena or Sherlock placements, and any live exploit they postmortemed.
- 03
Risk judgement
Test severity calls: how they weigh likelihood versus funds at risk, judge admin key and upgradeability risk, and separate real findings from theoretical noise.
- 04
Getting things fixed
Look for how they drive remediation: rewriting fixes with dev teams, verifying patches on the diff, mitigation review rounds, and disclosure etiquette on live protocols.
Pre-screening questions to ask Smart Contract Auditor candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Audits they ran
3 questions01Do you have experience auditing high-value or high-risk contracts?
Listen forEngagements with value at stake described, and their own role distinguished from the wider audit team.
Firm reports offered with no personal contribution, or no audit of code that held real value.
02Can you discuss a challenging audit and how you handled it?
Listen forA complex protocol where the difficulty was understanding intended behaviour, not reading the code.
Difficulty described as codebase size, or no audit where the economic design was the hard part.
03Can you explain how you have handled a security incident in a deployed contract?
Listen forIncident response including disclosure timing and coordination with the protocol team under pressure.
Vulnerabilities disclosed publicly before a fix, or no experience of a live incident.
Beyond tool output
4 questions04What are the most common vulnerabilities you find during audits?
Listen forAccess control, accounting and economic assumption failures named alongside the standard classes.
Only textbook vulnerability classes named, or findings that a public tool would have produced.
05What is your experience with contract programming languages?
Listen forDeep familiarity including compiler behaviour and the low-level details that affect security.
Language knowledge at tutorial level, or no awareness of how compiler versions change behaviour.
06Do you have experience auditing upgradeable contracts?
Listen forProxy patterns understood including storage collisions and initialisation, with upgrade authority examined.
Upgradeability treated as a feature rather than a risk, or upgrade permissions not reviewed.
07Do you have experience with multi-signature wallet contracts?
Listen forSignature verification and threshold logic examined carefully, with key management practice questioned.
Multi-signature treated as inherently safe, or signer key practices considered out of scope.
Systematic method
2 questions08Can you detail the methodology you use for auditing?
Listen forA systematic process from specification to code, with intended behaviour established before reading.
Method described as reading through the code, or no attempt to establish intended behaviour first.
09Are you comfortable performing both manual and automated review?
Listen forAutomation used for coverage with manual review for logic, and tool output validated rather than reported.
Reports built from tool output, or manual review limited to confirming automated findings.
Honest about limits
3 questions10How do you approach risk assessment for a contract?
Listen forSeverity assessed by value at risk and exploitability, with an honest statement of what was out of scope.
Severity assigned by category, or scope limitations not stated clearly in the report.
11How do you ensure confidentiality of the business logic you audit?
Listen forPre-disclosure material handled carefully, with no trading on information learned during an engagement.
Client code discussed publicly, or no clear position on trading in protocols they audit.
12How familiar are you with decentralised finance protocols?
Listen forEconomic attack vectors understood including oracle manipulation and flash loan assisted exploits.
Protocol mechanics not understood, or economic attacks treated as outside an audit's scope.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Technical depth
35%5Explains bug classes at bytecode and storage-slot level, and names invariants they wrote in Foundry or Echidna to catch them.
Real incidents and findings
30%5Cites named engagements with severity counts, links public reports or contest profiles, and describes findings the client actually confirmed and patched.
Risk judgement
20%5Justifies severity using concrete attacker cost, preconditions, and value at risk; concedes when an issue is informational rather than inflating it.
Getting things fixed
15%5Describes fix review cycles where the patch introduced new issues, and shows tact handling disclosure on deployed contracts holding user funds.
Deployed code is immutable and the interesting flaws are economic, not syntactic. A one-way video screen asks what they missed.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for this role take?
Fifteen minutes across eight to ten questions, answered async. Enough to establish audits they conducted, test their vulnerability depth, and check methodology and honesty about limits.
Should I ask for published audit reports?
Yes, where they exist. Public reports show reasoning and severity judgement, and asking which findings were theirs distinguishes an author from someone listed on a firm's report.
Evaluating answers
What is the strongest signal when screening this role?
Something they missed. Auditors with real engagements have had a finding surface later and can describe what their process failed to catch. Anyone with a perfect record is either new or evasive.
How do I judge their depth?
Ask about the most interesting bug they found. Real answers describe economic or logic flaws specific to the protocol. Anyone naming only standard vulnerability classes is running tools.
Go deeper on this role
Sanat has been hiring since 2012 and watching the recruitment industry change up close ever since, and turned that screening process into Hirevire's video screening platform. LinkedIn
