Evaluate Zero-Knowledge Proof Developer candidates across 4 weighted areas: theoretical command, from theory to hardware or code, research judgement, and explaining it to non-specialists. Theoretical command leads at 35%, so probe command of proving systems: Groth16 versus PLONK versus STARKs, polynomial commitments (KZG, FRI), elliptic curve pairings, R1CS versus AIR. Use the rubric to compare role-specific evidence consistently.
frontier research deep techcircom halo2elliptic curvesplonk starkzk snarks
TL;DR
For theoretical command, look for evidence the candidate explains trust setup, proof size and prover cost trade-offs across schemes, and cites the security assumptions each one rests on. For from theory to hardware or code, look for evidence the candidate names deployed circuits with before and after constraint counts, prover latency figures, and audit findings they remediated.
Apply the written 1–5 anchors to every answer, record the evidence behind each rating, and use the factor weights to reach a consistent overall assessment.
Complete evaluation framework
What to assess and how to score it
Review the evidence signals before interviewing. Then use the anchored descriptions—not instinct alone—to choose the score that best matches each answer.
01
Evaluation factor
Theoretical command
35% weight
Probe command of proving systems: Groth16 versus PLONK versus STARKs, polynomial commitments (KZG, FRI), elliptic curve pairings, R1CS versus AIR arithmetisation, and soundness assumptions.
Evidence to listen for
Explains the underlying theory at the level the role demands, and can go a layer deeper when pushed
Knows which results are established and which are contested
Distinguishes their own contribution from the field's
Comfortable saying where the theory runs out
Five-point scoring guide
1
Poor
Recites terminology without understanding; cannot go one layer deeper.
2
Needs Improvement
Surface familiarity; conflates established results with speculation.
3
Satisfactory
Solid grasp of the core theory; thin at the frontier.
4
Very Good
Strong command; separates settled results from open questions.
5
Excellent
Explains trust setup, proof size and prover cost trade-offs across schemes, and cites the security assumptions each one rests on.
02
Evaluation factor
From theory to hardware or code
30% weight
Ask for circuits they wrote and shipped: Circom, Halo2, Noir, Cairo or gnark, constraint counts reduced, proving times benchmarked, audits passed, mainnet deployments.
Evidence to listen for
Has built, simulated, or run something real, not only published about it
Knows the gap between the idealised model and the actual apparatus or system
Names the practical constraint that dominates in real conditions
Can describe a result that did not match prediction
Five-point scoring guide
1
Poor
Purely theoretical; no contact with implementation.
2
Needs Improvement
Some exposure but unaware of practical constraints.
3
Satisfactory
Has implemented work; understands the main real-world limits.
4
Very Good
Strong practical record; articulate about theory-versus-reality gaps.
5
Excellent
Names deployed circuits with before and after constraint counts, prover latency figures, and audit findings they remediated.
03
Evaluation factor
Research judgement
20% weight
Test how they chose between recursion, folding schemes and custom gates, and how they spotted underconstrained circuits or nondeterminism before an auditor did.
Evidence to listen for
Chooses problems by tractability and value, not novelty alone
Knows when to abandon a line of work
Reads and evaluates others' results critically
Can say what would falsify their own approach
Five-point scoring guide
1
Poor
Chases novelty; no sense of tractability or when to stop.
2
Needs Improvement
Weak problem selection; persists past the point of value.
3
Satisfactory
Reasonable judgement within a defined programme.
4
Very Good
Selects problems well and knows when to abandon a line.
5
Excellent
Describes rejecting a tempting approach on soundness or cost grounds, with the reasoning and the fix that replaced it.
04
Evaluation factor
Explaining it to non-specialists
15% weight
Judge whether they can explain a proof of knowledge, trusted setup risk, or why a ZK rollup is valid to product managers, auditors and investors.
Evidence to listen for
Explains the work to an engineer, an executive, or a funder without either mystifying or dumbing it down
Writes clearly
Collaborates across disciplines
Makes the case for resources in terms the audience cares about
Five-point scoring guide
1
Poor
Cannot communicate outside their specialism.
2
Needs Improvement
Explanation is either impenetrable or hollow.
3
Satisfactory
Adequate with technical peers; less effective with lay audiences.
4
Very Good
Explains clearly to specialists and non-specialists alike.
5
Excellent
Gives a clear, jargon-light account of what a proof guarantees and what it does not, without distorting the cryptography.
Evidence-led prompts
Interview questions for a Zero-Knowledge Proof Developer
Use these prompts to surface evidence for the weighted factors above and compare candidates against the same role-specific criteria.
01
Tell us about a project you have worked on that used zero-knowledge proofs.
02
Have you contributed to any open-source projects involving zero-knowledge proofs?
03
What libraries or tools have you used for developing zero-knowledge proofs?
04
What is the difference between the main families of succinct proof systems?
05
What cryptographic constructions do you prefer for proofs, and why?
