Hacking The Hiring Process: Technical Interviews & Questioning

If the job hunting process is a triathlon, the technical interview phase is that portion where you get out of the water soaking wet and exhausted, and now need to ride a damn bike instead to win the race.

You've been utilizing a fundamentally different set of skills thus far, relying on your resume, LinkedIn profile and general personality to succeed.

But now it's game-time, friend - it's time for the technical interview, where the employer is looking for your general technical knowledge base, aptitude and potentially hands-on skills.

It's one of the most feared stages in the tech hiring process – and for good reason. It's unpredictable, it's challenging, and hoo boy, can it be nerve-wracking!

In this article, we're going to demystify the technical interview. We're going to break it down into manageable chunks, and give you a roadmap to navigate this step confidently and secure the offer!

Hacking The Hiring Process is a series of deep dives into each stage of the technical hiring process, with real, actionable advice and examples you can take away and implement immediately in your next job search.

BLUF - Bottom Line Up Front

If you just want a specific piece of advice in this article, the below list details the areas we'll be going through in this piece:

What are technical interviews for? Why do we do them?
The myth of the "perfect candidate" and "successfully failing" at this stage
Know Your Enemy: Preparation is King
Post-Interview Follow-up: A Neglected Tactic
Advice for Recruiters

What Are Technical Interviews For? Why Do We Do Them?

If you've ever played any type of "grand strategy" game like chess, you'll know that simple rote knowledge of the rules and possible actions isn't enough to secure victory on its own.

Accurately working out the dynamics of the specific game you're playing, predicting your opponent's likely moves and then planning your own out multiple steps ahead are what really separates the long-term, repeat winners from the pack.

The latter stages of the hiring process, especially as you climb higher up the seniority ladder, start to resemble this chess game more and more.

The right certifications and academics might get you to the game, but once you're in it - they might not be enough to win it for you.

To give confidence that they're making the right hiring decisions, employers want to see you demonstrate that "next level" of skill, rather than just knowing the right answer.

Employers want to see you apply your book/course knowledge to real-world problems that the business (or the clients the business serves) face on a daily basis.

