Just about every question in this article is along the lines of “what do I need to know/do to ace a tech interview and get a job?” With people on our team having experience conducting many technical interviews, StackCache can provide some simplified advice. This isn’t a full list, but it should cover the most important aspects.

Expectations-setting: If this is your first job search or you haven’t had an interview in a long time, you should expect to put in some time and effort in advance of the interview. Industry professionals, as well as some college students, tend to overlook this stage. You’re preparing for a test, so don’t take it lightly; it’ll be difficult. Now is the time to fill in the details on anything you don’t know. 

We’ll concentrate on what a fresh graduate should do to prepare for brevity’s sake, as this is more consistent across businesses (and it’s a quicker process).

Data Structure

Before preparing your own responses, read each of these Wikipedia entries numerous times (to make it more realistic, write the code and get familiarize with this stuff – that is the crucial part)

• Array
  • Directed/Undirected/Weighted Graphs
  • Hash Table (It’s critical to comprehend all of the different collision mitigation mechanisms, as well as what amortized constant-time means.)
  • Heap
  • Linked Hash Map (this is a very specific question, but it comes up frequently in interviews)
  • Linked List

• Stack/Queue
• Trees (Tree, Binary Tree, Binary Search Tree, Red-Black Tree, etc. Learn as many as possible.)
• Trie (pronounced “tree”)

For each of these, you should know the Big-O for insert, delete, lookup, and so on. Understand how the mechanics operate. Although these aren’t good interview questions, you should be able to code each one of them. Then, think of real-life scenarios in which you’d use each of these, and explain why it’s the best option. In technical interviews, data structures come up in two ways. The first is in coding questions, where you must use the appropriate one at the appropriate time. The second is based on a non-code comparison question: “why would you choose X over Y in situation Z?”

Algorithms

Make sure you’re coding these for real when you’re practicing. It’s not going to be enough to read code written by someone else. Start typing in the integrated development environment of your choice (IDE). This is important because even if you have a knowledge gap, your nasty brain will tell you that everything is OK (this tends to occur without even realizing it). The only way to find these issues is to write code. Learn all of the Big-O and how it’s derived for this.

You don’t have to go insane with this, but go through a couple of the suggestions below:

• Sorting algorithms (both comparison and non-comparison sorting)
• Traversals through trees (simply learn the following: inorder, preorder, postorder, level order)
• Traversals Dijkstra’s, A*, BFS, DFS (understand the difference between DFS and BFS and when you should use one over the other and why – hint: when you don’t have to search the entire area, it usually makes a difference. Check that you can code in a coherent form and with your own stack/queue.)
• All searches in the prefix tree

You’re about 60% done now, which is fantastic. Now it’s time to put what you’ve learned into practice. Look for a good source of interview questions (random websites, glassdoor.com, cracking the coding interview, etc.) Answers to those questions should be coded. Forcing yourself to pretend you’re in an interview situation is highly recommended. The majority of these questions should take between 10 and 15 minutes to complete; however, some may take longer, such as 20 to 25 minutes. Set a timer for yourself. Before writing a single line of code, gather your thoughts and plan out the full solution, then begin coding. The coding portion should be straightforward and uninteresting. Carry on the same manner in the actual interview. Make sure you confirm with the interviewer that your method is sound before writing a single line of code. This is something you should practice a lot.

Filling the Gaps

This is the point at which you can be completely honest with yourself. That lengthy list of things you don’t know that you keep telling yourself is fine since what you don’t know isn’t essential…well, it is. Even if it isn’t, your interviewer may believe it is, and having a job is preferable to being correct. Here’s a quick list of things I’ve heard people say aren’t important (but must know them).

• Writing code – Sometimes, people with over 15 years of experience lose touch with code because they’ve gotten rusty. These “architects” are unable to find work. Managers and other support positions are in the same boat. You won’t be writing production code; that’s OK; nonetheless, you should be able to write some code.
• Bits and Bytes – You should be familiar with how bit-shifting works in the language you’ll be interviewing with. You should be aware of the terms “large endian” and “small endian.” Do a few practice questions, even if they are simple. “Write a technique to determine if an integer’s bit-wise representation is a palindrome,” for example.
• How the internet works. This is more applicable to businesses these days, but it applies to almost everything. You should understand how sockets function and what TCP/IP is. You should have a basic understanding of HTTP. Understand your networking levels and who is in charge of what. You don’t need to be familiar with all of the protocols’ intricacies, but you should be aware that they exist. This may be intimidating, but it should only take a few hours.
• Databases. If the position you’re applying for requires databases, learn some basic SQL and data modeling.
• Learn the basics of testing. Make some code and put it to the test. What exactly is TDD?
• Consider trying Linux for a while if you’ve only ever used Windows.
• Anything else that comes to mind. Imagine yourself in an interview “Man, I hope they don’t question me about X,” which is a useful mental exercise. Find out what X is and do some research on it.

The good news is that most of the items on this list are much easier to learn than you might expect. Typically, these are scars from undergrad or gaps from a non-traditional path to CS that sound difficult. They’re all simpler than you would assume.

Behavioral

It’s not all about the technology in tech interviews (they mostly are these days, but not completely). You must project yourself as someone that people want to work with. Smile, keep the fire burning, be enthusiastic about the company, be knowledgeable about what they do, and offer ideas for what they could do. There’s a good chance you’ll be asked behavioral interview questions. You can get ready for them. We recommend imagining three scenarios in which you were working on a tech project and things went well, as well as three scenarios in which things went badly. Then try presenting the stories, making sure to include some background information such as the place, the project, who was working with you, and what your job was. Next, tell the story; for positive stories, talk about the impact of your work; did you win, save the firm money, or what? For negative ones, talk about what you’ve learned and how you’d approach the situation differently and better in the future.

Conclusion

Get a good night’s rest and perform your best. Expect to fail at some of these interviews; that’s fine; use it as a learning opportunity and keep in mind that there are good and poor interviewers. A great candidate can be thrown in front of a bunch of jerks and not get hired. That’s not to suggest you shouldn’t learn from the experience, but interviewing is a game. Don’t try to break the rules or believe they’re ridiculous. It is what it is, and it is what stands in your way of getting the job you want. By practicing, you can learn how to play the game and win. You are not a fraud if you are just getting started; we all know how inexperienced new grads are.

Don’t sell after the time. There are many times someone has been a little too honest with all of the extroverts out there. Interviewers try to be your best buddy during interviews. For several reasons, their goal is to get you as comfortable as possible. First and foremost (and maybe the most compelling reason to choose to be polite), your performance is best represented when you’re at ease. Try not to get overly comfortable and disclose something that might hurt your chances of getting hired.

It’s in our nature to want to make bonds with people, and one way we do so is by performing a sophisticated game of secret-sharing with them. It’s tempting to offer some more truths early on, usually light ones, but this is a horrible idea in an interview situation. Some examples of what NOT to do.

“Believe it or not, between you and me, I just had to labor 5-6 hours a day to finish it.”

“I know I shouldn’t mention this in an interview, but my coworker was the true issue.” 

Don’t go overboard with your sharing. If you expect something to make you appear awful, it will almost certainly do so.

There are a few exceptions to this rule: There are a few things that people consider to be bad but are fine:

• Admitting you don’t know what you’re talking about (better than making stuff up)
• Inquiring into the situation to ensure that you comprehend it.
• Admitting that you’re a little apprehensive and need a few moments to gather your thoughts (OK, but don’t make it too emotional.)

After you’ve been hired, you can become friends with the interviewers you like. They could turn into potential mentors.