How I Studied for My Amazon Security Engineer (L4) Interview

I interviewed with Amazon for a security engineer (L4) role during my 2021 job hunt as a new grad. I received an offer and worked as a security engineer for one year, before switching internally to a software engineer (SWE) role (L4). In this article, I’ll explain how I prepared for my security engineer interview. I won’t be going over the interview format or questions as there’s better resources.

I’ve broken this article up into two sections: technical (security, coding, general computer science (CS) concepts) and behavioral.

Technical 📱

1. Security 🔒

Glassdoor is an amazing tool to learn about interviews at companies (questions, format, difficulty). I used it to identify, common security questions.

List of questions written by two anonymous Glassdoor users

These two were my main studying lists. Prior to the Amazon interview, I did a cybersecurity research internship for 10 weeks my sophomore summer, where I developed a solid foundation in cryptography, some cyber attacks and general security concepts. There were many things I never heard of like CSRF. With little time to prep for my final round, I only reviewed familiar topics.

Out of everything above, here’s what I already knew and reviewed. There’s a few extra topics below, that’s aren’t listed in the Glassdoor screenshots above. These are extra topics, I knew and reviewed.

Cryptography 🗝️

Symmetric vs. Asymmetric Encryption: This was a very common question I’ve seen throughout Glassdoor responses. Know which is faster and why. What important problem does asymmetric cryptography solve? Why don’t we just use symmetric/asymmetric cryptography for everything? Knowing the tradeoffs between each type and the problems they solve is critical.
Hashing: Knowing all important properties (non-reversible, avalanche effect, quick computation, collision-resistant, deterministic), hashing vs. encryption, how passwords are hashed (using a salt, hashing is done multiple times to slow down attackers calculating the hash, through brute force or other tactics, all of this is often done using a key derivation function/password-hashing function). Know the effects of having a high iteration count for hashed passwords (whatever hashing you do on a password to slow down attacks, will be done when a user logs in). There’s a tradeoff of not increasing the password iteration count too high as users will experience more lag when logging in (the web server will need to take the password entered by the user, hash it multiple times, add in a salt the server knows then compare it with the hash stored in the database). What is a hash collision? What makes a good or bad hash function? Give examples of how hashing is used besides passwords?
Salt and Pepper: Difference between both and why the salt is usually stored in plaintext.
Transport Layer Security (TLS): What it does, all handshake steps, modern/secure versions used (TLS 1.2 and 1.3), cipher suites (what each part of the cipher suite represents). Does TLS use TCP or UDP (technically, a trick question as TLS isn’t tied to any transport protocol but the answer an interviewer would likely expect is TCP)? Does TLS require TCP (it doesn’t as it only needs a reliable transport protocol, which TCP provides for the internet)?
Advanced Encryption Standard (AES): AES Modes (GCM vs. CBC). Which mode is more secure and why, AES versions (256, 384, 512), AES always encrypts in 128 bits at a time, AES-128 is strong enough, though AES-256 is recommended.
Plaintext vs. Ciphertext vs. Cleartext: Just knowing the definitions of each is enough.
Elliptic Curve Cryptography (ECC) and RSA: Acknowledgement that asymmetric keys need to be larger to achieve the same level of security as symmetric keys. Asymmetric keys are weaker due to the complex math behind them. Bonus points if you know why. Know the key exchange process for an asymmetric cryptographic algorithm. Other uses of asymmetric cryptography besides key exchange. Why prime numbers are important in cryptography? Why computers struggle to calculate prime numbers?
One-time Pad: Unlikely to come up but I think you’ll impress your interviewer if you remember this.
Cryptographic Keys: The strength of the encryption is dependent on the strength of the key (size and entropy) and other factors (i.e. strength of encryption algorithm). Different forms of key derivation (PRNG-generated key (i.e. using Random/SecureRandom class in Java), key generated via asymmetric cryptography, key derivation functions. Know the name of a key derivation function (i.e. PBKDF2) and why they’re used when generating things like passwords. What is key stretching?
Entropy: What it is and how it relates to cybersecurity.
SSL/TLS Certificates: Why they’re important, understand how its related to the padlock icon showed on browsers, certificate authority, Java truststore vs. keystore, self-signed certificate.
XOR (Exclusive Or — a boolean operation): Why XOR is extremely important in cybersecurity.
Types of Encryption: Payload encryption (i.e. encrypted HTTP body) vs. in-transit encryption (i.e. TLS) vs. at-rest encryption (i.e. encrypting data stored on a hard drive/SSD).
Nonce: Define it and give an example of how it can be used (i.e. in an encryption algorithm, a nonce can be used to add more entropy). What is an initialization vector (IV)? Give an example of its usage. What is the difference between an IV and a nonce?
Random Number Generators: Understand why computers can’t generate truly random numbers? This is why random number generators used by computers, are called “pseudorandom” (fake) number generators (PRNGs).
Secrecy: Forward secrecy (aka perfect forward secrecy).
Crypto Algorithms: Know the names of popular crypto algorithms (new and old): ECDH, ECHDE, AES, DES, 3DES, RC4, RC5, SHA1, RSA, SSL, TLS. This is just in case you get asked to name algorithms, give examples of old algorithms or some other trivia-like question.

Cyberattacks 👾

Password Attacks: Dictionary attack, rainbow table attack
Databases: SQL injection (what it is, how to protect against it, knowing that its a common vulnerability)
Networking: Denial of service (DoS) attack , distributed denial of service (DDoS) attack, man-in-the-middle attack

General Security Concepts 🚨

Perfect Security: There’s no such thing as “perfect security”. A secure system is only as strong as the weakest link (which is often the user). There will always be new vulnerabilities discovered, employee-targeted phishing attacks and more powerful computers to help crack crypto algorithms.
Security via Obscurity: Obscurity can provide some extra security but it can’t be relied upon. The attacker sometimes knows the system/algorithm. For example, attackers know the inner workings of all popular crypto algorithms but many of them are still secure. It may be helpful to assume they do know to adopt a healthier security mindset. In the real world, most systems are obscure (their internal architecture and code base is private), so obscurity isn’t inherently bad. It’s seen as bad, typically when it’s relied upon, instead of primary defensive protections.
Security Isn’t an “End State”: Security engineers and hackers play an endless game of cat 😺 and mouse 🐭. Cats (security engineers) are adept hunters and even emit a chemical that deters mice (hackers). Although, cats alone may not stop mice from entering a home. Mice continue to learn clever ways to avoid cats (like traveling through walls). Just like these archenemies, security engineers work on improving security while hackers discover clever ways of breaking into systems.
Too Much Security: Be careful what you wish for 🪄. More security can lead to worse performance (TLS introduces more latency), a worse user experience (imagine needing two factor authentication every time you logged into your bank account on the same laptop) and can cost more money than its worth (a security company may over-engineer a security solution). For example, is a 200 character password limit necessary? Security additions like these may not add enough value to justify their investment and could deter end users depending on the consequences.
Don’t Reinvent the Wheel: Just like in software engineering, we want to reuse things (authentication services, crypto algorithms, security tools). For example, creating your own hash or encryption algorithm is discouraged as there’s likely an existing solution that’s appropriate. There’re entire teams, researchers, managers, etc. dedicated to working on popular security tools and algorithms. The consequences for an insecure implementation can be catastrophic 🔥.
Security As an Onion: What do onions 🧅 and secure systems have in common 👀? Layers and lots of them! Consider a web application for a hypothetical online clothing store called “Shopolisa” that’s hosted in the cloud (AWS). In AWS’ data centers, there’s physical locks on doors. On Shopolisa’s AWS servers, automated patching is done to apply monthly security updates to the operating system. The data of retail customers is encrypted at rest. All these protections provide security against different attacks. It’s important to not ignore other layers and additional defensive-in-depth protections.

As you can see, cryptography was most of my studying. Since I wasn’t told about the interview format, I predicted my interviewers would tailor questions based of what my resume looked like. I mentioned many things listed above in my resume.

The security engineering interview process, seems less standardized than the typical SWE one. So you may get completely different topics. I do think cryptography, is Security 101 as they’re fundamental concepts that are related to many security concepts. They will also give you perspective on how data is secured on the most fundamental level. So I’d make sure you understand the topics well as they usually come up in interviews.

I only knew a few cyberattacks so I refreshed my knowledge. Understanding hashing well is critical as it’s important for many crypto algorithms. If you have time, study cross-site scripting, cross-site request forgery and server-side request forgery as those are complex, yet common security vulnerabilities. I’d also highly recommend reading up on the OWASP Top 10 to show you’re aware of current security trends as it may demonstrate passion. OAuth and authentication (session vs. token authentication) are both common topics for interviews. Some other subjects I’d highly recommend studying are: incident response, threat modeling and least-privilege permissions. Lastly, this resource, provides a very comprehensive list of other topics to study.

Some Glassdoor users reported doing a manual code review, where you look for security issues in code. It sounds obvious but be conscious that hard-coded credentials are a problem. Hard-coded credentials may seem so obvious that you may miss it, while looking for more complex vulnerabilities!

2. Coding 👨🏽‍💻

I had no idea if there would be a coding portion in my Amazon security engineer interview. Although, by browsing Glassdoor, I realized coding rounds were common. Since Amazon is a big tech company, I knew if there was a coding round, it’ll likely involve the traditional Leet-code style interview question(s). This involves coding up a solution to a problem in 30–45 minutes, explaining your thought process and stating the time and space complexity. Since this is a security engineer interview, I knew there’d be less emphasis on this (easier and less coding questions). From what I’ve seen from others, this lined up.

I studied Leetcode for about a year. Why so long? It’s a long story. I applied to the security engineer role as a backup for the chance to work at Amazon. My goal was always to be a software engineer. My interview prep for this interview, lasted only about two weeks. I studied and solved 50–60 leetcode problems (didn’t use any guide like Blind 75 because I didn’t know about them) but inconsistently during the school year. My goal was to maintain my GPA and pass all classes. In hindsight, I could’ve sacrificed my GPA more to study.

After studying, I was comfortable doing Leetcode easies but would struggle to solve most mediums with an optimal solution in a 30–45 interview.

Here’s what I knew at this point:

Data Structures: Array, Linked List, Hash Map, Graph, Tree, Stack, Queue, Heap, Binary Search Tree
Algorithms: Binary Search, Breadth-first Search, Depth-first Search
Other Common Concepts For Coding Interviews: Time & Space Complexity, Dynamic Programming, Greedy, Memoization, Recursion, Quick Sort, Amortized Analysis

You may notice, I didn’t touch advanced data structures like trie, disjoint set (union find) or topics like backtracking, sliding window and topological sort. I didn’t make it that far. Out of the missed topics, sliding window, backtracking and topological sort would be very useful. The rest, I mentioned in this paragraph, would be overkill. You may have a harder coding interview, though I doubt it’ll be more than a Leetcode medium. I was way more prepared during my Amazon SWE interviews next year.

I’d focus on studying security concepts first, then covering your grounds in the important data structures and topics with Leetcode (using Blind 75, Grind 75 and/or Neetcode 150). Before the interviews, I only reviewed my past solutions to about 30 Leetcode problems. I also documented popular Java classes, methods and functions I used in interviews (see the resources section). I reviewed them for about 15 minutes before the interview, along with other behavioral stuff I’ll mention later.

3. General CS Concepts 💾

Knowing how comprehensive big tech interviews can be, I brushed up on other CS concepts.

Networking: TCP/IP layers, OSI layers, IP addresses (iPv4, iPv6, two parts of an IP address), MAC address, port numbers, subnet, subnet mask, DNS, modem, router, gateway, TCP vs. UDP, connection-oriented vs. connectionless, checksum, LAN, WAN, persistent vs. non-persistent HTTP
Object-Oriented Programming: Abstract classes, Interfaces
Misc: Upcasting vs. downcasting, what “final” keyword does to a class in Java, what makes a good unit test

I studied #2, in case of an object-oriented design section and #3 if I was asked about these directly. #2 and #3 were very personal to me as I wanted refresh my memory on these. I would brush up on general CS concepts, you expect may show up or are weak in. I’d say networking is huge! You should have a solid understanding of networking concepts as many cyberattacks happen on……you guessed it, networks! I spent many afternoons refreshing my memory on networking to shake off that rust 📚.

Behavioral 💬

Photo by LinkedIn Sales Solutions on Unsplash

Amazon is notorious for its challenging behavioral interviews. It’s well documented that you’re expected to provide answers to various questions and tie them to leadership principles. I’ve always been good at behavioral interviews. I always felt they exist to generally make sure you’re not crazy 😂, evaluate how you’ve handled past situations and gauge how they’d like working with you.

I will say, take the behavioral interview seriously. From my experience, Amazon’s behavioral interviews are the most difficult.

For behavioral interviews, I typically always prep for the same questions. My goal is to practice thinking on my feet and switching from a hyper-focused mode to a sociable one. Here’s an example of one question I prepped and an answer.

11. What do you do if you disagree with your boss?

I’d clearly express why I disagree but also listen to my boss’ perspective. Depending on the situation, I might imagine myself in their position to better understand their perspective. I would be open-minded and convinced if a good argument is made. Although, I’d also consider convincing them, if I felt strongly about it. Sometimes, the best solution is a hybrid approach so I’d suggest compromises as well, if applicable.

Conclusion 🎬

Hopefully, this gave you insight. All of this, may seem intimidating but it’s knowledge I’ve accumulated over 4 years of college. It’s always easier, relearning old concepts than new ones. Best of luck, in your security engineering interviews!

I write other tech articles (job hunting tips, common questions from CS students, tech quizzes, whether college is worth it, personal stories, etc.). If you like this article, you can follow me on Medium. My first goal is to hit 100 followers and the support I receive, encourages me to continue writing. Thanks for reading 👀!

Resources 📚🔎

Resume I Used to Apply to Amazon’s Security Engineer (L4) Role: https://drive.google.com/drive/folders/1xFWFc2T6IA_4kAYIGtbNWHI6nQ8TSI4a?usp=sharing

Amazon Security Engineer L4 (2021) Job Description: https://drive.google.com/drive/folders/1xFWFc2T6IA_4kAYIGtbNWHI6nQ8TSI4a?usp=sharing

My Coding Interview Notes (Note: many sections have been added as this is the current version and not the version I used in my Amazon security engineer interview): https://drive.google.com/drive/folders/1xFWFc2T6IA_4kAYIGtbNWHI6nQ8TSI4a?usp=sharing

A Google Security Engineer’s Guide for Studying: https://github.com/gracenolan/Notes/blob/master/interview-study-notes-for-security-engineering.md#coding--algorithms

Amazon Interview Guide (General): https://www.amazon.jobs/en/landing_pages/interviewing-at-amazon

Amazon Interview Guide (Behavioral): https://www.amazon.jobs/en/landing_pages/in-person-interview

Glassdoor: https://www.glassdoor.com/

Levels.fyi (Amazon): https://www.levels.fyi/companies/amazon/salaries

Leetcode: https://leetcode.com/

Neetcode: https://neetcode.io/

Grind 75: https://www.techinterviewhandbook.org/grind75

Blind 75: https://leetcode.com/discuss/general-discussion/460599/blind-75-leetcode-questions

If you enjoyed this, I think you’ll find this article entertaining 🍿 and insightful.

Why I Became a Security Engineer 🔐 as An Aspiring Software Engineer 💻

Sometimes to reach a destination, you have to take a few detours.

chigozie-asikaburu.medium.com