How to interview (founding) security engineers

How do you hire your startup’s first security engineer?

Over the last few months, I’ve been through half a dozen interview processes for founding security engineer roles. Here’s what I think actually works, and what’s a waste of everyone’s time.

In short:

• Use your standard engineering interviews.
• Tweak the system design interview more towards security.
• Use the behavioural interview to understand how they’ll work with (and not against) your engineers.

Don’t use “what’s insecure about this HTTP handler” puzzles.

What’s a Security Engineer?

To start, all engineering teams have to handle security themselves. Thanks to compliance platforms, most startups are going through security certifications like SOC2 with just their founding engineering team. But inevitably—whether it’s to address real security issues, or to close deals with enterprise customers—companies decide that they need someone who can dedicate their time to doing security.

You can’t vulnerability-scan or OWASP Top-10 your way to great security. If you’re a software startup building a product, then you need someone who can work with your product teams and build a secure foundation which will lets them ship quickly and safely. This means you need a security engineer.

So, a “Security Engineer” is simply someone with a software engineering background who has specialised in security.

While a security engineer—especially a founding one—often does a lot of operational work, fundamentally they’re software engineers.

What this post doesn’t cover

I don’t have any unique insights into the engineering hiring process as a whole. So this post won’t cover general considerations like:

• Whether you give candidates a take home task to complete vs getting them to live-code an algorithms challenge.
• If candidates should be allowed to use AI-assisted coding tools.
• What stages should be on-site vs remote.

Instead, this is about tweaks to your existing process that I think will get you the most signal about someone’s security skills.

The interview process

Your interview process for hiring security engineers should look very similar to the process you use to hire any other software engineer. These processes all look roughly the same, comprising:

• A coding challenge
• A system design interview
• A culture fit interview

A security engineer candidate may not breeze through your product engineer interviews, but they definitely shouldn’t fail them.

To get some signal about their security skills, either you tweak your existing interviews to focus more on security, or add on a specific security skills interview. I’ve seen both approaches work well.

The next few sections go over the typical engineer interview process and what I’d do to tailor them to security engineers.

Coding challenge

The coding challenge isn’t useful for gauging security knowledge. The types of toy problems used for take-home or live coding challenges are just too simple to have any interesting security discussion about. Just use this stage to test their engineering skills.

System design

The system design interview is probably the best place to gauge someone’s security skills. You’ll be asking the candidate to design a sizeable system and so there’s a lot of surface area to talk about security:

• Infra security: where and how you’ll deploy the system.
• Application security: what types of threats are most likely here (XSS, CSRF, etc.)
• Detection/response: what audit logs do you need and what signs of abuse are there.

You can easily steer the questioning towards areas you’re looking for in a candidate.

This is essentially a threat modelling session. At the extreme, you can just give the candidate a system diagram from the start and spend the whole interview on security. You get more signal on their security knowledge, but less on their engineering.

Behavioural/culture fit

The behavioural interview is where you suss out how well a candidate works with others. This is crucial for security engineers.

Entrenched security teams can become deny-by-default, forcing the rest of the business to work around them. This doesn’t work for a startup that needs to ship rapidly.

The behavioural interview is where you need to figure out someone’s ability to:

• Distinguish between on-paper security risks and things that actually matter for a startup.
• Be able to communicate to the rest of the business why a certain security control is necessary.
• Engage early in the development process, and not just be a pre-release roadblock.

Security-specific interview

Adding an extra, security-specific interview to your process can be useful. But, it’s easy to end up just testing book knowledge.

I’ve never had a useful conversation come out of being shown a small piece of code and being asked what the security issues are. In every case the conversation has gone like this:

[Candidate] There’s a SQL injection vulnerability here: you’re using string interpolation with a user-controlled value.

[Interviewer] How would you fix that?

[Candidate] Use parameterized queries.

[Interviewer] Ok great, …

If the issue is basic enough to be on your secure developer training, it’s not worth asking about.

Instead, I’d ask about real vulnerabilities they’ve dealt with:

1. How was it discovered/reported?
2. What was the response/fix?
3. Did it trigger any longer-term projects?
   • How could the vulnerability have been discovered earlier?
   • Was there additional hardening that would have lessened the impact?

Similarly, you should ask about security controls they’ve implemented proactively:

1. What risk was being addressed?
2. Why was it the important risk to address at the time? (vs all the other risks)
3. How was it rolled out to the business? What was the impact?

Final thoughts

Engineering skill tradeoff

We’re not magic: having specialised in security will naturally detract from other skill areas. While I think security engineers should be able to pass your product engineer interviews, it’s unlikely they’d meet your bar to actually be hired as a product engineer.

Coverage of security specialisms

Not only have security engineers specialised in security, often they’ve specialised within security too. In a fully-staffed security function you’ll have teams for:

• Infrastructure security
• Application/product security
• Corporate security

No-one is a master of them all.

What balance you need in a founding security engineer depends on what skills you’ve got already in the company. Have you got a strong infra team? Maybe they can own cloud security for a while longer.