Technical Interview Cheat Sheet

Few people look forward to a job interview. Even though it’s obviously nice to find a new career and end unemployment, the process of being judged and scrutinized based on your skills and personality is enough to make anyone uncomfortable. Worse still is when you know that you have the skills and experience you need for a job, but you’re not sure whether you can adequately communicate this to your interviewer.

It’s a sad fact that sometimes people are better at a job interview than they are at the actual job. This is especially true during technical interviews, where people who have memorized certain strategies will often excel. With this being said, interviewing is a skill, and you can learn it in the same way that you’ve learned how to code. Use this Technical Interview Cheat Sheet to understand the many ways that you can give yourself an edge during the interview process—and then demonstrate your skills in your dream job.

Interview Do’s and Don’ts

To begin with, there are some pointers that have commonality between technical and non-technical interviews. You should look your best, prepare adequately, and be congenial towards your interviewer. People are going to judge you primarily on your talent, but they also want to work with people that they like and who are easy to work with. Even if you’re not sure you can memorize all of the technical information further down this list, you can still maximize your personal appeal to give yourself a better chance of getting hired.

Environment Control

DO: Neaten your surroundings

Let’s assume that interviews are going to be remote-only for the foreseeable future. Therefore, the background of your video call is something that you need to control. Make sure that your background shows a neat, well-organized space—or use a filter that blurs is all out if that’s not possible.

DO: Test your setup

Make a test call to a friend of yours using the interviewer’s videoconferencing application choice. This will ensure that your webcam, mic, and internet connection are in working order.

DON’T: Assume that you’ll be familiar with the coding environment

Interviewers are going beyond simple text editors during technical interviews. If your interviewer uses a solution like CoderPad, you’ll find that it contains useful features like highlighting and autocomplete—if you don’t familiarize yourself beforehand, you may miss out on a vital tool.

DON’T: Dress too informally

Although it’s true that we’ve all spent 2020 in sweatpants, interviewers will think better of you if you wear something other than pajamas. That being said, it’s likely that you’ll be sitting for a long time, so wear clothes that are comfortable, but not too casual.

DO: Expect behavioral questions

Even though this is a technical interview, you may expect to hear some questions like, “tell me about yourself” or “where do you see yourself in five years.” Make sure that you have a few prepared answers to questions like this, so you don’t get caught off guard. In addition, you should make sure that you have a prepared list of intelligent questions about the organization.

DON’T: Forget to Repeat the Question

There’s a lot of pressure to start demonstrating your skills as fast as possible during a technical interview, but listening is also a skill. If you start coding right away without being sure that you’ve fully understood the interview question, then there’s a chance that you’ll start trying to answer the question you thought you heard, and not the question your interviewer had in mind. Always read the interview question and then repeat the question back to the interviewer to ensure you’re on the same page.

DO: Clarify Understanding of inputs, outputs, and side effects

In the course of this technical interview cheat sheet, we’d like to stress two important things:

1. You’ll never hurt your chances by asking for more information

2. Coding in an interview is only an approximation of coding in real life

This means that if you’re not sure what your input is supposed to be, you won’t lose points by asking—and you’ll lose a lot more points if you don’t ask and get it wrong. In the same vein, if your code generates a side effect that you’re not sure about—ask. Side effects in the technical interview IDE may not be the same as side effects in the production environment.

DO: Go through an example to ensure understanding

Finally, technical interview questions are often left deliberately vague. To ensure your thorough understanding of the question, create a quick example that encapsulates the question. The interviewer should be able to tell you whether you have the right idea.

DO: Consider algorithms in niche cases

Algorithms are tough, but in the niche cases where they’re relevant, can be important to keep in mind. We’ve included a long list of useful resources to remember when dealing with algorithm interviews later on. Keep in mind, however, that most interviewers won’t expect you to memorize algorithms off-the-bat. Don’t be afraid to ask questions during the interview and vocalize your questions throughout the interview process.

DON’T: Forget to test your code logic

It’s worth saying again—check your work. Audibly review the code you’ve created. Not only does this help prevent mistakes, but it also helps demonstrate your thought process to your interviewer.

Code behavior extends far beyond algorithms, which this advice is relevant for. Further, for people who have studied algorithms ahead-of-time, it’s likely that another part of their logic is broken, not algorithms.

DON’T: Neglect to discuss the time and space complexity of your approach

Computers don’t have infinite resources, and good code economizes on time and space. Even if you’re created a relatively time and space-intensive program for the interview, you can still score points by discussing how you’re optimizing your program given additional resources. Likewise, some portions of development may not have the same requirements of complexity as others. Feel free to highlight when you’re simplifying code for maintainability.

DO: Point out when you’re cutting corners

Sometimes—especially if you’re running out of time—you’ll have to finish your program in ways that you’d consider to be less than idea, such as by writing pseudocode. This isn’t necessarily a dealbreaker, as long as you tell your interviewer what you’re doing (and again, discuss how you’d improve your process in an actual workplace environment).

DO: Manage whiteboard space

Coderpad contains a helpful Drawing Mode, allowing candidates to sketch out a system or describe technical architecture. When using this, remember to try and make everything legible—don’t cram elements too close together or make things too small to read, as your interviewer will probably look at your diagram after the interview is concluded.

Coding Review

Now that we’ve gotten the do’s and don’t of our technical interview cheat sheet out of the way, let’s start reviewing code. A lot of people memorize coding methods for technical interviews, but that’s not necessary with CoderPad. That’s because CoderPad lets you run the code you write during technical interviews, so if you don’t memorize something fully, you can go back, check your work, and fix it. This simulates an actual workplace environment a lot more closely than the alternative.

Even though you don’t need to fully memorize data structures and algorithms, it still helps to review the fundamentals. Here’s what you need to know.

Data Structures

Data structures can often be a major part of optimizing and organizing your codebase. While deep-dives on each of these concepts are outside the scope of this article, we’ve provided a cheat-sheet for your next technical interview below. Find any that sound interesting? We encourage further reading to master them!

Heap

This kind of binary tree places the smallest value at the top. Helpful when creating priority queues.

Array

A data structure that places items sequentially. Offers fast lookups and appends, but its fixed size requires careful planning.

Dynamic Array

Similar to an ordinary array, except that a dynamic array expands to fit additional elements as needed.

Linked List

A flexibly-sized list in which each item contains a pointer for the next element. Although the list is easy to expand, lookups can take a lot of time.

Queue

A data structure in which each item is stored in the order it’s received.

Stack

A data structure in which the last item to be stored is the first item to be addressed.

Graph

Not an X/Y chart. Graphs are formed by nodes, and the relationships between the nodes are denoted via lines (edges). Good for creating functional diagrams, but difficult to scale.

Trie

Also known as a prefix tree, the trie is designed to store strings in a compact manner—mostly in cases where you’re storing words with a large number of shared prefixes.

Priority Queue

Distinct from a regular queue. Each item in the queue is given a priority, and higher-priority items are addressed first regardless of when they entered the queue. See also: Heap.

Bloom Filter

A probabilistic data structure that allows administrators to understand whether a set contains a given item—sometimes.

LRU Cache

Here, LRU stands for “Least Recently Used.” It’s a data structure that shows which item has gone unused for longest.

Hash Table

Also known as a hash table, this data structure stores hashed items for quick lookup.

Binary Tree (AKA Binary Search Tree or BST)

A tree in which the nodes to the left are always smaller than the nodes to the right. Balanced trees offer the best performance.

Red-Black Tree

A tree in which the black values remain constant, and the red values may change.

B-Tree

A self-balancing BST variant in which nodes are allowed to have more than two children.

Union Find

Also known as disjoint set structure. Stores non-overlapping sets.

Search

Candidates asked to implement search will most likely encounter one of two search methods in a technical interview—breadth first search and depth first search.

Breadth first search (BFS) searches across the tiers of a tree—first the top node, then the layer of nodes beneath it, then the nodes beneath that, and so on. The primary advantage of BFS is that it can be used to find the shortest path between any two nodes.

Meanwhile, depth first search (DFS) searches down pathways. Starting at the root of a data tree, it then searches all the way down one branch before moving on to the next. DFS is easy to implement and requires less memory most of the time.

Efficient Sorting

Sorting algorithms are another huge component of creating efficient code. Again, you don’t need to memorize the algorithms below, but you should be aware of their time and space complexity.

Selection Sort

The cursor scrolls left to right through a dataset. Every time the right number is smaller than the left number, the right number gets moved to the all the way to the left until the whole data set is sorted. Simple but inefficient.

Insertion Sort

The cursor compares itself to numbers on the left. If smaller, it changes places with the leftmost number and iterates until the data set is sorted.

Merge Sort

Divides the data set in half, then continues dividing until each item is an individual subset. Once this action is complete, the algorithm recombines the data set, sorting as it does.

Quicksort

An algorithm that recursively divides a data set into two halves, placing smaller elements to the left and larger elements to the right, until the whole data set is sorted.

Bubble Sort

Scrolls through a data set comparing every pair of numbers, placing the larger number on the right and the smaller number on the left, until the entire data set is sorted.

Heapsort

A “max heap” is created from a data set by comparing parent nodes with child nodes and then swapping them until the largest number is at the root. By deleting the root, swapping the first and last node, and starting the max heap again, you’ll eventually sort all numbers from least to greatest.

Types of Algorithms

Lastly, you should know the basic types of algorithms.

A recursive algorithm triggers itself repeatedly until it reaches what’s known as a base case, which is when the algorithm stops.

An iterative algorithm also loops repeatedly, but only while a certain condition is true. These can be somewhat more efficient than recursive algorithms, but recursive algorithms can solve more complex problems.

A greedy algorithm is given a set of specific criteria and then selects data that matches those criteria. This algorithm can improve the time efficiency of an application, but only in cases where there’s a small amount of matching data in a large data set.

Asymptotic Notation

Refer back to the “Review time and space constraints” section of the Do’s and Don’ts above. Asymptotic notation is used to describe how long your algorithm will run when given different inputs. There are three symbols you’ll need to remember:

·   Big O: Under the worst-case scenario, this is how long the algorithm will run

·   Big Omega (Ω): This is the best-case scenario for runtime

·   Big Theta (Θ): The runtime value is the same in the best-case and worst-case scenarios

In a multi-part algorithm, the runtime is always calculated using its slowest part. Please note: you can always communicate your applications’ performance constraints if you’re unfamiliar with this terminology in a pinch.

Conclusion

That’s it! Using the tools, algorithms, and strategies in this technical interview cheat sheet, you should be able to master the application process. Before you begin, make sure to stretch your legs. Check out CoderPad, try out a few coding challenges, and neaten up your room—it’s time for a technical interview!