| We do a few screens, starting with general security discussion - something like: intro, light tech/coding - just to make sure we aren't completely wasting our time The main interview centers on software security, and is focused on real world scenarios. We avoid "explain this OWASP top 10 blah blah blah" kind of questions. The goal is to see if you can reach the outcomes we expect, regardless of how you may approach them. I don't care if you can explain SQLi to me, you should be able to approach exploiting it on a live system. We will: * Give you a sample system and ask you to threat model it. Maybe you will use STRIDE, maybe you wont, but we hope you will find some threats using structured techniques. * Ask you about secure systems you have designed, why you made the choices you made, and how you would make them differently today. We want to know if you have a methodology, a structured approach, and experience. * Expose you to vulnerable code implementations, and running systems. We hope you will discover vulnerabilities. * Show you examples of our systems, and ask you how you would secure them. We want to understand if you can see, and discuss security architecture. * Role play developer interaction scenarios. Can you handle soft skills? * Have you done any of this at scale? Do you understand how to make it work for 10, and 1000 developers? Explain your experience, how would you do it differently? I can go on, but again the emphasis is evaluating whether or not you can do the tasks we need you to do, with a high degree of quality in whichever way works best for you, while also being able to completely ignore your resume if we want. It is extremely difficult for us to consider hiring junior candidates, and we frequently encounter candidates with no deep experience. While it is unfair to expect candidates to have spent time at home treating this as a passion project, those are the ones im going to hire because they can deliver the outcomes in an interview. To combat the hiring difficulty, we have arrived at this approach which allows us to send candidates through the machinery quickly, with low bias. |
Huh interesting. I work in infosec (but not a hiring person). I would normally rank this as an important skill. Not because i actually care about getting an explanation but because half the job is getting non security devs to care about security issues/fix them/not make them in the future. In my experience it is really difficult to do that if you can't explain the vulnerability to them.