I’ve been on both sides of the table for blockchain security interviews, and what often filters candidates isn’t the math. It’s the connection between cryptography and system design.
If you’re aiming for a security engineer role, here’s the mental model I suggest:
1️⃣ Hashing isn’t just SHA or Keccak — it’s about trust boundaries.
Understand why blockchains rely on one-way functions. Be able to explain collision resistance and preimage resistance in the context of Merkle proofs, state roots, and light clients. If you can explain how a corrupted Merkle root can invalidate an entire chain state — that’s depth.
2️⃣ Digital signatures = identity layer of Web3.
Go beyond “ECDSA = private-public key pair.” Learn nonce reuse attacks, deterministic signatures (RFC 6979), and why Ethereum moved to EIP-2098 for gas-efficient signatures. Interviewers often ask, “What if the RNG fails while generating a signature?”
3️⃣ Key management separates hobbyists from professionals.
Discuss cold/hot wallet segregation, threshold signatures (TSS), and MPC. Most projects today care more about secure custody than about perfect math.
4️⃣ Zero-Knowledge Proofs (ZKPs) & commitments.
Even if not your daily work, you must know Pedersen commitments, zk-SNARK verification flow, and the difference between trusted vs trustless setup.
💡 Pro tip: Instead of reading random blogs, review real audit reports — OpenZeppelin, Trail of Bits, ConsenSys Diligence. They expose cryptographic misuse patterns (e.g., insecure randomness, weak entropy sources, signature malleability).
That’s what interviewers mean by practical cryptography.
