# Big O is for the interview only

The interviewers favorite card.

I didn't know what Big O meant. At least not before I had worked many jobs and on many projects as a developer. I remember reading about it in school but I didn't see any use for it in a real world. If you are like me and never encountered it yet worked in the field, we are the lucky ones. It's hard to get passed any interviewer without having to encounter a question about it.

## What is Big O?

Big O is a way of representing the efficiency of an algorithm. It tells you how long a specific algorithm will take to complete a task in the worst case scenario. On paper it is noted `O(n)`.

If an algorithm is denoted `O(1)`, it means no matter what the input is, it will take the same amount of time to complete. `O(n)` means the time will increase linearly as the input increases in size. `O(n2)` the time will increase by the square of the input, quickly slowing down as the number grows. And so on and so forth.

### Where is it used?

A popular place you will hear the term Big O, is when talking about sorting algorithms. Binary search for example is noted as `O(log n)`. A quicksort is noted `O(n log n)`. Bubble sort is O(n2).

You can find more cases on the Wikipedia entry for Big O Notation.

## Do I need to know it?

Sorting algorithms and Big Notations are the interviewer's favorite go to questions. When you have a candidate applying for a programming job, and you don't know the first thing to ask, these questions can quickly differentiate those who know their craft versus the pretenders.

Only that is not true. The big O notation is a computer science term, and it is something you mostly study in school and never use in the real world. At least not when you are building your app, little game, or website.

It is important to familiarize yourself with it but hardly ever a requirement. Yet, it is the main reason candidates are rejected. I worked as a developer and saw great developers with many years of experience simply fail to do their quicksort test because, well, no one implements a quicksort on a daily basis.

The last time I struggled to do a sorting algorithm was when I was in college. But I write search algorithms very often, yet I don't have to worry about whether it uses Red Black tree or quicksort. The underlying framework has already solved this problem for me.

## But Google interviewers say I need to know it.

There is a misconception that everyone at Google are consistently writing sorting algorithms because, well Google is the search giant. Let me ask you a question: "Who was the president of Iran in 1952?" Chances are you don't know, but with a simple google search, you will find that there wasn't a president but a prime minister in that year and his name was Mohammed Masaddiq. The point is, you can find this answer easily without having to memorize it. The same goes with those sorting algorithm.

A friend of mine said it best:

[But] it's the current culture that we're sitting in. Just Google "Good interview questions" and you'll get back list after list of these questions, and that's the biggest problem. People aren't giving interviews based on their companies needs, they're doing it based off their laziness and the ease of just looking up what someone else thought to ask. This is the equivalent of hiring a doctor and asking them to name every bone in the body. It's unnatural and only manages to make people fresh out of college with no real work experience look like pros and it makes actual programmers who know how to problem solve look like they have no idea what they're doing.

As a programmer, it is important to understand these notations and their benefit, but it is hardly a requirement to memorize them. The only time it is relevant is if you are an interviewer who doesn't know what he is doing, or you are a candidate who is preparing for an interview. And of course, if you are doing a job where you use it consistently.

Just because it is google, amazon, twitter, or facebook doesn't mean that you need to master these notations to work on the UI design team. Since no one wants to make their interview relevant for the job, do yourself a favor and study your Big Os for your next interview.