
Data structures and algorithms interview questions and their solutions - adamnemecek
https://techiedelight.quora.com/500-Data-structures-and-algorithms-interview-questions-and-their-solutions
======
wheaties
When I had less than 5yrs experience I used to ask these types of questions,
thinking they showed the ability of a developer to reason out critical
software issues. Then I met a guy who had practically memorized everything I
could ask. He spit out answers so fast it was appallingly clear he was
regurgitating answers from a book. This proved nothing about him and
everything about me.

Today, I recognize that good software development owes nothing to data
structure knowledge or obscure algorithms. This knowledge can't hurt but very
few jobs or languages require you build a skip list from scratch. Instead,
writing good software requires the ability to maintain a system, to debug
problems, and to give constructive code review. That's it.

~~~
davidcbc
>Today, I recognize that good software development owes nothing to data
structure knowledge or obscure algorithms. This knowledge can't hurt but very
few jobs or languages require you build a skip list from scratch. Instead,
writing good software requires the ability to maintain a system, to debug
problems, and to give constructive code review. That's it.

While I don't think that the current state of interviewing is perfect, this
statement is pretty out there. Good software development owes NOTHING to data
structure knowledge? Choosing the right data structure is critical for
software that performs well (or performs at all once you get to a certain
scale), and demonstrating knowledge of various data structures shows at least
that a candidate knows a bit about which tools they have available to them on
the job.

Of course not many people are implementing skip lists from scratch in their
everyday job, that's why in the list of 500 questions none of them are
"Implement a skip list". Data structure questions rarely ask you to implement
some data structure from scratch, they ask you to look at a problem and figure
out which data structure best lends itself to the solution.

I won't argue that asking questions about obscure algorithms isn't a problem,
but good interviewers aren't asking questions that need obscure algorithms,
they are asking questions that need algorithms like DFS, basic variations of
sorting, and basic DP problems.

~~~
hluska
You're focusing too much on a particular phrase and not enough on the overall
meaning. Read this again:

> Instead, writing good software requires the ability to maintain a system, to
> debug problems, and to give constructive code review. That's it.

Code review is the best time to talk about data structures and algorithms as
they are a time to apply theoretical knowledge to real world problems. Good,
constructive code reviews are about education and maintaining a quality code
base.

Interview questions about data structures and algorithms rewards memorization
and classroom knowledge. I've worked with way too many mediocre developers who
are great at whiteboarding interview questions but who couldn't build a
maintainable system if their lives depended on it. Consequently, I don't give
a damn about a candidate's performance on these types of questions. Instead,
I'd rather learn about some projects they've built, problems they've
experienced and their experience with code reviews.

------
darioush
\- Programmers are increasingly more "API plumbers", not "pathfinders". The
change being you have to more often create an "easy to maintain" glue layer
between lots of existing code (most of which your company wrote a bunch of
years ago, or is external to your code in a framework or library) instead of
solving a problem from scratch using CS basics. Interview questions haven't
shifted to "this library has such and such function calls, how would you
expect it to report an error?" or "describe two distinct UI frameworks you
have used and explain their differences". They're still very much in the era
of OK we have two rectangles, how do we find the overlapping pixels.

\- Software is increasingly built in teams. We don't ask about "how you
handled a difficult person on your code review" or "how would you break this
change in to two logical commits" or even "what's a good name for this
function", all of which are more important than knowing the big-o for some
obscure interval tree.

\- CS 101 algorithms have very little to do with how they are implemented.
e.g, in a recent discussion with a co-worker I discovered libstdc++
hashtable's iteration orders depend not only on hash code but also on
insertion order. Looking at how libstdc++ and MSVC implemented hashtables was
both very difficult and exhausting to follow and had many many more details
than the typical CS 101 approach of just hash the key and direct lookup the
bucket! Turns out writing code that is really fast needs more than knowing the
big-o.

\- Big O is such a garbage simplification of all the "fundamental" knowledge.
Why not just ask some fundamental graph or combinatoric counting questions?
Why nothing about what is computable and what is not, or which languages are
regular? What about information theory? How come no information recall or
database questions? or even these days with all the ML, why not some basic
linear algebra?

------
NTDF9
Here's my gripe with this interview process. It encourages engineers to spend
months and years into learning and remembering optimal solutions to textbook
problems.

A REAL engineer would spend the same time doing something productive....things
like:

\- Writing a sql optimization for their current company that saves resources

\- Creating shared memory interfaces for faster processing of logs

\- Modifying filesystems or kernel to create their own log processing

\- Modifying JVM to optimize critical code

\- Rewriting parts of a server to set up security alerts

\- Fast encryption and decryption of in-memory cache records

\- Writing an interpreter for faster generation of low level code for high
speed processing

\- And on and on

