Study Guide to Senior Software Engineering Interviews
Prepare for coding, system design, and behavioral questions.
Note: I wrote this back in 2021 when changing roles. This process hasn’t changed much.
This guide shows how to prepare for the 3 types of “on-site” interviews:
Coding
System Design
Behavioral Questions
This guide assumes you are past the HR screen in the interview process. For information on resumes and applying see:
Coding
To prepare for the coding round you should:
Learn the common patterns
Understand the best way to approach interview coding problems
Practice
Learn the common patterns
Rather than blindly grinding Leetcode or Hackerrank, it’s best to take a step back and work through some basics first. Learn:
Basic data structures (hash maps, arrays, linked lists, graphs, etc.)
Common algorithms (two pointer, recursion, search, etc.)
Data Structures / Algorithms
Algorithm Patterns
Cheat Sheets
Approaching live coding problems
During the coding interview, you are also being tested on how you:
Work with others (this round is somewhat collaborative)
Think
Communicate
Here are some tips I found to still do well here, even if you struggle with the actual coding problem:
Have a collaborative attitude. Think of the interviewer as a colleague who is there to help you solve the problem
Before coding, ask questions. Be sure to understand the problem. Ask about any edge cases, ask clarifying questions, etc.
Think out loud. The interviewer is trying to get a signal from how you work as a developer, if you just sit in silence they have nothing to score you on. Think out loud and ask the interviewer, ‘how does that sound?’.
Look for the trade-off between time and space in your solution. Most problems have one.
If you want faster time, you need more space (hash map?)
If you want to use less space, you need more time (iterate twice?)
Solve the problem first, then optimize. Don’t prematurely start to optimize.
Listen for hints. Pay attention to the hints in the problem’s prompt. Ie. is the array sorted? Is the interviewer asking leading questions?
Practice
When practicing, go for quality over quantity. Spend time struggling with the problem on your own before looking up the answer. Then when you do submit a solution, look at different approaches to the problem and take the time to understand a few of them.
Always understand the space and runtime complexity for your solutions (Big-O). You will likely be asked to state the runtime and space complexity of your solution.
As you work through practice problems, practice thinking out loud. Get in the habit of verbalizing your approach before starting to code.
When reviewing your solution, take the time to look up anything you don’t understand.
Here are some curated questions to practice:
System Design
Approaching System Design Problems
This round is extremely open ended. The conversation can go wherever you or the interviewer would like it to. This is a conversation to gauge your:
Ability to Scope
Technical Breadth
Communication
Steps to Solving a System Design Problem
Requirements clarifications/ use cases/ scope.
Functional requirements – What is the goal of the system? Who are users?
Non-Functional requirements – CAP Theorem, Consistency vs Availability?
Back-of-the-envelope estimation.
Scale – how many concurrent users?
Throughput – Queries per second?
Memory – cache size?
High-level design
Start basic, then extend
Client -> Load Balancer -> Server -> Cache -> Database
Details: Interfaces & Data Model
Microservices – single responsibility
Data – SQL vs NoSQL – do we need consistency (SQL) or scalability with eventual consistency (NoSQL)?
Scale the Design
Load Balancing
Microservices
Caches/ CDN
Asynchronism / Task Queues
Database Scaling – indexes, replication, sharding, denormalization
Telemetry/ Analytics
Some additional tips:
ASK QUESTIONS – clarify the scope of the problem, ask what they are looking for, ask if you can go deeper (especially if it’s a topic you know well)
Use specifics – instead of saying “database”, get more specific. Say a columnar database like Redshift so we can easily aggregate data for analytics.
Let the interviewer talk too. Remember this is a conversation.
Practice
Start with some of the more common system design problems, like a URL Shortener. Then go for some specific examples that are more relevant to the company you are interviewing for. For example, watch some solutions on designing video streaming services if you’re interviewing for Netflix.
The System Design Primer (start here)
System Design Interview Questions – Concepts You Should Know
My System Design Template (LeetCode forums)
YouTube/ Google any specific problem
Behavioral Questions
This round is all about being prepared. Own this section just be preparing a few stories.
STAR
Stories should follow the STAR pattern:
Situation - set the context.
Task - what was the high level objective?
Action - specific steps you took to solve the problem.
Result - call out the business value.
Stories to Prepare
Write all this down BEFORE you interview. It’s good to practice and have these ready so you don’t waste energy thinking about them in the actual interview.
Technical Projects – have one to three technical projects you’ve completed that you are proud of and can go into detail.
The more relevant they are to the role you’re interviewing for, the better.
Follow the STAR method as outlined above.
What are your strengths?
What are your weaknesses?
Share an example of a conflict you had at work and how you handled it.
Going Forward
Remember, a lot of the interview process is completely outside of your control. Keep your head up and stay positive.
You’re trying to see if it’s a good fit for you as well, always have questions to ask the interviewer and take notes.
Be honest. Honest about what you are looking for and if you don’t know something.
Be personable. Listen when someone else is speaking, pay attention, be respectful. You’re being evaluated as a potential colleague as well as for your skills.
It takes time, but this too shall pass.
Good luck!