Codementor Events

Use Python in Interviews, Please

Published Apr 06, 2018Last updated Oct 03, 2018

At this point in my career, I've interviewed hundreds of candidates and seen a wide variety in the way people do things. One of the biggest hurdles that people face is that in an interview you're trying to churn out a good quality, readable solution to a coding problem as quickly as possible. You're not trying to make a robust solution that will stand up to many refactors over time, or able to support dependency injection, or many of the other concerns that production code has to deal with.

Many people I interview try to use C++ or Java for the interview questions, often because they don't really know any other language. The problem is that languages suffer from something that is very important during an interview: verbosity. Verbosity is not always a bad thing in programming, it can often make code clearer and easier to understand and it makes it easier for static analysis tools to make sure that the code is correct and doesn't have any weird quirks to it. However when you're writing on a whiteboard and your main available resource is time (and whiteboard space), you'll want to use a language that is much more optimal for that use case.

Python fits the bill perfectly, and I'll demonstrate with a simple example. Many interview questions involve building some sort of data structure, so many people write out some sort of class/struct - in this example we'll use a node in a binary search tree. I've seen many people waste loads of time doing something like this:

public class Node<T> {
  T data;
  String key;
  
  public Node(T data, String key) {
    this.data = data;
    this.key = key;
  }
  
  // Sometimes they even write out getters and setters.
}

This is a load of code that doesn't do very much. It takes them a few minutes to write all this stuff out, which is a few minutes that they are not solving the actual problem that I asked them to solve. Compare it to Python:

Node = namedtuple("Node", "data key")

That's a lot shorter! Now this is a bit of a contrived example since in an interview you can just say, "pretend there is a class called Node that has these two fields" without actually writing out the class, but now and then you might get a stickler who wants to see everything.

I'll give another example in case you get someone like me who doesn't care too much that you know how to write a basic class. Often in some algorithm you have a container of things, and you need to filter that container and do some transformation on the data. In Java:

Container<Type> newThings = new Container<>();
for (Type thing : things) {
  if (someCriteria(thing)) {
    newThings.add(someTransformation(thing));
  }
}

vs. Python:

newThings = [someTransformation(thing) for thing in things if someCriteria(thing)]

This is a lot shorter, and flows a lot better when you're writing and talking at the same time. It also works when you want to use a dict comprehension or a 2D array.

There are many other small expressiveness tweaks like these which in total add up to quite a bit of time savings when you're writing out your algorithm on the whiteboard.

What about other dynamic languages? I've seen lots of people use Javascript, especially those that come out of coding bootcamps. It's not too bad a language to use, but when you're doing algorithmic problems I find that the built-in's in Python (especially sets) are just slightly better and are easier to work with than in JS.

Another language that is fantastic for interviews is Ruby, however I've noticed that Ruby has been in decline over the last few years where Python is actively used in interesting domains like machine-learning and data science. As much as I love Ruby, if you're going to invest the time to learn a language then I'd say Python would open more doors to you. There are a few exceptions of course, Ruby is still pretty strong in devops with things like Chef or in infosec with things like Metasploit, however I am not sure if these will stand the test of time quite as well. Devops is already getting pruned down by the shifts to container-based systems like Docker and Kubernetes which is largely in Go and config files.

Lastly there are plenty of very expressive languages like Lisp or Haskell that language geeks like to bring up in a discussion like this. I have yet to see anybody use anything esoteric like this in an interview, but your risk there is that your interviewer doesn't know that language and so is not 100% sure if your code is actually correct. Since Python is super readable and is OOP/imperative, pretty much all interviewers will be able to follow what you're doing even if they don't have a strong handle on Python.

As a side note, the downside of Python is that it is very easy to write quadratic time algorithms to linear problems with it. As it turns out, many other languages also suffer from this problem (including even Java). I'll post more details on that in a later post, and how you might be able to get around it by learning a different way of algorithmic thinking.

Discover and read more posts from Rob Britton
get started
post comments3Replies
Mukul
6 years ago

Wonderful article rob, I have a question for you, when you say ‘the downside with python is that you can write quadratic time algorithms to linear problems with it’, what does it mean ? Can you elaborate with an example. Thanks for article anyways.

Rob Britton
6 years ago

It’s mostly an observation I’ve seen while doing interviews. A number of the interview questions I’ve asked usually involve using integers as indexes in lists, which is common in the C++/Java world. Python programmers on the other hand tend to try to do everything using list comprehensions and higher-level abstractions that can often hide the time complexity of the underlying operation.

One example that bothers me a little bit is when people use list.append() when they know the final size of the list ahead of time, and so internally the list will end up resizing itself periodically. Although this is amortized constant time, the resizes are linear and so you’ll have these spiky outliers in performance that can be terrible when dealing with large arrays.

Mukul
6 years ago

Got it. Thanks for the wonderful explanation.