This article is geared specifically toward cybersecurity positions, but you could still take a bunch of this information for other roles and industries.

I think interview processes are really fascinating for a number of reasons. This is one of the most critical pieces to building an effective team. And this can't be over-stated. Hiring the right people will impact everything in your program.

The beginning of this process starts with identifying and detailing the business needs you want to address, and then mapping the responsibilities and duties which will impact those needs. This part, alone, could be its own article... so let's assume for brevity that you've got that nailed down and you've written your job brief. Now you need to craft your interview questions!

There will be a wide range of questions and styles you could use to craft your interview, but you need to remember that your questions need to serve a purpose. What you're looking for are actionable answers. The type of answers which will help you assess if the skills a person has will support the responsibilities you are looking to delegate (and part of that can even be measured against a growth path, but that's for another article.) Some folks are tempted to ask "gotcha" questions, but I've never actually witnessed an instance where doing this actually provides any value to the interviewer. The answers to these questions are not actionable, and usually don't even relate to the responsibilities of the job.

Open vs Closed questions

To build effective questions, you are going to want to intentionally use a combination of closed and open questions.

Closed questions are questions which don't allow the respondent to provide unique or unanticipated answers. Instead, the respondent chooses from a set of preselected options meant to guide them in a specific direction. The simplest example here is asking a question where the answer is either "yes" or "no".

Open questions, on the other hand, encourage the respondent to provide unique answers based on their knowledge and experience. It's the dynamic nature of these questions which make them so powerful and valuable when assessing a person's skills. But they will also take a bit of effort on the interviewer's side to interpret them appropriately.

When I give an interview, I will intentionally mix these questions. I usually start by asking some open questions:

  • Tell me about your background.
  • Describe the last program or script you wrote. What problem did it solve?
  • How do you effectively manage your time?

There really are no wrong answers here. The candidate is going to be most comfortable in this part, because they are talking about things they are familiar with in their own experience.

Next I will start asking some more technical questions. These questions will continue to be largely open questions. I want to see how people might think about a problem, or describe a solution, based on their knowledge and experience. I'm not looking for a canned response like "ssh runs on port 22." But what I can do is carefully drop some closed questions at key points in the interview. If I have just asked a few difficult questions in a row, or if I feel the candidate may be getting a bit anxious about how they're doing, I will add a few closed questions to give them a small bit of guidance and let them feel more comfortable. Then we can work our way back to more open questions. It's a bit of a dance. You want your candidates to feel comfortable and confident enough to put their best selves forward, and this can just be really intimidating for most folks. So getting into the right ebb and flow of open and closed questions can be and incredibly useful tool for evaluating someone's real potential.

Adventuring!

So what kinds of open questions are valuable to ask? Well, one of my favourites comes in two parts. I start with a simple scenario:

"Pretend you are a malicious actor and you just compromised a machine. What are some of the things you would do next?"

The candidate will usually take a few moments to really go through this. They will respond with a variety of things like:

  • I may try to scan the network for lateral movement.
  • I would wipe the log files.
  • I'd setup a key logger to steal passwords.
  • I might setup some form of persistence.
  • etc.

The options are really endless on this one. Everyone has a different response, and it's going to depend heavily on their experience. Some folks can give you a list a half mile long, and others might need a slight nudge of encouragement here and there. Some of them will just give you the general gist of what they'd do, and others will tell you the tools and techniques they'd use to perform each action. Against, there's almost no wrong answer here.

But absolutely critical here is that I take notes when they speak. They're going to enumerate several things, and they might get excited or carried on trains of thought when they do. Once they've finished, I follow up with part two:

"As a defender, how would you protect against these things you just listed?"

This is a great opportunity to see how people approach some abstract problems. Especially when they realize they've just set the rules for themselves! They may not remember all of the things they mentioned before, but that's ok. Now there are some handy notes available which can be used to gently guide them in the right direction. And usually, people really like that you take the time to listen to what they are saying, write it all down, and use that information to help them along rather than bait them.

What I am looking for here is, now that I see you can identify problems, how do you approach solving them? And the answers are just as varied as the first part. If they spoke about scanning the network for lateral movement, I want to see what tools and techniques they would put in place to detect it. If they mentioned wiping log files, I want to see how they could ensure the integrity of the log files. Do they solve it with backups? Off-site/remote persistence of log data? Some combination of both?

In the end, you will get a much stronger sense of what a person has learned to recognize and how they may approach it. You're giving them opportunity to create their own interview adventure, and then you offer to journey through that with them. If you've done this right, you'll get a better pool of employees than any "gotcha" question could ever hope to dream.