Study Guide to Senior Software Engineering Interviews
TLDR: I recently moved to a Senior Data Engineer role at a much bigger company. Here is the outline I followed to prepare for senior-level engineering interviews in 3 weeks. You need to prepare for coding, system design, and behavioral questions.
Why study?
Like it or not, this is the industry we are in, we need to prepare for our interviews. You have a limited window to provide signals to the company that you are capable of doing the job.
This means even if you are experienced and fully capable, you need to prepare so you are polished, ready, and can maximize the positive signals you send in the short interview window you are given.
What should I do to prepare?
This guide assumes you are past the HR screen in the interview process. For information on resumes and applying check r/cscareerquestions or the beginning of Cracking the Coding Interview.
Almost all interviews for non-entry-level engineering roles are roughly the same. After the HR screen, job fit, and potential take-home code screen you have the big “on-site” day. This day is where you do 3-5 different interviews with various folks at the company. These rounds focus on a mix of coding, system design, and your experience.
This guide will focus on the 3 pillars you need to prepare for your “on-site” interview.
In this round, you will be asked to whiteboard or live-code solutions to various problems, perform a system design exercise or two, and describe your experience and work history. The skills needed to succeed in this round can be broken down as follows:
Coding
System Design
Behavioral Questions
How to Prepare?
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. You should spend time understanding most basic data structures in computer science (hash maps, arrays, linked lists, graphs, etc.) and the common algorithm patterns we see in interviews.
I’m not going to walk through any of the above here, but I will provide the best resources below that helped me prepare. In my recent job search, the two-pointer algorithm and recursion happened to come up a lot.
Data Structures / Algorithms
Algorithm Patterns
Cheat Sheets
Approaching live coding problems
Take some time to review the best way to solve these coding problems and understand what the interviewer is looking for. Remember, you are also being tested on how it is to work with you, how you think, and how you 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?’.
There is almost always a trade-off between time and space in your solution.
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, go for accuracy. Don’t prematurely start to optimize
Pay attention to the hints in the problem’s prompt. Ie. is the array sorted?
Practice
Equipped with the common interview patterns and methods for approaching these problems, go and 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 the thinking out loud part. 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 cultivated questions I used to practice:
System Design
Similar to the coding round, you should step back and understand how to approach these problems in general and then study a few more specific solutions.
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 an abstract problem, your breadth of knowledge, and how well you communicate your ideas.
Here is the general outline of how I approach these problems. This process is a combination of the various resources linked below.
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.
Remember this is a conversation. Let the interviewer talk too.
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.
If you’re interviewing for a Data Engineer or Data Warehouse Engineer role you might be asked to design some schemas. If you’re a Backened Engineer, maybe you dive deeper into designing the API.
Resources
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. If you can spend time preparing some stories and answers to common questions you’ll own this section.
Your stories should be STAR. The cleaner and more concisely you can tell these stories in an interview, the better you are going to present yourself.
STAR
STAR stands for Situation, Task, Action, Result. Basically for your stories, set the context (situation), then explain at a high level what your objective was (task). Describe the specific steps you took to solve the problem (action) and finally point out the business value (result).
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.
What’s next?
Some parting advice:
Remember, a lot of the process is up to chance. 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 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.
Good luck!