One Tip to Crack the Coding Interview — Use Abstractions!

Based on five years of my interview experience

Important note: This article was originally written on Medium - you can read the full version here.

Disclaimer: This post is not affiliated by Google or Microsoft. It’s purely my opinion.

I have been taking interviews for Google and Microsoft for around 5 years and in my mind, this is likely one of the most common mistakes, I see several promising candidates make.

I am talking about a typical programming interview here — one where you are given one or more problem statements and are expected to arrive at an optimal solution (algorithm) and write code for it within 45 to 60 minutes.

These are generally called “Data Structures and Algorithm interviews” and most of the major Software Companies use this kind of interview to hire software engineers from entry-level to senior hires.

After taking several interviews, of candidates from 0 to 12+ years of experience — there was this one common problem leading to a bad impression and potential rejection.

The candidate attempts to solve every part of the question rather than focussing on what is important.

And in many cases, the candidate ends up not solving the given problem. Sometimes the candidate gets tangled up in an unimportant subpart of the problem.

Interview for junior role vs. senior role

If the candidate is interviewing for a junior role, I don’t mind this and I usually steer the candidate back to the problem at hand before it’s too late. But when hiring for intermediate or senior roles there are two important signals I like to analyze:

1. Can the candidate break down the problem well and address them independently.

And in case the candidate jump to the potentially long path.

2. Can the candidate step back and think rationally

I’ll give an example for reference

How I look while taking an interview as per my wife!

Let’s take the example of LeetCode problem 165 — Compare version numbers

Given two version numbers for example “1.4.5” and “1.3.6” return the greater one

On its own, it looks like a fairly simple question. Before the candidate is about to start coding — I explicitly mention:

Please feel free to use as much abstraction as needed, if there is something particular I am interested in I will dig into it.

One of the most common approaches is to split the string with “.” as a delimiter and convert the values to integer and then compare left to right, assuming the given values are valid version numbers.

For this specific question, I have seen several C/C++ candidates spend too much time on the first subproblem — splitting and converting string to integer array.
In C++, many candidates write some version of the following code.

std::vector<int> VersionStringToIntValues(const std::string& version_string) {
  std::vector<int> version_values;
  int buffer = 0;
  for (int i = 0; i < version_string.length; ++i) {
    if (version_string[i] == '.') {
      version_values.push_back(buffer);
      buffer = 0;
    } else {
      buffer *= 10;
      buffer += (version_string[i] - '0');
    }
  }
  
  // Many candidates just miss this step.
  if (buffer > 0) {
    version_values.push_back(buffer);
  }
  
  return version_values;
}

std::string GetGreater(const std::string& version1, const std::string& version2) {
  // Some validation logic
  
  std::vector<int> version_values1 = VersionStringToIntValues(version1);
  std::vector<int> version_values2 = VersionStringToIntValues(version2);
  
  // Many candidates just implement the function `VersionStringToIntValues()`
  // inline, twice for each version strings.
  
  // Further logic
}

One way to address the first sub problem of the interview question in C++.

While this may not be the best way to write code for this sub-problem, I have seen several candidates trying to address this sub problem like this — hence giving similar example.

I have seen some candidates finally getting through with this subproblem one way or another while a couple of them getting stuck writing code for this.

But, this isn’t solving the question I asked

And you have got a total of 45–60 minutes

The question was to return the larger version number.

I see many candidates not being able to finish the code for the question in the given timeframe. I haven’t asked this specific question in a really long time but time and again, I have seen candidates trying to solve the given problem without breaking it down and focusing on the key components.

If the candidate is interviewing for intermediate to senior roles — this gives a bad impression, to me as an interviewer. During the course of the interview, I need to see enough signals from the candidate around the algorithm and data structure skills, coding skills, design skills, and efficacy to solve the problem and this can be a red flag for the last two verticals.

TL;DR;

When you start to write code during an Algorithm or Data Structure interview — try to write the top-level code and make assumptions on the interfaces and helper methods.

Start solving the key part of the problem — you can even ask the interviewer if you are expected to solve a certain sub-problem or you can assume it is implemented. If the interviewer needs more signals, they’d ask you to write code for the sub-components.

It’s always better to finish the code for the required question than not!

Closing points

Thanks for reading, this can be subjective area — happy to learn about other opinions on this topic! Sections below are optional read.

If you are interested in reading about the ideal way I recommend this types of questions be solved - you can read the full article here.

Photo Credits

• Photo by 傅甬 华 on Unsplash.
• Photo by Paul Hanaoka on Unsplash.

For example, while working on the Camera App I got opportunity to work on a “Night Mode” in the Camera App, which requires us to capture a burst of images and merge them in robust fashion to produce a well exposed and low noise image. This is computationally very expensive and we needed our algorithms to run on resource-constrained hardware within a certain latency budget.

This was a very exciting problem statement for me and required me to re-learn modern C++, image processing concepts etc.

But it was so much fun, that the effort spent on learning didn’t feel like a bother. I’d recommend finding such directions and start learning what ever it takes.

TL;DR; Don’t bother to find one programming language that would be your bet for 2022.

Want to Connect With the Author?

Subscribe to Medium using my membership link (I'll earn a small commission).

• My blog: blog.minhazav.dev for related articles
• Github: mebjas@
• Twitter: minhazav@
• LinkedIn: minhazav