My point is, today's interview process treats engineers with such complicated
experience as shit because they spent time working on complex projects and
couldn't memorize these questions. But then these same companies will hire
some mediocre engineer who cannot think out of the box but is an expert at
memorization.

Said mediocre engineers then hire other mediocre engineers using the same
process, because these mediocre engineers do not even have the ability to
grasp what kind of engineering would lead to above points.

To top it off, these same mediocre engineers sweep this problem under the rug
claiming they are trying to reduce false negatives. Lol!

Sad state of the industry!

~~~
qaq
If this materially impacts the bottom lines of companies that are practicing
this approach eventually companies that are not using this process will
prevail.

~~~
NTDF9
>> If this materially impacts the bottom lines of companies that are
practicing this approach eventually companies that are not using this process
will prevail.

It would, if companies realize that they can save millions by improving their
interview processes and not have to aqui-hire so much.

But this insight requires smart people (who they eliminated with this
interview process) to be already hired in those companies.

~~~
qaq
While I highly dislike this trend it's hard for me to call say Sundar Pichai
not smart for example.

~~~
NTDF9
What do you think about Marissa Mayer? For every outlier winner person you
point out, the industry is littered with losers. Perhaps stop correlating
wrong things together?

~~~
qaq
Well if you theory holds how did Rob Pike, Ken Thompson, Guido van Rossum, Dan
Bornstein and on and on ended up at Google?

~~~
NTDF9
>> Well if you theory holds how did Rob Pike, Ken Thompson, Guido van Rossum,
Dan Bornstein and on and on ended up at Google?

You realize they got hired because of their fame and expertise? They didn't
have to go through intense whiteboarding. And even if they did, they would be
hired even if they didn't solve a stupid N-Queens problem?

~~~
qaq
I realise they have 0 problems with CS fundamentals while being at the same
time top experts in respective fields.

~~~
NTDF9
>> I realise they have 0 problems with CS fundamentals while being at the same
time top experts in respective fields.

I suspect your definition of CS fundamentals is only Algos and Datastruct
problems. Said experts are very good at what they do. That does not mean they
will whip out an algorithmic puzzle solution on a whiteboard under pressure.

I also suspect that those experts have better things to do than get a job at
Google. They'd rather not go through this process. Google wants them to be
there not the other way around.

------
khazhoux
It's a tragedy of our industry that this super FUN list of basic algo
problems, is connected in everyone's mind to lame-ass whiteboard interviews.
These problems should be like playing scales: engineers should just work
through these, practice them till they're no-brainers. But not to land that
sweet entry-level SWE job at Google, but just to grease your own wheels in
day-to-day coding and problem-solving.

~~~
acheron
I've never been to an interview that would ask this kind of crap, and would be
very surprised if a future interview did. So yeah, I'm just looking at it as a
list of possibly interesting problems, which makes it a way better link than
"interview help".

------
xaybey
As a fun warm up-question, I always ask the candidate what editor and keyboard
they use. The candidate who geeks out about their plugins and cherry switches
inevitably passes all 5 rounds; the candidate who uses eclipse with maybe a
vim plugin will go on to fail about 75% of the time. It's a good filter too;
I'd say 1 out of every 20 candidates expresses strong convictions.

I'm seriously considering using it as a dog whistle and skipping the
experience deep-dive (which tests if you are a good story teller), the systems
design questions (which tests if you can sync to the interviewer's sense of
judgement), and the algorithm hazing (which tests social anxiety). But I'm
worried there is some kind of discriminatory correlation baked into that
metric.

~~~
rachelbythebay
nano and a $10 Logitech k120. What's your verdict?

~~~
rfrey
I'm probably just reading this into your comment, but the challenging tone
makes it seem like you think OP is pretty misguided... like there's no
information to be had here.

But isn't an interest in tools pretty common in most crafts/trades? If I were
hiring a woodworker for my cabinet shop, I'd probably ask about favourite
tools. I wouldn't actually care if they talked about how a bandsaw beats a
tablesaw every time, or launched into a sermon about shopmade wooden
handplanes versus metal monstrosities. It's the presence of an opinion at all
that matters.

edit: I don't actually have a cabinet shop. :(

~~~
twic
Tools, yes. But seeing editors and keyboards as the tools indicates that
someone is operating at a pretty low level of abstraction. If you asked a
civil engineer what their favourite tool for designing bridges over deep
valleys was, and they said "a Rotring isograph" [1] rather than "parabolic
arches", would you be impressed?

[1] [http://www.cultpens.com/i/q/RT04273/rotring-isograph-
technic...](http://www.cultpens.com/i/q/RT04273/rotring-isograph-technical-
drawing-pen)

------
pfarnsworth
I have a friend who memorized all of these types of questions and answers. It
worked because he got offers from Google, Facebook and Uber, amongst others.
The key is to pretend like you're figuring it out on the spot and not just
regurgitating it from memory. I plan on doing the exact same thing when I look
for my next job. It's unfortunate, but the reality of the state of our
interviews.

