In my particular case, hiring for security engineers is ridiculously hard. If we put them through a hands on assessment, they only find cross-site scripting er

In my particular case, hiring for security engineers is ridiculously hard. If we put them through a hands on assessment, they only find cross-site scripting errors with the most basic payloads (for example) and fail to assess with more abstract thinking (like design flaws that are not part of the OWASP Top Ten). Out of ten candidates I interviewed, only one knew what same origin policy is (this is foundational). I'm not asking about elliptic curve cryptography here, and I'm pretty generous with assuming people are just really anxious. I've considered that I'm too harsh, looking for the wrong signals, interpreting noise as signal and trying to match for folks like myself instead of an objective bar. Every time I revise to try and reach the platonic ideal of an interview where: 1. There is a short hands on assessment, 2. There is a phone interview with basic theory and no trick questions, 3. We eliminate as much "culture fit" hunting as possible, 4. We basically go totally rèsumè blind, ...we still fail to interview folks who can reliably find find SQL injection in a deliberately vulnerable MySQL database. I think it's pipeline issue, personally, but I'm open to suggestions that my interview methodology sucks. I'm a big fan of 'tptacek's hiring style. Every time I get hopeful, something goes wrong and we have wasted 10 or so hours that week (or more) collectively evaluating this individual. The closer we get to the final interview or hiring decision, the more disappointing and inefficient it gets.