Full Disclosure: I am a security engineer @ Google and the following are my own opinions.
I’m here to help you out – whether you are in school, a seasoned professional or just someone who is curious about the security engineer interviews, this guide is for you. Having struggled to find my own breakthrough in the industry and having received offers from security teams of companies like Google, Facebook and Yahoo, I have been in your shoes at some point and I am writing this guide to help you in your career. Interviewing is a nerve wracking process where you never know till the end whether you made it. It also requires an initial investment upfront to spend time preparing yourself, applying for relevant roles in companies and finally going through the process. Having gone through this several times in my career at the largest tech companies, I wish I had known a few things prior to the interview that would have helped me even more.
The focus of this post is on interviewing at large tech companies but the methods I describe do apply elsewhere to a certain degree. Information security is a vast and complicated field and there are a wide variety of topics that can appear in an interview. So instead of diving into each topic, I follow a “show and tell” approach in this post where I take a question as a running example and demonstrate a framework that can be handy to effectively answer the question.
In a security engineering interview, questions generally fall in one of a few several categories:
- Open ended questions
- Knowledge based questions
- Coding questions
- Soft skills or experience based questions
The scope of this post is limited to open ended questions. These are typically the ones that require a blend of knowledge and experience. They are also the ones where a response can be a never ending discussion. Due to the nature of such questions and how they are increasingly becoming more relevant in interviews, this post puts its emphasis on this question type. Knowledge based questions can be directly answered by knowing the subject matter. They are generally of the form of – “Describe X” or “What is Y?”. For coding questions, there are already tons of resources out there including “Cracking the Coding Interview”, online programming judges etc that are sufficient for preparing oneself for this aspect of the interview. The same applies to soft skills and experience based questions where existing resources available in the public space make it relatively easy to prepare oneself.
Framework for open ended questions:
The following is a framework that I have created for tackling open ended questions. In short I refer to it as the ACEDER framework.
Ask relevant questions:
Let’s say the interviewer asks you the following relatively open ended question:
How do you go about ensuring two parties can communicate without the possibility of eavesdropping on the network?
Just by reading this question, there can be several thoughts coming to you, for example:
- Is the communication one time or an ongoing one?
- Is the interviewer asking me indirectly to describe existing protocols like HTTPs? SSH? TLS?
- Should I be designing my own protocol?
- (Insert your additional thoughts here)
While having thoughts is normal, in my experience it is best to take a moment to organize the relevant ones and get clarity before jumping into an answer. So focus on the core elements of the question, think out loud and ask clarifying questions in a structured way without jumping immediately into potential solutions. Asking questions also stops you from making unnecessary assumptions which might not hold true and may even lead you to an unwanted path. For this particular question, we do know that we need to ensure two way communication and with the property of avoiding eavesdropping. Other than that, there are no specific details that the question mentions.
A response such as the following can be a good start:
I am aware of several different existing secure communication protocols like TLS, SSH and the like that operate on the application layer as well as others like IPSec which operate on the network layer. All of them satisfy the property of being secure against eavesdropping on the network. Do you want me to focus on an existing one or is the question asking me to design my own communication protocol?
Notice that the above structured response not only shows that you are considering different layers in the networking stack and mentioning relevant protocols that satisfy the criteria of the question, you also asked a clarifying question to determine the scope of the question. This provides you a clear direction to move forward. A word of caution on this: Asking too many questions without providing some answer can be detrimental. The clarifying questions should be reasonable in quality and quantity for them to be most effective.
Cover the basics
Once you have gained clarity on what the interviewer is looking for, it is useful to cover the basics first. To provide a concrete example, let’s say in the question for communication protocols, the interviewer responds and asks you to describe TLS.
Although it can be tempting to mention the awesomeness that TLS offers using crypto magic like generating the master secret from premaster secret, it might be a better idea to first cover the basics of the protocol.
To start off, you can formulate a response:
TLS stands for Transport layer security and operates on the application layer. TLS is used in conjunction with other protocols like HTTP, IMAP and others to provide a secure communication channel for them. It uses a sequence of high level steps as follows:
- Client and Server Hello
- Key negotiation and exchange
- Follow up data transfer
(Then proceed to give a overview of each step in some detail)
Such a response prevents the idea of “the candidate could not describe the basics” from popping up in the interviewer’s mind. However what is considered as basic really depends on the level of experience you have with that particular topic. It is definitely a good idea to keep asking questions and provide more information based on the response. It is best to also state your assumptions as you go through your answer to make them clear to the interviewer throughout the interview.
Expand the breadth
While asking questions and proceeding accordingly is definitely useful, having no informative and thoughtful content as follow up defeats its purpose. As an example, let’s say after hearing your response of the sequence of steps and its details, the interviewer asks you to contrast that with SSH. The idea might be to test your breadth of knowledge and to see if you can correlate different protocols.
An appropriate response here would be to again cover the basics of SSH and to highlight specific differences among the two. Something along the lines of would be considered a good response:
SSH stands for secure shell. It operates on port 22 and is used for remote login. It uses a sequence of steps to establish a secure communication channel. At a high level:
- ID Key exchange
- Algorithm negotiation
- Key Exchange
- Follow up data transfer
Then proceed to give a overview of each step in some detail and highlight the differences from TLS e.g. no ID key exchange in TLS
Expanding on the breadth is definitely a great idea as it shows your expansive knowledge base. Therefore doing so voluntarily as you answer the question automatically puts you in a good light if done without too much deviation from the original answer (e.g. jumping to another unrelated protocol).
Increase the depth
While the idea of expanding on the breath is great, we also want to ensure that details are mentioned to convey the depth of our knowledge. Demonstrating the depth of knowledge goes hand in hand as you expand the breadth. Imagine breadth as drawing a landscape for the interviewer to visualize and then you fill in the appropriate details like colors to make it a vivid picture.
As an example for the secure communication protocols questions, depth can be demonstrated when you describe the sequence of steps involved in detail, mention relevant steps both the client and the server take, the encryption and hashing algorithms that can be used and why which one is better etc. Similarly for SSH it would be best to mention why exchanging ID is important, the algorithms involved and the pros and cons of each. Calling out relevant attacks that can occur when weak protocols are chosen further demonstrates depth and provides an opportunity to discuss related pitfalls when implementing secure communications.
Add in experience
After the basics of the question have been covered, adding in real world experience is helpful. For new graduates, this can be a project you did at school or on your own on a weekend and fits right in with your answer. For an experienced professional, this can be a project you contributed to in your previous job or a project you led other members of the team through. Irrespective of the place the experience was acquired, meshing in your experience with your answer and including the takeaways does end up enhancing your responses. This also leads to a better impression in the mind of the interviewer in several ways – First it demonstrates that you can correlate information from the past and can build on that to guide your future work. Second it also conveys your practical experience to the interviewer which gives you bonus points. A structured way to communicate this is by using the well known STAR method (Situation, Task, Action, Result).
Going back to the communication protocols question, here are several ways experience can be meshed in:
- In graduate school, I was involved in a project to test TLS security guarantees. I was responsible for setting up the virtual infrastructure and conducting tests. I set up two virtual workstations as clients and servers and emulated an active attacker on the network. I experimented with both wireshark and tcpdump for capturing network traffic and observed that the encrypted traffic was gibberish. I also emulated performing a downgrade attack to weaken the strength of encryption. The result was that I was able to verify the security guarantees that TLS offered.
- In my previous job I was tasked with upgrading all website servers when the heart bleed vulnerability was announced. I spent considerable time reading and grasping the real issue at hand, scanned the company network for hosts that were affected and worked with our partner teams to deploy patches in a timely manner.
Notice how the depth is enhanced by adding in your experience with the appropriate tools, terminology and details in your answers.
Rinse and Repeat
The above process of asking questions, covering your basics, expanding your breadth and depth along with adding your experience can be repeated till the interviewer is satisfied or you feel that the answer is sufficient and complete. It is important to note however that generally interviews are time bound and in that spirit it is best to check in with the interviewer before diving way too deep into a particular concept, algorithm or idea.
Going back to our secure communication protocols question, the check in can be introduced at relevant points within your answer. As an example when you have described the protocol and its details with some of your experience, it can be worthwhile to check by asking – “Do you want me to go deeper into any particular aspect of the protocol or applicable attacks”?
Depending on the interviewer’s response, you can proceed accordingly in the anticipated direction. The interviewer also may have a series of questions to cover and they may interject if you deviate or go way too deep in your answer than what is required for them to know.
4 thoughts on “Pwning the security engineer interview”
Can you also submit an idea of your carrier path liek your education, experience,knowledge that got you into Google
Thanks for the idea. I gave an interview recently in which I talked about all of those points you mentioned. You can find it on youtube here – https://www.youtube.com/watch?v=vZHwI-csqsE
Hi, i think there is a type in your last sentence. “our” vs “your”. 🙂
You’re right Susie. I’ll fix it.