Why pre-screen decentralised identity specialists before the technical panel
The cryptography in this field is well understood and the failures are elsewhere: a user loses the device holding their keys, a verifier cannot check a credential issued by a different system, and the recovery flow reintroduces the central authority the design was meant to remove. Specialists worth hiring lead with that. A short screen asks what happens when somebody loses their phone.
What actually matters when screening Self-Sovereign Identity Specialist candidates
- 01
Technical proficiency
Check hands-on command of W3C DIDs and Verifiable Credentials: which DID methods they implemented, SD-JWT VC or JSON-LD with BBS+, OpenID4VCI/VP flows, DIDComm messaging, status list revocation.
- 02
Systems and trade-offs
Probe architecture choices: ledger-anchored versus did:web or did:jwk, wallet key custody and recovery, trust registry design, and how they weighed eIDAS 2.0 ARF conformance against delivery speed.
- 03
Evidence and rigour
Test rigour around interoperability and privacy: conformance testing against ARF or Aries interop profiles, correlation and phone-home risks, GDPR data minimisation, key rotation and audit evidence.
- 04
Collaboration and communication
Assess how they aligned issuers, verifiers, wallet vendors and legal or compliance teams; look for standards body participation such as DIF, OIDF or W3C CCG working groups.
Pre-screening questions to ask Self-Sovereign Identity Specialist 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.
Systems they built
3 questions01Have you designed a decentralised identity system, and what did that involve?
Listen forA system they designed with the trust model and user numbers described, not a prototype only.
Designs that never left a document, or systems used only by the development team.
02Have you worked with digital wallet technology?
Listen forWallet work including key storage, backup and the recovery experience for ordinary users.
Wallets treated as a solved component, or key storage handled without device security features.
03Can you give an example of a project using established identity frameworks?
Listen forReal implementation experience, with the framework's limitations described from actually using it.
Frameworks named without implementation, or their constraints unfamiliar in practice.
Standards precise
4 questions04How do you design and manage the lifecycle of decentralised identifiers?
Listen forCreation, rotation and revocation all handled, with the resolution method chosen deliberately.
Rotation and revocation not designed for, or identifiers assumed permanent.
05Can you explain verifiable credentials in this context?
Listen forIssuer, holder and verifier roles explained precisely, with selective disclosure properly understood.
Credentials described as signed documents, or revocation checking not considered.
06Can you explain the difference between centralised, federated and self-sovereign models?
Listen forAn accurate comparison including where the decentralised model still relies on trusted issuers.
The model described as removing all trusted parties, or federation confused with decentralisation.
07Do you have experience with secure messaging protocols in this field?
Listen forPractical implementation work, with transport, encryption and message routing all handled properly.
Protocols named without implementation, or message security assumed from the transport.
Recovery handled
3 questions08What security measures do you consider when designing these systems?
Listen forKey compromise and device loss both designed for, with revocation reaching verifiers quickly.
Security limited to cryptography, or no plan for a compromised or lost key.
09Have you implemented a cryptographic protocol in this area?
Listen forVetted libraries used rather than custom implementations, with review sought for anything novel.
Cryptographic primitives implemented from scratch, or no independent review of the design.
10Do you have experience with data privacy law in this context?
Listen forAwareness that identity data on a shared ledger conflicts with deletion obligations.
Personal data written to an immutable ledger, or deletion obligations not considered.
Usable by ordinary people
2 questions11How do you approach interoperability between different identity systems?
Listen forSpecific incompatibilities encountered, with the effort to verify across ecosystems described honestly.
Interoperability assumed from using standards, or verification across two systems never attempted.
12Can you give an example of balancing usability against security here?
Listen forA real trade-off with ordinary users in mind, especially around recovery and key management.
Usability described as user education, or flows that only work for technical users.
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 proficiency
35%5Names specific DID methods and signature suites used, explains selective disclosure and revocation mechanics precisely, and cites libraries or SDKs they wrote against.
Systems and trade-offs
25%5Articulates trade-offs between anchoring models, custody schemes and holder privacy, with a clear rationale for why one option lost.
Evidence and rigour
25%5Backs claims with interop test results, threat models covering issuer collusion and correlation, plus documented conformance or audit outcomes.
Collaboration and communication
15%5Describes governance frameworks negotiated with real issuers and verifiers, and translates credential mechanics clearly for legal and product stakeholders.
The failures are lost keys and verifiers that cannot check credentials. A one-way video screen asks about recovery.
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 systems they built, test their standards knowledge, and check recovery and usability thinking.
What should the screen establish beyond the technology?
Whether anybody outside the project used it. These systems are frequently built for enthusiasts, and the design decisions change entirely once ordinary users are involved.
Evaluating answers
What is the strongest signal when screening this role?
What happens when a user loses their device. Specialists who shipped describe a recovery approach and its trade-offs. Anyone without one has built something people will lose access to.
How do I judge their standards depth?
Ask about interoperability between ecosystems. Real answers name the specific incompatibilities they hit. Anyone describing it as solved by standards has not tried to verify across two systems.
