------
khazhoux
I have two kinds of questions: (1) tell me about a problem you've solved, and
(2) let me tell you about a problem I'm facing. I'll never ask candidates
about made up problems. Why would I waste our time talking about fake stuff,
when there's so many actual real problems in front of us that we could dive
deep on?

~~~
alansammarone
The best, most fair interviews I've been through follow this pattern. I
remember one of them told me about a current problem they had, and told me
"You can google anything you want, you have 30 minutes. After that, you should
tell me how would you solve this problem, including any tradeoffs you've
made".

This is by far the most realistic scenario employees of most companies face.
It doesn't matter so much that one doesn't remember the specific details of
tree traversal or how linked lists are implemented. It matters much more that
one is able to find it out quickly, understand it and apply it. Those are the
skills you're looking for.

------
faragon
In my opinion, it is great having people trying to "memorize" those questions.
If they understand them, it would be like one half of formal computer science
studies. What is a shame is people graduated from Computer Science university
courses not remembering a clue about algorithms, because they "memorized" just
to pass the exam. BTW, some of the interviews may be are too much hard,
requiring being a Donald Knuth, having a "intelligence" index of 160, and
being a nice team player (if you target very smart people you'll deal with
crazy jerks most of the time -until those jerks become tamed, somehow-).
Super-smart people should target working for the NASA or similar, not for
writing APIs in Python 50 hours a week with just 3 week per year holidays.

Anyway, algorithms matter.

------
lkozma
Nice list, but a side-note: all this focus on interview-preparation may give
the false impression that algorithms and data structures is a closed body of
work, when in fact it is an active and lively field of research with many
basic questions not yet understood.

Someone could go through these 500 questions and for (almost) all of them
formulate variants/extensions that would be open research questions. Or
alternatively, ask for each of them: is this the best possible solution? Can I
prove it? What if I restrict what the algorithm can do? What if the data comes
online? What if the input is noisy? etc. etc. etc.

------
mtreis86
Dear HN,

Please stop telling companies not to use this method of interview.

Sincerely, Michael.

I use it to filter myself out before wasting anyone's time.

What I see here is an AND gate, and their use of this process itself triggers
the false in my own filters-for-job-positions system.

I see it as an uniform filter. The company is filtering me out, or in. And, if
I understand the reality of their options for filtering methods, I can use
that information to filter them back. Interestingly enough, this one is pretty
uniform for me, if they use the method of out-of-a-book problems in either an
on-the-whiteboard or pair-programming session, they have solved the problem of
whether I want to work in that position without my having to trouble myself
with memorizing problems to answer, nor waste their time screening me.

The filter I am applying here is against the out-of-the-book part of this. If
a company wanted to provide a previously solved bug in a section of their own
code, with enough information to debug but perhaps not enough testing written
into the system, to me this would not filter that position out. As long as the
job would be similar in setup to the methods used during the interview this
would be fine by me. Difficult, as the level of chaos internally to any
interviewee is very high, and most positions would not be nearly as chaotic as
the induced level this hiring process creates.

I think asking on-the-board questions, or running some pair programming, is a
filter for perspective, and attempts to identify how an applicant handles
chaos.

To put it another way, the company wants people who when they hear an alarm
will file out of the business in an orderly fashion, doing that job that has
out-of-a-book interviews during hiring. I personally walk towards alarms, not
away, and am plenty happy not to be stuck in a position that isn't supposed to
have someone like me in it.

My system is tragically flawed, of course. A company could easily use an
interview process they consider arbitrary to filter the lowest tier of
applicants (non-tech people fishing for a few months paid internet browsing),
and I could, not recognizing the insignificance of it, preselect them false
when they would have stopped that interview after ten minutes and hired me on
a handshake.

------
peteretep
I would love to see a "this can be solved in O(n)" annotation on each,
separate from the solution itself.

------
rv11
If you are just asking Algo and probably pseudo code, these questions might
help, but if you ask to write the proper code with boundary conditions etc,
that makes it difficult even if you know the Algo. Of course I am assuming
that no one memorizes the code ;).

~~~
peteretep
I used to give people a description of how an algorithm was implemented, and
ask them to write it out in code. Specifically we'd take the conversation to
boundary conditions, failure conditions, testing, etc, from there. I was
reasonably happy with the outcome.

------
fjdlwlv
The solutions here make the common mistake of ignoring the cost of stack
space, and thereby incorrectly claiming that recursive solutions have lower
space complexity than iterative solutions.

~~~
curiousDog
Not if you point out that whatever platform you're coding in employs tail
recursion I guess? But yeah the intermediate results will still have to be
stored somewhere.

------
signa11
here is an article by google vp about their approach to hiring:
[https://www.wired.com/2015/04/hire-like-
google/](https://www.wired.com/2015/04/hire-like-google/)

