Lessons Learned Interviewing for Security Engineering Roles
I recently completed several interviews for security engineering roles. Over a period of three months, I completed recruiting calls, phone screens, and onsites with tech companies large and small. The whole process was incredibly difficult. You may well know that standardized resources do not exist for the busy security engineer. Given how broad the domain is, where does one even start? In the hope of giving you a clearer picture of the interviewing landscape than I had, I wanted to share five lessons learned from my recent experience.
1. You don't need to know how to code
Not like a software engineer, anyway.
The biggest misconception I had before starting my job search was that I would need to pass coding interviews. I spent several weeks re-learning data structures and algorithms, thinking these would be foundational concepts to know. In retrospect, this was a massive waste of time. Across the eight companies I interviewed with, I was not asked a single data structures and algorithms question.
I'm sure mine is not a universal experience, but for someone entering the job market today, I would recommend spending much less time than I did grinding LeetCode-style problems. At most, practice with pointers, string manipulation, and maybe sliding windows. That would have been sufficient in my case.
That isn't to say you won't be expected to write any code. You should expect at least one interviewing round with a scripting component. Solving a scripting problem is not like solving an algorithms problem. As I learned, you cannot approach them in the same way. You often must skip optimizing for time and space in favor of simply writing code that achieves the task at hand.
You will need a strong command of the libraries, modules, and packages available to your preferred language. The best way I found to prepare was by prompting a chatbot to generate scripting problems. Not ideal, but at least it builds muscle memory.
2. Take your recruiter's advice with a grain of salt
Twice I was burned by believing everything a recruiter told me. For one interview, I was told to expect a casual conversation about my interest in the company and the kind of projects I would like to work on in the future. That was, in fact, how the interview began, but an open-ended domain knowledge question was trojan-horsed into our casual conversation. I was caught off guard and apparently did not answer adequately, because I received a rejection email a few days later.
For another interview, I was told to prepare to talk about my professional background and proudest achievements. So I did. I rehearsed answers to questions about my work experience and past projects. I prepared stories about some favorite memories in my career. But over the course of the entire interview, I was not asked a single question about my work history. Not one. Rather, I was grilled on gate-keeping security trivia for which my interviewer was looking for an exact answer based upon their own job experience. That interview marked the end of my candidacy.
What I took away from these experiences is that recruiters and hiring managers are seldom on the same page. Any advice you receive from a recruiter about how to prepare for an interview, while it should be appreciated, is not enough. You will have to do your due diligence and research a company's interview process on your own if you want to perform well.
3. Recruiters are sometimes screeners too
I was led to believe recruiter calls were generally low-stakes. I expected to speak to my interest in the role and why I would be a good fit. As long as I presented like a normal guy with earnest motives, I thought I would have no issues advancing to the phone screen. But that was not always the case.
One recruiter call doubled as a behavioral interview. I was asked to talk through several experiences where I had driven security outcomes at scale. I was also asked to explain how I would approach scenarios where velocity and security were in tension. This call had the feel of a full behavioral round and I cracked under the pressure.
Another recruiter call doubled as a domain knowledge quiz. I was asked relatively basic trivia questions like the difference between TCP and UDP, the mechanics of the TLS handshake, and so forth. I passed, but attempting to answer well on my feet was stressful.
My advice to the job-searching security engineer is that if you have any recruiting calls coming up, prepare for the possibility that they might be more than just recruiting calls.
4. Treat interviews like oral exams
In one way or another, every interviewing round will test the breadth and depth of your security engineering knowledge. Most often in the form of open-ended questions you must answer verbally. I found it helpful to approach these questions like I was studying for an oral exam.
Oral exams are a form of guided dialogue. The examiner asks the candidate a question and the candidate's response will shape the dialogue to follow. If a candidate answers well, the examiner typically generalizes their next question to make it more difficult. If the candidate answers poorly, the examiner will offer hints to get the candidate unstuck. A consequence is that the candidate is kept in a constant state of discomfort, which will affect their ability to deliver an answer confidently.
Although the oral exam is not designed to intimidate or distress you, experiencing these emotions is unavoidable. Much of the effort of preparing for oral exam is in learning how to get comfortable being uncomfortable so you can deliver a strong answer that demonstrates your knowledge of a topic.
The primary goal of an oral exam is to check breadth. Think of the job description as defining the topics that are fair game. If you can, also clarify the non-negotiable requirements of the role with your recruiter. That will help you further narrow the scope and focus your prep.
The secondary goal is to check depth. Your interviewer will likely steer the dialogue from a high level of detail to a low level of detail. Keep your answers brief. You don't have to say all you know in one breath. Recall Hemingway's Iceberg Theory: answer in such a way that your interviewer gets the impression that you know a lot more than you are saying. And invite them to ask you a follow-up question. I got into the habit of asking my interviewer if the level of detail I provided in my answer was sufficient before we moved on. I believe it served me well.
5. No amount of prep survives first contact with the interviewer
Much of security engineering is about resiliency. Interviewing is no different. Despite your best efforts, you will likely bomb at least one interview, if not several. Remind yourself that in no way does it reflect on your ability as a security engineer or your worthiness for a job you find desirable. It is only a hazard of an imperfect process in which imperfect decisions get made. Use failure to your advantage. One of the best tools in your arsenal is the post-mortem log. For every mock interview you complete (and for every real one too), asses your performance and make note of where you could improve.
The security engineer should be well acquainted with things not going to plan. Keep interviewing. Keep failing. That's okay. Just pick yourself up and keep moving forward. That job you are looking for is waiting for you!