Technical interviews (if they're done right) engineer effective opportunities to:

Watch how you think on your feet,
Observe how you solve problems (or attempt to with insufficient to no information),
Look at how you handle pressure.

It's not about what's in your toolbox per se, but how you use those tools to do the job at hand.

None of this should scare you off at all. Quite the opposite, in fact.

Give these interviews the respect and attention they deserve and you'll be gifted with an opportunity to put yourself at an unassailable advantage or punch well above your relative weight class.

The technical interview is your opportunity to shine, to prove that you have not just the knowledge to do the job, but also the wisdom to use it to the business' benefit.

What's the difference between knowledge and wisdom, you ask? I always thought this old joke summed it up great:

Knowledge is knowing that tomatoes and cucumbers are fruits. Wisdom is putting neither in your fruit salad.

Don't be this guy, basically.

So yeah...technical interviews matter. A lot.

Mindset: The "Perfect Candidate" Myth and "Successfully Failing"

Sometimes noone is expecting you to hit the bullseye.

Imagine that you finally got a chance to appear on a new game show centered around a brutal obstacle course.

The airhorn goes off and everyone just barrels their way towards their first obstacle:

Some falter at this first hurdle and withdraw, their confidence rocked early.
Others still make it further, but a confusing wrinkle in the task undermines their focus, and they falter later on.
A few exceptional individuals make it disproportionately far before they eventually admit defeat.

You're one of that last group of individuals, confused and unsure whether you did a "good job" or not. After all, you didn't finish the course.

Here's the twist: No-one finishes the course, it was designed this way from the beginning.

You'd be forgiven for thinking "Well, that sounds like it blows", but you'd be missing the point of the whole exercise.

Completion and perfection were never the goals. The true victory or failure came in your:

Approach to obstacles,
Your ability to think on your feet,
Your resilience and determination in the face of something you might not fully understand.

Late-stage technical interviews are designed in pretty much exactly this way - the test isn't pass/fail, it's an assessment of how you navigate a difficult problem or approach a situation without all the necessary tools and information.

There is no "perfect candidate" that can breeze through every question - because the interview would simply continue down another angle of questioning until the interviewee started to falter.

The interviewer (contrary to what you might believe) is not even looking for perfection, because it doesn't exist.

They're looking for things like your potential, how creative your thought process is, weaker areas that may need training, and even your level of self-awareness to identify those areas yourself.

Sometimes the goal is to keep pushing, pushing and pushing to see how you deal with pressure and to see how deep you go before you finally say "I'll be honest, I don't know."

Oftentimes, whether you actually complete the task assigned is immaterial to whether you pass this stage of the hiring process - it's all in the way you went about executing it.

A Change in Mindset

Hopefully, this helps take the pressure off you to execute flawlessly every time you interview!

Sure, you need to know your stuff in this industry - but don't mistake rote knowledge for wisdom and don't mistake expertise for perfection.

When we're all in an industry where knowledge is out of date almost as soon as we've internalized it, knowing how to adapt and learn when you're confronted with unfamiliarity is way more important than knowing everything, every time.

A technical whiz that can't admit when they're stumped can lead to enormous wastes of time, money and resources going down pointless rabbit holes.

Back in the Army, it was drilled into us that if you don't know something, then you need to swallow your pride and say something. In extreme cases, officers that can't admit they've gotten lost, or when they don't know the right solution but won't ask, can and have gotten people killed.

Having the confidence to say "I don't know, but I'll make it a priority to find out for you" isn't a weakness, it's a superpower.

Remember - at this stage of the process, the goal often isn't to get to the end of the rabbit hole or complete the task. The goal is to do yourself justice as a professional and see how creative you're willing to be, using all the information and expertise you've built over your career.

More often than not, the 'passing mark' is a lot sooner than you think, and you'll surprise yourself how far you go past it!

Take this mindset into your next technical interview, and you'll find yourself feeling and invariably doing better.

Know Your Enemy: Preparation is King

The Art of Kanban wasn't anywhere near as popular, sadly

The Art of Kanban was nowhere near as popular, sadly for Sun Tzu.

He did however, drop a famous nugget of wisdom that you've likely heard in a million LinkedIn posts:

"Know your enemy and know yourself and you can fight a hundred battles without disaster."

Our strategist friend had a point - a lot of the nerves, anxiety and pit-of-the-stomach swirling associated with interviewing stems from a lack of accurate, thorough preparation.

You wouldn't go out onto the battlefield without all the food, water, ammunition and spare parts you needed - this situation is no different. Approach every interview you do in this same manner - know your enemy and know yourself.

Know Your Enemy

The first part of knowing your enemy comes from looking at their tactics - what could they possibly throw at you?

Thankfully, this part is pretty easy, as cybersecurity interviews will tend to take one or more of the following formats:

Interviews can take a wild array of forms

We're going to dive into a few of the more common and more difficult types of interview to let you know what to expect and how best to prepare:

Whiteboard Interviews

These are very, very common in many tech interviews, including in the cybersecurity industry.

What to Expect:

Surprising exactly no-one, in a whiteboard interview you'll be asked to solve a given problem, explain a concept or design a solution on a (drum roll, please) whiteboard.

These types of interviews are designed to give whoever is interviewing you a first-hand insight into how you go about solving a problem that you haven't had time or opportunity to prepare for.

In addition, it's a great opportunity to display your technical knowledge and ability to communicate that knowledge under pressure.

Common Tasks/Questions:

Design a Secure System: This is a really common challenge in cybersecurity interviews of all kinds, but mostly technical ones. Usually the ask is something like "XYZ healthcare company is growing fast and wants to build a new corporate network from the ground up with security in mind - show me how you'd design a secure network for the client."
To succeed you'd need to consider obvious things like firewalls, access controls, data encryption, and endpoint detection and response systems (EDR). For major bonus points, bring in subjects like availability of systems, disaster recovery/backups, usability and compliance.
Respond to a Breach: Imagine a company has just discovered a data breach. How would you respond? This question is designed to assess your knowledge of the incident response, but also expect a lot of situational "cantrips" to trigger as you go through your IR response. The interviewer wants to see how you respond to questioning under pressure.
Threat Modeling: This is significantly rarer, but you could be asked to perform threat modeling for a specific system or app. How would you identify potential threats, assess their likelihood and potential impact, and plan how to effectively mitigate it?
Be prepared to justify your answers and be confident, the interviewer is likely looking to see whether you'll buckle at the first sign of pushback from a superior or whether you'll say "I don't know" when asked something clearly out of your stated experience.
Explain A Technical Concept To A Non-Technical Stakeholder: This is very popular in sales engineering, technology audit and consulting roles where the ability to explain technical concepts to non-technical stakeholders is the lifeblood of the business.
You'll often get the choice of subject or given something fairly straightforward to explain, because the interviewer is looking for how you explain the topic, not how deep your knowledge on it goes. Pick a few topics and drill this type of exercise till you don't even have to look at your notes, it will absolutely show.

Coding/Penetration Testing Interviews

These are also very, very common types of interviews - with coding interviews markedly less common outside of software development-focused roles.

I put these two together because they're both testing for the exact same thing - your ability to demonstrate relevant real-world skills in a simulated setting under pressure.

What to Expect:

Penetration testing interviews will normally consist of you being set loose on what is usually called a testing rig.

The testing rig is usually set up to mirror what could ostensibly be a simplified version of a client network, like the example below:

You will then be given an objective to achieve - this can be to compromise an administrator account, gain domain administrator or capture a series of "flags" to demonstrate your expertise.

Coding interviews will normally consist of you being given a set amount of time to write code designed to achieve an objective given to you by the interviewer.

These types of interviews are designed to give whoever is interviewing a first-hand insight into how you fare under fairly strong pressure and how you're able to translate your collective skills into demonstrable, tangible output.

After all, these roles are usually the direct producers of client deliverables!

Common Tasks/Questions:

For penetration testing interviews, the tasks are almost always one of the following:

Capture as many "flags" as possible.
Achieve root or system access on XYZ system in the testing rig.
Achieve domain or enterprise administrator access within the testing rig network.

Often, the company is not looking for you to complete every available task within the time limit, but will expect a reasonable amount of progress to be made factoring in for candidate nerves.

For coding interviews, many modern companies will use a platform like HackerRank or LeetCode to test your skills and then digest the results afterwards.

I'm no software dev, but from my research, common coding interview tasks may include:

Algorithm Design and Analysis: You might be asked to write an algorithm to solve a particular problem, like sorting a list, finding the shortest path in a graph, or searching for a specific element in a data structure. The interviewer will likely ask you to analyze the time and space complexity of your algorithm as well.
String and Array Manipulation: These are common tasks in many coding interviews. Examples might include finding the longest common substring in two strings, checking if a string is a palindrome, or rotating an array by a certain number of places.
Design Patterns: You might be asked to implement a particular design pattern, or discuss when and why you would use specific patterns.
System Design: For more senior roles, you might be asked to design a complex system, like a social network or a distributed cache.
Debugging: You might be given a piece of code with bugs and asked to identify and fix them.

Incident Response Simulation Interviews

These types of interviews are usually only used for specific roles like SOC analysts, threat hunters and threat intelligence work.

What to Expect:

An incident response simulation will typically start by presenting the candidate with a description of a hypothetical cybersecurity incident - this is the scenario description. This could involve a suspected breach, malicious network activity being detected, or a reported spearphishing attempt.

Common Tasks/Questions:

You will most likely be expected to:

Analyze initial data or indicators, and discern that a security incident has indeed happened.
Investigate the incident, and then work out the scope, severity and potential impact of the incident. Usually, this will involve analyzing log files, traffic captures, or samples of malware.
You'll then be expected to propose a response to the incident - containment/eradication/recovery etc.
Throughout you'll be expected to communicate findings and justify your decisions, just like in a real incident. This will usually include briefing management and reporting.
In some cases, you might also be asked to propose some post-incident activities, such as lessons-learned sessions etc.

Technical "Quiz" Interviews

These are probably the most common type of technical interview, because they're the quickest and cheapest to run.

They usually consist of increasingly difficult sequences of technical questions, designed to test your overall subject matter expertise and test your willingness to admit you don't actually know the answer to something.

What to Expect:

Technical "quiz" interviews tend to be pretty simple in their construction and will usually consist of either a single technical interviewer or sometimes a panel of them.

Each will normally have a topic or two they'll choose to drill you on - almost always related to the job you're applying to do.

Common Tasks/Questions:

The types of questions you might be asked in a cybersecurity technical quiz interview will normally be tailored to the specific type of job you're applying for.

However, to help you prepare in general, here are a list of common technical interview questions and their answers:

What is the CIA Triad?

The CIA triad stands for Confidentiality, Integrity, and Availability - the three core principles of information security. Confidentiality is the practice of keeping data private and secure, integrity is the practice of keeping data reliable and accurate and availability is the practice of keeping data available for users.

What is the difference between symmetric and asymmetric encryption?

Symmetric encryption uses the same key for both encryption and decryption. It's fast and efficient but sharing the key securely can be a challenge.

Asymmetric encryption uses different keys for encryption and decryption (a public key for encryption and a private key for decryption). It's more secure for data transmission because you don't need to share the private key, but it's also slower.

What are some important elements of an incident response plan?

An incident response plan should include clear roles, responsibilities and documented procedures for identifying, containing, eradicating, and recovering from a security incident, as well as learning from it to prevent it happening again.

What is a VPN and why is it used?

A VPN, or Virtual Private Network, is a service that creates a secure, encrypted connection over the internet between the user's device and the network they connect to. VPNs are used to protect the user's privacy, and allow for secure remote access to a network amongst other things.

Senior Interviews

This is one of the few interview formats that can and will change drastically depending on the seniority of the role being applied for.

Technical questions for senior roles will skew much less towards your rote subject matter knowledge and much more towards your real-world experience.

Expect a lot less "What is X and what is it for?" questions and a lot more "How would you go about implementing Y in an organization?" types of questions.

While excelling at these questions will rely heavily on how you communicate your own experience, here is a short list of common technical interview questions and a potential good answer:

How do you balance the need for security with the needs of the business, such as usability and speed of development?

You start off by understanding fundamentally that cybersecurity is intended to enable the business, not restrict it from achieving its objectives. This by its very definition entails compromise from what the textbooks might say to do.

Balance can start to be achieved through frequent, effective collaboration with the various business units and a solid understanding of how the main business processes work in their current state.

With all this in place, you can then start to tweak these processes and layer best practices on top of them to achieve a balance between effective security and the business' ability to continue operating in a profitable manner.

The company is designing its first in-house software product from scratch. How would you go about ensuring the end-to-end software development process is sufficiently secure?

I would begin by integrating security into the software development process as far as is feasible, starting with requirements generation and the design stage.

From there, I would integrate security practices into every stage of the development lifecycle - it's so much cheaper to design security into the process while building it than doing it later on once people are used to the way of working.

Secure coding practices and automated security testing would be mandatory quality gates during development, with penetration testing conducted before release and with the introduction of any new major functionality.

In a scenario where budget is tight, how would you prioritize different cybersecurity investments?

You can elaborate on this as much as you like, but the best answer is always to prioritize based on risk.

Personally, I would start with nailing down the basics if they're not there already - I want accurate inventories of my assets, software, people and organizational risks before I do anything else.

After that, I'd work in concentric circles steadily outward from there - moving into identity and access maangement to combat overprovisioning before eventually investing in advanced technology solutions at the very end, if required.

The basics done well will fend off 80% of opportunistic threat actors.

Know Yourself

This is going to be a very short section because if you've gotten this far, you should already have done most of it:

Your nerves can be drastically reduced by preparing hard, but likely never totally eliminated. Some light nerves are human but they should never affect your ability to execute on your prep work.
I have never once regretted overpreparing for an interview. The worst case scenario is that you don't use some of it and it always sends a message that you don't screw around and you're to be taken utterly seriously as a professional.
It sounds dumb, but stay hydrated. You'd be surprised how much adrenaline your brain will pump out in a high-stakes interview like this and you want your brain function operating at 100%.
If you're attempting to joke with the interviewer(s) and your joke feels even remotely risky; pick another. I promise you, it's not the time.
If any part of you is hoping "God, I hope they don't ask me about that...", then you have yourself a neon sign pointing to a potential weak spot - prepare accordingly.
Much like we discussed in a previous Hacking The Hiring Process article, ensure that you have prepared enough for an interview that you could answer two or three consecutive questions on any part of your resume.
If you can't do that without resorting to waffle or vague language, you need to get back to prep work until you can.
It's extremely common for a technical interviewer to pick a specific, non-headline, section from your resume and ask several pointed questions to discern whether you actually know your stuff or whether you're just padding out resume space.
Preparing for things like incident response simulations, coding interviews and penetration testing tech interviews really comes down to practice, but you can absolutely get your practice reps in for the other types of interview.

For example, you can practice whiteboard-style interviews by using ChatGPT to grade your "explain a technical concept to a non-technical stakeholder" response.

Can you generate a list of technical questions that I might get asked in a quiz-style interview for a penetration tester position, and then grade my answers for clarity and accuracy?

Use this prompt to practice your communication skills and subject matter knowledge for technical quiz-style interviews.

Can you generate a list of 5 simpler/fairly tough/difficult (delete as appropriate) real-world scenario-based questions I could get asked for a role as a SOC analyst or incident responder and grade my response for quality, clarity and relevancy?

Use this prompt to generate some difficulty-adjusted questions to practice your scenario response questions for blue-team roles with no hands-on lab element.

Get creative and try and get as much accurate, useful practice in as you possibly can before you get into the final interview.

Your effort will show, I promise you. Most don't rise to the occasion, they fall to the level of their training.

YOU get to control that training.

Post-Interview Follow Up: A Neglected Tactic

A little bit of effort can really help out and make the difference

Now, here's something most candidates overlook and where you go from a good candidate to a great candidate.

You've spent days, maybe even weeks, preparing for the technical interview.

You nailed every question with style, demonstrated deep technical knowledge, and you even cracked a good joke or two to show you're a cultural fit.

Your work is done, right? Let me tell you: it's not.

It's not over till the proverbial lady sings and the contract is in your inbox, friend!

The post-interview follow-up can often be the difference between snagging the job and watching it slip through your fingers like so much sand.

You might wonder, "Does it really matter?" The answer is a resounding "hell yes".

Think of it like this. You and another candidate are neck and neck, equally qualified, equally impressive in the interview. But you send a thoughtful follow-up note and they don't.

Who do you think has the edge?

Here's a guide to how you do this well:

Send a Thank You Email: Not just any email. Send a personalized, thoughtful message within 24 hours of your interview. Thank the interviewer for their time, express your continued enthusiasm for the role, and, most importantly, bring up a specific topic or discussion from the interview that you found interesting or insightful. This shows you were engaged and gives the interviewer a memorable point of reference.
Be Patient: After you've sent your follow-up note, be patient and chill the hell out. It might take a week or even two to hear back. Constantly pinging the hiring manager won't make them respond faster, but it might make you seem desperate or impatient.
Ask for Feedback: If you're not selected, it's OK to ask for feedback. This shows your continued committment to improving but could also very well help you in your next interview.

Who knows, your professionalism might even land you in their talent pool for future opportunities!

Advice For Recruiters & Interviewers

Most of this article has understandably focused on the candidate, as it's a far more involved part of the process for them than the interviewer.

However, there's still things that we as interviewers and recruiters can do to make sure we're delivering the best possible experience for our candidates:

Be Transparent

Let the candidate know extremely clearly what the type of interview they'll be doing is and what the expectations are.

This ensures the process is fair, and that the candidate doesn't waste valuable focus trying to work out what the hell you want them to do.

You want them firing on all cylinders actually doing whatever tasks you set, not deciphering your expectations and rules.

No Unicorn Hunting

No candidate is perfect, so let's look beyond the "perfect candidate" myth.

If the candidate messes up on something but it's something they can be trained on, don't necessarily disrgard them as an option.

Prioritize long-term capacity to adapt and grow over time instead of holding out for the one-man-IT-team that you almost certainly aren't paying enough to hire, even if they did exist.

Look At The Full Picture Before Choosing

This is almost certainly the most nerve-wracking stage for your candidate and they might not excel here the way they did in the behavioral interview or HR screen.

If the skills demonstrated are sufficient to make training or extra onboarding activity feasible and the candidate otherwise excelled during the process, consider looking holistically at the candidate's performance overall.

TL;DR / In Conclusion

The technical interview is an often nerve-wracking but necessary part of cybersecurity hiring.

It might be scary but with the right mindset and preparation, you'll do just fine!

There's no such thing as a unicorn and you're only human - treat yourself that way and stop expecting perfection.
Do your research and practice, practice, practice - I promise you it will show when it comes down to it.
Preparation is king and you are unlikely to regret overpreparing for an interview - especially a high-stakes one.
Follow up after your interview every time. It's good manners, and it could be the difference between you and the next candidate.

If you enjoyed this article, check out the other articles in the Hacking The Hiring Process series: