Only 30-Minute Guide To Crack All Programming Language, Algorithm & Data Structure Interview

By Kimberly Cook |Email | Mar 12, 2019 | 33621 Views

Despite scoring decent grades in both my CS101 Algorithm class and Data Structures class in university, I shudder at the thought of going through a Programming Language Interview that focuses on algorithms.

Hence I spent the last three months figuring out how to improve my coding interview skills and eventually received offers from the big tech companies. In this post, I'll be sharing the insights and tips I gained along the way. Experienced candidates can also expect system design questions, but that is out of the scope of this post.

Many of the algorithmic concepts tested in programming language coding interviews are not what I usually use at work, where I am a front-end web engineer. Naturally, I have forgotten quite a bit about these algorithms and data structures, which I learned most during my freshmen and sophomore years of college.
It's stressful to have to produce (working) code in an interview, while someone scrutinizes every keystroke that you make. What's worse is that as an interviewee, you're encouraged to communicate your thought process out loud to the interviewer.

I used to think that being able to think, code, and communicate simultaneously was an impossible feat, until I realized that most people are just not good at programming language coding interviews when they first start out. Interviewing is a skill that you can get better at by studying, preparing, and practicing for it.

My recent job search has led me on a journey to improve my programming language coding interview skills. Front-end engineers like to rant about how the current hiring process is broken because technical interviews can include skills not related to front-end development. For example, writing a maze solving algorithm and merging two sorted lists of numbers. As a front-end engineer myself, I can empathize with them.

The front end is a specialized domain where engineers have to care about many issues related to browser compatibilities, the Document Object Model, JavaScript performance, CSS layouts, and so on. It is uncommon for front-end engineers to implement some of the complex algorithms tested in interviews.

At companies like Facebook and Google, the people are software engineers first, domain experts second.
Unfortunately, the rules are set by the companies, not by the candidates. There is a high emphasis on general computer science concepts like algorithms, design patterns, data structures; core skills that a good software engineer should possess. If you want the job, you have to play by the rules set by the game masters - improve your coding interview skills!

This post is structured into the following two sections. Feel free to skip ahead to the section that interests you.

  • The breakdown of programming language coding interviews, and how to prepare for them.
  • Helpful tips and hints for each algorithm topic (arrays, trees, dynamic programming, etc.), along with recommended LeetCode practice questions to review core concepts and to improve on those topics.

The content for this post can be found in my Tech Interview Handbook repo on GitHub. Updates will be made there. Pull requests for suggestions and corrections are welcome!

If you are interested in Front End content, check out the answers to the famous Front End Job Interview Questions.

Picking a programming language
Before anything else, you need to pick a programming language for your algorithmic coding interview. Most companies will allow you to code in the language of your choice. The only exception I know is Google. They allow their candidates to pick from only Java, C++, Python, Go or JavaScript. For the most part, I recommend using a language that you are extremely familiar with, rather than one that is new to you but that the company uses widely.

There are some languages that are more suitable than others for programming language coding interviews. Then there are some that you absolutely want to avoid. From my experience as an interviewer, most candidates pick Python or Java. Other languages commonly selected include JavaScript, Ruby, and C++. I would absolutely avoid lower-level languages like C or Go, simply because they lack standard library functions and data structures.

Personally, Python is my de facto choice for coding algorithms during interviews. It is succinct and has a huge library of functions and data structures. One of the top reasons I recommend Python is that it uses consistent APIs that operate on different data structures, such as len(), for ... in ... and slicing notation on sequences (strings, lists, and tuples). Getting the last element in a sequence is arr[-1] , and reversing it is simply arr[::-1]. You can achieve a lot with minimal syntax in Python.

Java is a decent choice too. But because you will have to constantly declare types in your code, it means entering extra keystrokes. This will slow down the speed at which you code and type. This issue will be more apparent when you have to write on a whiteboard during on-site interviews.

The reasons for choosing or not choosing C++ are similar to Java. Ultimately, Python, Java, and C++ are decent choices. If you have been using Java for a while, and do not have time to become familiar with another language, I recommend sticking to Java instead of picking up Python from scratch. This helps you to avoid having to use one language for work and another one for interviews. Most of the time, the bottleneck is in the thinking and not the writing.

One exception to the convention of allowing the candidate to "pick any programming language they want" is when the interview is for a domain-specific position, such as front-end, iOS, or Android engineer roles. You need to be familiar with coding algorithms in JavaScript, Objective-C, Swift, and Java, respectively.

If you need to use a data structure that the language does not support, such as a queue or heap in JavaScript, ask the interviewer if you can assume that you have a data structure that implements certain methods with specified time complexities. If the implementation of that data structure is not crucial to solving the problem, the interviewer will usually allow it. In reality, being aware of existing data structures and selecting the appropriate ones to tackle the problem at hand is more important than knowing the intricate implementation details.

Review your CS101
If you have been out of college for some time, it is highly advisable to review the CS fundamentals. I prefer to review it as I practice. I scan through my notes from college and revise the various algorithms as I work on the algorithm problems from LeetCode and Cracking the programming language Coding Interview.

This interviews repository by Kevin Naughton Jr. served as a quick refresher for me.

The Medium publication basecs by Vaidehi Joshi is also a great and light-hearted resource to recap on the various data structures and algorithms.

If you are interested in how data structures are implemented, check out Lago, a Data Structures and Algorithms library for JavaScript. It is pretty much still WIP but I intend to make it into a library that is able to be used in production and also a reference resource for learning Data Structures and Algorithms.

Mastery through practice
Next, gain familiarity and mastery of the algorithms and data structures in your chosen programming language.

Practice and solve algorithm questions in your chosen language. While Cracking the programming language Coding Interview is a good resource, I prefer solving problems by typing code, letting it run, and getting instant feedback. There are various Online Judges, such as LeetCode, HackerRank, and CodeForces for you to practice questions online and to get used to the language. From my experience, LeetCode questions are most similar to the questions asked in interviews. HackerRank and CodeForces questions are more similar to questions in competitive programming. If you practice enough LeetCode questions, there is a good chance that you will either see or complete one of your actual interview questions (or some variant of it).
Learn and understand the time and space complexities of the common operations in your chosen language. For Python, this page will come in handy. Also, learn about the underlying sorting algorithm being used in the language's sort() function and its time and space complexities (in Python it's Timsort, which is a hybrid). After completing a question on LeetCode, I usually add the time and space complexities of the written code as comments above the function body. I use the comments to remind myself to communicate the analysis of the algorithm after I have completed the implementation.

Read up on the recommended coding style for your language and stick to it. If you choose Python, refer to the PEP 8 Style Guide. If you choose Java, refer to Google's Java Style Guide.

Learn about and be familiar with the common pitfalls and caveats of the language. If you point them out during the interview and avoid falling into them, you will earn bonus points and impress the interviewer, regardless of whether the interviewer is familiar with the language or not.

Gain broad exposure to questions from various topics. In the second half of the article, I mention algorithm topics and useful questions for each topic to practice. Do around 100 to 200 LeetCode questions, and you should be good.

Practice, practice, and more practice!

Phases of a programming language coding interview
Congratulations, you are ready to put your skills to practice! In a programming language coding interview, you will be given a technical question by the interviewer. You will write the code in a real-time, collaborative editor (phone screen) or on a whiteboard (on-site), and have 30 to 45 minutes to solve the problem. This is where the real fun begins!

Your interviewer will be looking to see that you meet the requirements of the role. It is up to you to show them that you have the skills. Initially, it may feel weird to talk while you code, as most programmers, do not make a habit of explaining out loud their thoughts while they are typing code.

However, it is hard for the interviewer to know what you are thinking by just looking at your code. If you communicate your approach to the interviewer even before you start to code, you can validate your approach with them. This way, the two of you can agree on an acceptable approach.

Preparing for a remote interview
For phone screens and remote interviews, have a paper and pen or pencil to jot down any notes or diagrams. If you are given a question about trees and graphs, it usually helps if you draw examples of the data structure.

Use earphones. Make sure you are in a quiet environment. You do not want to be holding a phone in one hand and typing with the other. Try to avoid using speakers. If the feedback is bad, communication is made harder. Having to repeat yourself will just result in the loss of valuable time.

What to do when you get the question
Many candidates start coding as soon as they hear the question. That is usually a big mistake. First, take a moment and repeat the question back to the interviewer to make sure that you understand the question. If you misunderstand the question, then the interviewer can clarify.

Always seek clarification about the question upon hearing it, even if you think it is clear. You might discover that you have missed something. It also lets the interviewer know that you are attentive to details.

Consider asking the following questions.
  • How big is the size of the input?
  • How big is the range of values?
  • What kind of values are there? Are there negative numbers? Floating points? Will there be empty inputs?
  • Are there duplicates within the input?
  • What are some extreme cases of input?
  • How is the input stored? If you are given a dictionary of words, is it a list of strings or a trie?

After you have sufficiently clarified the scope and intention of the problem, explain your high-level approach to the interviewer, even if it is a naive solution. If you are stuck, consider various approaches and explain out loud why it may or may not work. Sometimes your interviewer might drop hints and lead you toward the right path.

Start with a brute-force approach. Communicate it to the interviewer. Explain the time and space complexities and clarify why it is bad. It is unlikely that the brute-force approach will be the one that you will be coding. At this point, the interviewer will usually pop the dreaded, "Can we do better?" question. This means they are looking for a more optimal approach.

This is usually the hardest part of the interview. In general, look for repeated work and try to optimize them by potentially caching the calculated result somewhere. Reference it later, rather than computing it all over again. I provide some tips on tackling topic-specific questions in detail below.

Only start coding after you and your interviewer have agreed on an approach and you have been given the green light.

Starting to code
Use a good style to write your code. Reading code written by others is usually not an enjoyable task. Reading a horribly formatted code written by others is even worse. Your goal is to make your interviewer understand your code so that they can quickly evaluate if your code does what it is supposed to and if it solves a given problem. Use clear variable names and avoid names that are single letters, unless they are for iteration. However, if you are coding on a whiteboard, avoid using verbose variable names. This reduces the amount of writing you will have to do.

Always explain to the interviewer what you are writing or typing. This is not about reading, verbatim, to the interviewer the code you are producing. Talk about the section of the code you are currently implementing at a higher level. Explain why it is written as such, and what it is trying to achieve.

When you copy and paste in code, consider whether it is necessary. Sometimes it is, sometimes it is not. If you find yourself copying and pasting a large chunk of code spanning multiple lines, it is probably an indicator that you can restructure the code by extracting those lines into a function. If it is just a single line you copied, usually it is fine. However, remember to change the respective variables in your copied line of code where relevant. Copying and pasting errors are a common source of bugs, even in day-to-day coding!

After coding
After you have finished coding, do not immediately announce to the interviewer that you are done. In most cases, your code is usually not perfect. It may contain bugs or syntax errors. What you need to do is review your code.

First, look through your code from start to finish. Look at it as if it were written by someone else, and you are seeing it for the first time and trying to spot bugs in it. That's exactly what your interviewer will be doing. Review and fix any issues you may find.

Next, come up with small test cases and step through the code (not your algorithm) with those sample input. Interviewers like it when you read their minds. What they usually do after you have finished coding is get you to write tests. It is a huge plus if you write tests for your code even before they prompt you to do so. You should be emulating a debugger when stepping through your code. Jot down or tell them the values of certain variables as you walk the interviewer through the lines of code.

If there are large duplicated chunks of code in your solution, restructure the code to show the interviewer that you value quality coding. Also, look out for places where you can do short-circuit evaluation.

Lastly, give the time and space complexities of your code, and explain why it is such. You can annotate chunks of your code with their various time and space complexities to demonstrate your understanding of the code. You can even provide the APIs of your chosen programming language. Explain any trade-offs in your current approach versus alternative approaches, possibly in terms of time and space.
If your interviewer is happy with the solution, the interview usually ends here. It is also common that the interviewer asks you extension questions, such as how you would handle the problem if the whole input is too large to fit into memory, or if the input arrives as a stream. This is a common follow-up question at Google, where they care a lot about scale. An answer is usually a divide-and-conquer approach - perform distributed processing of the data and only read certain chunks of the input from disk into memory, write the output back to disk and combine them later.

Practice with mock interviews
The steps mentioned above can be rehearsed over and over again until you have fully internalized them and they become second nature to you. A good way to practice is by partnering with a friend and taking turns to interview each other.

A great resource for preparing for programming language coding interviews is This platform provides free and anonymous practice interviews with Google and Facebook engineers, which can lead to real jobs and internships. By virtue of being anonymous during the interview, the inclusive interview process is unbiased and low risk. At the end of the interview, both the interviewer and interviewee can provide feedback to each other for the purpose of helping one another improve.

Doing well in mock interviews will unlock the jobs page for candidates, and allow them to book interviews (also anonymously) with top companies like Uber, Lyft, Quora, Asana, and more. For those who are new to programming language coding interviews, a demo interview can be viewed on this site. Note that this site requires users to sign in.

I have used, both as an interviewer and an interviewee. The experience was great. Aline Lerner, the CEO, and co-founder of, and her team are passionate about revolutionizing the process for programming language coding interviews and helping candidates improve their interview skills. She has also published a number of programming language coding interview-related articles on the blog. I recommend signing up as early as possible with, even though it's in beta, to increase the likelihood of receiving an invite.

Another platform that allows you to practice programming language coding interviews is Pramp. Where matches potential job seekers with seasoned coding interviewers, Pramp takes a different approach. Pramp pairs you up with another peer who is also a job seeker. The two of you take turns assuming the roles of interviewer and interviewee. Pramp also prepares questions, and provides solutions and prompts to guide the interviewee.

Personally, I am not that fond of Pramp's approach. Because when I do interviews, I ask questions that are familiar to me. Also, many users do not have the experience of being an interviewer, and that can result in a horrible interview experience. In one instance, my matched peer took on the role of the interviewer but he did not have the correct understanding of the question and attempted to lead me down the wrong path to solving the question. However, this is more of a problem of the candidate than the platform though.

Go forth and conquer
After doing a fair amount of questions on LeetCode and having enough practice doing mock interviews, go forth and put your new-found interviewing skills to the test. Apply to your favorite companies or, better still, get referrals from your friends working for those companies. Referrals tend to get noticed earlier and have a faster response rate than applying without a referral. Good luck!

Practical tips for coding questions
This section dives deep into practical tips for specific topics of algorithms and data structures, which appear frequently in coding questions. Many algorithm questions involve techniques that can be applied to questions of a similar nature.

The more techniques you have in your arsenal, the greater your chances of passing the interview. For each topic, there is also a list of recommended questions, which is valuable for mastering the core concepts. Some of the questions are only available with a paid subscription to LeetCode, which in my opinion is absolutely worth the money if it lands you a job.

General tips
Always validate input first. Check for inputs that are invalid, empty, negative, or different. Never assume you are given the valid parameters. Alternatively, clarify with the interviewer whether you can assume valid input (usually yes), which can save you time from writing code that does input validation.

Are there any time and space complexities requirements or constraints?

Check for off-by-one errors.

In languages where there is no automatic type coercion, check that concatenation of values are of the same type: int,str, and list.

After you finish your code, use a few example inputs to test your solution.

Is the algorithm supposed to run multiple times, perhaps on a web server? If yes, the input can likely be pre-processed to improve the efficiency in each API call.

Use a mix of functional and imperative programming paradigms:
  • Write pure functions as often as possible.
  • Use pure functions because they are easier to reason with and can help reduce bugs in your implementation.
  • Avoid mutating the parameters passed into your function, especially if they are passed by reference unless you are sure of what you are doing.
  • Achieve a balance between accuracy and efficiency. Use the right amount of functional and imperative code where appropriate. Functional programming is usually expensive in terms of space complexity because of non-mutation and the repeated allocation of new objects. On the other hand, imperative code is faster because you operate on existing objects.
  • Avoid relying on mutating global variables. Global variables introduce state.
  • Make sure that you do not accidentally mutate global variables, especially if you have to rely on them.

Generally, to improve the speed of a program, we can choose to either use an appropriate data structure or algorithm or to use more memory. It's a classic space and time trade-off.

Data structures are your weapons. Choosing the right weapon for the right battle is the key to victory. Know the strengths of each data structure and the time complexity for its various operations.

Data structures can be augmented to achieve efficient time complexity across different operations. For example, a HashMap can be used together with a doubly-linked list to achieve O(1) time complexity for both the get and put operation in an LRU cache.

HashMaps are probably the most commonly used data structure for algorithm questions. If you are stuck on a question, your last resort can be to enumerate through the possible data structures (thankfully there aren't that many) and consider whether each of them can be applied to the problem. This has worked for me at times.

If you are cutting corners in your code, state that out loud to your interviewer, and explain to them what you would do outside of an interview setting (no time constraints). For example, explain that you would write a regex to parse a string rather than using split, which does not cover all cases.

This article was originally published here

Source: HOB