Everything you need to get ready for technical interviews, behavioral questions and negotiating salary offers
Every company has a different way of interviewing its candidates, and you need to be prepared for all those possible scenarios.
The smaller the company, the less sophisticated the interviewing structure. Smaller companies and startups will probably only do 1 – 2 live coding interviews (interactive interviews with a tool like Codepen or an actual IDE, or whiteboard interviews) or they might give you a small project to complete on your own.
Large companies such as Google or Facebook start with a phone screen with a recruiter, then do 1 – 2 phone technical interviews where you do some coding, and then you move to the on-site interviews.
Task #1: Go ahead and read the Interview Formats section of the Tech Interview Handbook created by Yangshun Tay, a Facebook employee, to understand how different companies structure their different interviews.
Regardless of the structure and the number of interviews, you need to be prepared for the following types of questions:
- Technical questions
- Design questions
- Behavioral questions
Let’s review each one of these question types and let’s set some goals that you have to accomplish in order to be successful.
Technical questions can be about data structures and algorithms, or they can be about the specific technologies, languages, and frameworks used in the company you are interviewing with.
At this point, you should have been using platforms such as Hackerrank, Learneroo, and Leetcode to learn data structures and algorithms. While you are applying to jobs, you should continue your daily practice with Leetcode (more on this later).
Keep in mind that you can be asked to answer these type of questions using an actual IDE or interactive tool that lets you run the code, or in a Google Doc or whiteboard where you need to be able to write code without much guidance. You should practice all of those different scenarios.
I will assume that you are already proficient with your stack and how to build projects with it.
Moving forward, we will also start using Gayle Laakmann McDowell’s “Cracking the Coding Interview” book. If you don’t have it, I highly recommend that you buy it or try to find it in your local library.
Task #2: Read the section VII of the Introduction chapter of the “Cracking the Coding Interview” book: Technical Questions.
Task #3: As a refresher of data structures and algorithms, complete ONLY the first coding challenge in each section (i.e. Array, Dynamic Programming, Geometry, Graph, Hash, etc.) of this page using your preferred language.
You will be using a new platform called Leetcode. That page of the Tech Interview Handbook also includes an overview of each data structure or algorithm in case you need a refresher. Read it before trying the coding challenge.
Task #4: Find resources to test yourself against the most common conceptual questions asked about the different technologies that you know. If you don’t know the answer to a question, go ahead and use Google to learn about it before trying to see the solution.
Here are some examples of “Conceptual questions” for the different languages that we teach at Microverse. If you are using the same stack, feel free to use those links. Otherwise, use it to understand which kind of resources you need to find on Google. Keep in mind that conceptual questions are different than coding challenges in the sense that they are more theoretical and you are not supposed to write code to answer them (most of the times).
Algorithms and Data Structures (Max 45 minutes)
Ruby & Rails (Max. 45 minutes)
HTML & CSS (Max. 45 minutes)
React (Max. 45 minutes)
To make this task a little bit more endurable, set a limit of 45 minutes for each set of questions. Feel free to schedule some time with a friend to work on these questions together. You can take turns answering and explaining the answers to each other.
Remember to do mock interviews to get yourself ready for the real job interviews (more on this later) and to keep practicing these types of questions even while applying to jobs.
System Design Questions
In these types of questions, interviewers present a given product (e.g. a social network, a search engine, a URL shortener) and you are asked to design the system and architecture for that given product.
Some of the elements in the design are probably somehow familiar to you already – DNS server, cache, load balancer, databases, etc. However, even experienced developers sometimes struggle with these types of questions.
You are not supposed to design a super scalable and perfect system. Your interviewer knows that you are an entry-level developer who has probably never designed a scalable and production-level system before.
These types of questions are an opportunity for you to show how you approach big problems. You should ask a lot of questions to validate your assumptions about the system you are supposed to design, and you can approach the design in a very iterative way with the help of the interviewer.
Here is a list of tasks that you should complete to get yourself ready for system design questions. It will take you a while to complete all these tasks, and chances are that you won’t be even be asked these type of questions since you will be applying to entry-level positions.
However, you will learn a lot about the real world of software development here. Take your time and enjoy it, but don’t get into a rabbit hole. Feel free to skim through some sections if necessary. You can go back to many of these concepts whenever you need it.
Task #5: Read chapter 9 of the “Cracking the Coding Interview” book: System Design and Scalability.
Please read the “Example Problem”, but don’t try to complete the “Interview Questions” yet.
Task #6: Donne Martin, engineering manager at Facebook, has created another awesome open source resource to help people with their interviews. Go ahead and read the section called “How to approach a system design interview question”.
In Step 3 and Step 4 from the previous link, you are supposed to come up with the components that you would use to design your system and then think about how you are going to scale it. Let’s review the main components and scalability mechanisms of any system design.
Task #7: Read about the four different ways of scaling a system:
Task #8: Read about the different components of every software system (you don’t need to understand everything in detail, but you should be aware of the different components and concepts):
Task #9: Pick 2 – 3 companies that you like from this list and read about their architectures.
Task #10: Look at the answers to the following two design questions:
Those are high-level answers and they are good enough for an entry-level position. If you are curious about what’s expected from more senior developers, take a look at this more advanced answer to the URL Shortener design question.
Task #11: Finally, pick any 2 questions from this list of design questions and, using pen and paper, or any text editor, try to answer to them as if you were in a real interview. I recommend that you try doing this with a friend or colleague so you can help each other.
Note: I keep recommending that you try things with a friend or colleague because some of these steps can be hard and frustrating, and learning alone can be tough. In fact, this is the key to how we teach at Microverse. We don’t have teachers or live classes. Instead, our students learn in small distributed teams doing remote pair programming. Like the Swedish proverb says:
Shared joy is a double joy; shared sorrow is half sorrow.
Companies don’t just want to hire people who are really good from a technical perspective. They also want people they will enjoy working with and people who are a good cultural fit for the company.
For that reason, at some point in the interview process, the interviewer will ask some behavioral questions such as: “why do you want to work here?”, or “tell me about a project where you faced a challenge with your team and you were able to overcome it successfully”.
This section is meant to help you get ready to easily answer any of those questions.
Task #12: Read section V of the Introduction of the “Cracking the Coding Interview” book: Behavioral Questions.
Task #13: Using a Google Docs document, complete the “Interview Preparation Grid” described in the book. It’s ideal if you can use mostly software projects, but if there is any behavioral situation (e.g. Leadership) where you cannot think of a software project, use a non-software project to fill in the grid.
Task #14: Following the S.A.R. (Situation, Action, Result) methodology and the general tips from the book, write down and add the answers to questions from the book (i.e. “weaknesses” and “tell me about yourself”), and to each one of the question in the “General” section of this list to the Google Doc from the previous task.
Using the “Share” button in Google Docs, allow anyone with the link to comment and then share the document with your mentor or any other colleague and ask for feedback. It’s always good to have a second pair of eyes looking at this. Remember to make your answers sound natural.
Even though technical, design and behavioral questions will be the most important part of your interviews, it’s important to keep in mind other questions and tips that will be helpful during the interview process.
Questions to ask
Asking good questions during the interview not only makes you look smart, but it’s also something you should do to get to know the company and the people there before accepting any offer. An interview is a two-way process. Don’t forget that!
Task #15: Take a look at the questions from this list and use them as a reference for your future interviews. There is no need to memorize them now.
Here are some other psychological tips that can help you connect with your interviewer. Keep these tips in mind when you interview.
When the much expected moment comes, and you get a job offer, remember that you should always negotiate. However, negotiating well is an art.
Task #16: Read this list with 10 rules of negotiation and come back to them whenever you need to negotiate an offer.
If you want, follow the two links at the top of that article to get a more detailed description of each one of the rules.
Doing mock interviews before you jump into real ones is a great idea. Not only will you have the chance to get confident at answering some of the most common questions in an environment that feels like the real one, but you will also learn how to handle your nerves so you can look calmer and more confident while interviewing.
Here is a simple spreadsheet we use to generate mock interviews at Microverse:
Mock Interview #, Type, Time limit, Question, Comments 1, Behavioral# 1, 3 minutes, What project are you currently…docs.google.com
Our students use this spreadsheet to interview each other while applying to jobs. Most of those questions are specific to the stack that we teach, but you can find a friend or colleague and try to generate a similar list of questions for your friend and ask them to do the same for you.
You will need to be the “expert” in the room when interviewing your friend, so spend a maximum of 2 hours preparing the answers to those questions yourself. You can use Google to find for the optimal solution/answer to each question (especially to coding questions) so that you can guide your coding partner until he finds that same solution too.
Note: We also recommend that you try practicing some of the answers, especially the behavioral ones, in front of a mirror or with a rubber duck before meeting with your friend.
With this detailed guide in hand you should be able to prepare for any job interview that you will ever face as a software developer. Follow all these tips and you will feel confident when the time comes.
If you want to get some of my tips and recommendations and be notified when I publish my next article talking about how to craft a perfect resume, portfolio, and professional profiles on LinkedIn, Github and AngelList, follow me on Medium.
Founder of Microverse, a school for remote software developers that is free until you get a job. www.microverse.org
Stories worth reading about programming and technology from our open source community.