Let’s say you need a min priority queue and you don’t know what the methods are called. You can’t look it up, so you have to make an educated guess. This shows the interviewer the way you think about code organization and how you reason through things you don’t already know.
It is also useful to review basic computing concepts like networking or operating systems, particularly if the job is related to those fields. Interviewers often like to know that you have an understanding of the underlying system. You likely won’t be expected to go into great depth, but you should know how network packets work or basic methods of task scheduling.
Computer coding interviews are very similar to whiteboard interviews in terms of the questions you will be asked and the approach you should take, with the main difference being that you’re coding on a computer in an IDE rather than on a whiteboard. This also means you can run your code and see if it works!
In a computer coding interview, you’re not worrying about exact syntax. After all, you have all the tools you love to help you do that properly. You’re not worrying about the correctness of your code on a low level because you can just run it and see if it works (obviously your algorithm may not work, but it’s easy to see if your for loop goes out of bounds).
To start with, it’s critical to have a good foundation. Make sure you know how to implement all the most common data structures and algorithms from scratch (hashmaps, linked lists, priority queues, etc). If you’re unsure whether you need to know something, the index of Cracking the Coding Interview [Affiliate Link] is a great place to look. If it’s there, it’s worth a review.
Lastly, it’s worthwhile playing around a little with the most common IDEs for your language. You can certainly ask your recruiter ahead of time what development environment to expect, but especially if you don’t get a clear answer, it’s worth at least having a baseline familiarity with the options. For Java, for example, this means having used both Eclipse and IntelliJ.
These interview questions are a great way for you interviewer to test how you think in a big-picture way. Can you take this design doc and build it into an actual system? Could you design an analytics tracking system to monitor all of the orders going through the site? How about building a flow so users can upload videos?
As an engineer, there is much more to the job than just being able to write code. Sure you could be a code monkey, but if you’ve read this far, you’re definitely looking for something more. Software engineers need to be able to take these sorts of large problems from the product team, translate them into a specific set of requirements, and then apply technology to meet those requirements.
System design interview questions are also a great proxy for testing real world engineering experience. As you gain more experience as a developer, it becomes more intuitive how to break down problems. There are common patterns that repeat over and over. These questions help your interviewer to deeply evaluate your level of experience.
System design problems are as much an art as a science. They are also unlikely to make or break your interview, since there’s a less clearly defined “right” or “wrong” answer to the question. Rather, doing well or poorly will sway you one way or the other depending on your other interviews.
Most organizations also have relatively poorly documented code. In the interest of moving quickly, documentation is often pushed off until “later”. It’s also hard to document code that is in flux, so documentation rarely gets added at the time of writing, meaning that much of the original intention can get lost.
Ability to use tools well not only shows that you care about efficiency, but is also indicative of a deeper level of past experience. It’s unlikely that you would have much experience using the Eclipse debugger if you’ve only coded for your Intro CS class. However many seasoned engineers will have plenty of experience using that or one of the many other available debuggers.
The key is to focus on the auxiliary skills. This means improving your ability to quickly read and interpret code and learning how to debug code effectively, both with and without debugger tools. You may end up in a situation where the only tools available to you are print statements, so make sure you know how to debug without using your favorite tools.
To bone up on your debugging skills, learn the common commands for your prefered debugger. This should be the generally preferred debugger for your language. Don’t use some niche tool and expect access to that in your interview. Understand how to get stack traces, view variable values, set breakpoints, and other key techniques.
In reality, behavioral interviews are what most people would consider normal interviews. They are certainly the most “traditional” interview questions you will be asked and are often asked by a recruiter or someone from HR. If you have a recruiter reach out to you asking to chat about a potential job, expect these sorts of questions.
Like System Design and Conceptual interviews, these interviews are also testing how well you communicate. Good communication is critical to an effective organization and interviewers want to see that you are able to communicate your thoughts clearly. Do you know what is most important? Are you able to focus the conversation so that everyone learns exactly what they need to know? This is a great skill to have within an organization.
As shown on page 6 of this presentation Gayle recommends creating a grid with your three best/biggest/most recent projects on your resume along the top and common behavioral questions along the side. Creating this table is super valuable, because as you fill it out, you can find relevant stories for each project you may be asked about.
To take this one step further, you can even practice your exact responses to different questions. You may or may not be asked those exact questions, but it is valuable to practice answering out loud. It can be hard to frame your thoughts clearly, and a little practice goes a long way.
While I know it’s not a lot of fun, preparing for these different types of questions is critical to doing well in your interview. You are a performer, and you’d better know your damn lines. Maybe you’re improvising, but even improv troupes practice regularly to get the skills under their belts.
Whiteboard Coding Interviews: 6 Steps to Solve Any Problem
1. Ask questions that are the right level of difficulty.
You want to thread the needle between “so easy it doesn’t reveal anything” and “so difficult they would have had to study it in advance.” Aim for questions that would be a 3 to a 3.5 on a 5-point difficulty scale.
History of the Whiteboard Interview: How Did We Get Here?
Back in the 1980s and earlier, portable computers were large and expensive. Bringing a computer along to a candidate interview wasn’t practical. Instead, testing software developers using pen and paper was the norm. After all, it wasn’t that far removed from the times when computer programming required punch cards. Interviewers would ask interviewees to implement a linked list on college-ruled paper.
Later, in the 1990s, whiteboards were all the rage—from the classroom to the boardroom. Engineers loved them too. They made collaboration easier because everyone could see what you were working on. They were a clear choice over paper.
It stands to reason that the popularity of whiteboards would carry over to the interview process. It was easier for both the interviewer and candidate to look at what was being worked on and discuss it in real time.
Using a whiteboard in in-person interviews still happens today. Now more than ever, people are interviewing remotely and using virtual alternatives to physical whiteboards.
Unfortunately, job openings for programming positions often attract people who can’t program at all! It may sound harsh, but some of the candidates that coding jobs attract simply aren’t qualified.
When you’re hiring for a developer position, you need a competency check to establish baseline confidence. No single interview technique can separate good candidates from truly great ones. But using the right interview techniques can certainly help you ensure minimum qualifications.
Whiteboard interviews force both the interviewer and interviewee to focus on problems at a higher level. There are no development environments, syntax highlighting, or syntax errors to get in the way.
A whiteboard interview shouldn’t be a test to see if a developer has memorized their particular language’s syntax. It should do the opposite – removing those factors so you can both focus on solving the problem.
A whiteboard interview should be a conversation. It shouldn’t be a scenario where a developer tries to solve a problem under the interviewer’s cold, Simon Cowell-esque gaze.
Instead, it would be best to use the whiteboard interview to learn a bit about how the candidate does these things:
People solve real software development problems iteratively over weeks and months. Of course, you can’t do that during an interview process. But you can use these questions as a small-scale proxy.
Some developers detest being asked questions based on data structure and algorithms. Still, it isn’t easy to find a better solution for judging so many qualities of a candidate in a fixed amount of time.
Let’s explore some of the criticisms leveled against whiteboard interviews.
6. Know what your acronyms mean
Programming languages, terms, and their abbreviations may feel like a complex alphabet soup sometimes, but you need to know what they mean.
For example, REST stands for Representational State Transfer. Youre most likely used to simply saying “REST” in conversations with other developers. You dont want to be caught off-guard when your interviewer asks you to expound on the implications of “state transfer,” so understanding the acronyms and their definitions is a big help.
