I like to open up The 6th edition of Cracking the Coding Interview from time to time. Mainly to keep an up-to-date cheat sheet of things to narrow down during job search. All of the recruiters use some variation of things that is in this book.
So, I opened it up today and got some quotes from that book in no particular order.
There’s another reason why data structure and algorithm knowledge comes up: because it’s hard to ask problem-solving questions that don’t involve them. It turns out that the vast majority of problem-solving questions involve some of these basics. When enough candidates know these basics, easy to get into a pattern of asking questions with them.
This quote talks about justifications of asking data structure and algorithm questions. It finishes off with some practical reasoning for this interview structure. You, as an applicant have to remember this. These scenarios are easy to create, modify, and repeat. Additionally, it could save immediate and future employee costs.
Not only might you be judged harshly for not really understanding big 0, but you will also struggle to judge when your algorithm is getting faster or slower.
This quote was in the context of Big O. I’ve personally experienced this in a group setting. It wasn’t during an interview per se but I’ve definitely been caught off guard by this. Some people say maybe you shouldn’t meet your heroes. Maybe that is true. I’ll let you be your own judge of that. In this case, the harsh judgement came from a well known and important person. If I was a fan of this person or their work, I would have found their approach not professional and would not have wanted to work with them. Approach was used on a group of 18-21 year olds.
I think that this person used this approach as a strategy. A coping mechanism of some sort or a scare tactic. Or perhaps it allowed them to maintain order in their position. It made people less likely to approach them. Made the situation a bit more interesting since employees had to approach them.
Big O time is the language and metric we use to describe the efficiency of algorithms. Not understanding it thoroughly can really hurt you in developing an algorithm. Not only might you be judged harshly for not really understanding big 0, but you will also struggle to judge when your algorithm is getting faster or slower.
One of the things that I find interesting about Big O in our industry is the lack of consensus among various parts of this industry. If you know about Big O, then there is very little ambiguity. Most people who are familiar give similar responses.
There seems to be some kind of this weird distinction of: us (industry) vs. them (academia). This has been so when I was in academia and it is continuing to exist as such. I think this issue comes from the word approximation. You need some context to what you mean about an approximation. How good do you want it? Should it be a formal approximation? A rough estimate?
As you continue reading, a few lines down from the quote above we find
If you’ve never covered big O in an academic setting, you can probably skip this subsection.
Academics use big 0, big 0 (theta), and big O (omega) to describe runtimes.
In industry (and therefore in interviews), people seem to have merged 0 and O together. Industry’s meaning of big O is closer to what academics mean by 0, in that it would be seen as incorrect to describe printing an array as O(N2). Industry would just say this is O(N).
For this book, we will use big O in the way that industry tends to use it: By always trying to offer the tightest description of the runtime.
I agree to some of these statements but I also think that it depends.
Industry may use O(N) as an approximation but they will definitely check if it is not O(N2) by accident. They will definitely do so if money is involved. In other words, while the industry may use O(N) as an approximation, they definitely know how to get to the O(N2) boundary.
So, dear reader, spend the time and learn. This way you can adjust your answer based on your audience and you can understand. Plus, it is actually helpful when you are making things.
Unless otherwise mentioned in the post, those projects are side projects which I work on on weekends and evenings, and are not affiliated with my work or employer.
Tags: software engineering, hiring | Report a bug via Twitter