Why pre-screen post-quantum researchers before the technical panel
Several schemes that reached late standardisation rounds were broken, sometimes by classical attacks running on ordinary hardware. That history is the best available test of judgement in this field: a researcher who followed it can explain what the attack exploited and what it says about the assumption. A short screen asks about one, which distinguishes analysis from familiarity with a candidate list.
What actually matters when screening Post-Quantum Cryptography Researcher candidates
- 01
Theoretical command
Check command of lattice, code, isogeny and hash-based constructions: ask them to compare Module-LWE hardness assumptions in ML-KEM against SIKE's collapse and Falcon's trapdoor sampling.
- 02
From theory to hardware or code
Probe implementations they wrote: constant-time NTT in C or Rust, liboqs or PQClean contributions, hardware accelerators, side-channel countermeasures, and measured cycle counts or FPGA area.
- 03
Research judgement
Test how they choose problems: why pursue a given cryptanalytic direction, when to abandon a scheme, how they set parameters against uncertain quantum resource estimates.
- 04
Explaining it to non-specialists
Assess how they brief CISOs or standards committees on migration: crypto-agility, harvest-now-decrypt-later risk, hybrid TLS deployment, and NIST or CNSA 2.0 timelines.
Pre-screening questions to ask Post-Quantum Cryptography Researcher 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.
Research they produced
3 questions01Can you discuss a recent paper or project you worked on in this area?
Listen forTheir own contribution described precisely, with what the result established and what it did not.
Papers described at abstract level, or contribution to a multi-author work left unspecified.
02Which quantum-resistant algorithms have you worked with directly?
Listen forSpecific schemes worked on analytically or in implementation, with their parameters understood.
Schemes named from the standardisation list with no direct work on any of them.
03Can you describe a time when you collaborated with other researchers?
Listen forReal collaboration with the division of work clear, and disagreement resolved through analysis.
Collaboration described loosely, or contributions of others not acknowledged.
Depth in a family
3 questions04Describe your experience with lattice-based constructions.
Listen forThe underlying hard problem and its parameters understood, with known attacks and their cost discussed.
Lattices described at a conceptual level, or parameter choice not connected to attack cost.
05Describe your experience with code-based constructions.
Listen forKey size trade-offs understood, with the long history of analysis on these schemes appreciated.
Code-based schemes dismissed on key size alone, or their maturity not recognised.
06What is your experience with hash-based signature schemes?
Listen forStateful and stateless variants distinguished, with the state management hazard properly understood.
State reuse risk not understood, or stateful schemes recommended without that caveat.
Analysis not citation
3 questions07How do you assess the security of a quantum-resistant scheme?
Listen forBest known attacks and their complexity considered, with security levels reasoned rather than cited.
Security taken from a specification claim, or attack complexity not independently considered.
08How familiar are you with security proofs in this context?
Listen forProof models and their assumptions understood, with an honest account of what a proof does not cover.
Proofs treated as guarantees, or model assumptions not distinguished from real-world security.
09What are the main challenges in developing these cryptographic systems?
Listen forConcrete difficulties named such as key and signature sizes, side channels and parameter selection.
Challenges described as adoption or awareness, with no technical difficulty identified.
Implements and explains
3 questions10Have you implemented one of these algorithms, and how did you approach it?
Listen forImplementation with constant-time behaviour and side channel resistance both treated as hard requirements.
Implementations written without timing considerations, or side channels treated as a later concern.
11What is the significance of the standardisation process in this field?
Listen forThe process understood including why candidates were withdrawn and what the analysis revealed.
Standardisation treated as settling the question, or withdrawn candidates not known about.
12Can you describe explaining complex cryptographic ideas to a non-expert audience?
Listen forExplanation pitched at the decision rather than the mathematics, with uncertainty stated honestly.
Urgency created through exaggeration, or an inability to explain without the mathematics.
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.
Theoretical command
35%5Discusses concrete security estimates, core-SVP hardness, and known attack advances with precise reference to the underlying assumptions.
From theory to hardware or code
30%5Names merged code, benchmarks on specific targets (Cortex-M4, AVX2), and explains how timing leakage was eliminated and verified.
Research judgement
20%5Describes an abandoned or pivoted line of research with the evidence that triggered it, plus deliberate conservatism in parameter choices.
Explaining it to non-specialists
15%5Translates hardness assumptions into migration decisions non-cryptographers act on, without overselling or hand-waving residual uncertainty.
Schemes that reached late standardisation rounds were broken on ordinary hardware. A one-way video screen asks about one.
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 research they produced, test their depth in a mathematical family, and check analysis and implementation.
How does this differ from an architect screen?
An architect designs migrations and systems; a researcher analyses the schemes themselves. Weight mathematical depth, cryptanalysis and security proofs over deployment planning and system integration.
Evaluating answers
What is the strongest signal when screening this role?
Explaining a scheme that was broken and what the attack exploited. Researchers who follow the field can do it. Anyone who only knows the surviving candidates has read summaries.
How do I judge their depth?
Ask about the hardness assumption underlying a family they know. Real answers state the assumption and where it is not proven. Anyone treating security as established has misunderstood proofs.
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
