
Data Structures for Coding Interviews - sharjeelsayed
https://www.interviewcake.com/article/python/data-structures-coding-interview
======
daliwali
I got an impression who their target audience is, based on the examples used,
drinking kombucha and listening to Spotify.

All the young, beautiful people who wouldn't have ever taken a computer
science course if it weren't such a lucrative industry to be in right now.

Maybe with this guide they can pass an interview at a big company where they
just twiddle with bits all day. I won't be holding my breath until they can
produce something useful.

~~~
nxsynonym
Blame the young, beautiful people all you want for not slaving away over a 4
year degree that puts them in the same position as 1 year of self learning
would get them, OR blame the business yuppies who keep coming up with the SaaS
business models that don't need anything more than plug and play code monkeys.

I understand memorizing data structures does not make a good engineer, but
honestly who is still asking for cream of the crop engineers, especially at
the entry/junior levels?

~~~
CodeMage
At the risk of sounding like a cranky old codger, I'd like to point a couple
of things out. If all you have are "plug and play code monkeys", all you'll
have is shitty software. The fact that shitty software is "enough" for so many
businesses is just another symptom of the biggest problem with our society: we
optimize for profit and damn everything else.

~~~
nxsynonym
Oh I agree completely. I just take issue with the fact that it somehow is a
"youth problem", as is being pointed out by the parent comment. It's a
business problem, not a lazy millennial/education problem.

Stop hiring shitty coders and you'll stop getting shitty interviewees. Less
shitty interviewees means less need for these types of "beat the coding
interview" services/blogs.

Honestly a lot of times the comments in these threads amount to "I was a geek
and it wasn't cool, I know CS from the ground up, and nobody deserves to have
an easy path to being a coder". It's an exhausted form of gatekeeping and
doesn't make anything better for anyone.

~~~
CodeMage
I'm not defending such comments, but there's more to them than just
gatekeeping. Speaking from my own point of view, the "I was a geek and it
wasn't cool" sentiment comes from feeling betrayed by having your lifestyle
become an industry that too often focuses on profit more than on quality; the
"I know CS from the ground up" comes from frustration with all the people who
dismiss learning from the ground up without understanding all the insights it
gives you; and "nobody deserves to have an easy path to being a coder" is an
exaggeration of "when you try to make learning easier than it can really be,
you end up dumbing things down".

Recently I found myself struggling to formulate my attitude towards software
development and the best I could come up with is "lifestyle coding": sure,
it's important to me to make something people will use and like, something
that will improve life in some aspect, but in the end, I'm in this because I
_love_ to create programs. To me programming is more than my job, more than
just means to an end, it's what I truly enjoy. People like me will often feel
bitter about many aspects of our industry and it takes a conscious effort to
keep aware of that feeling and to make sure it doesn't taint our decisions.

------
andrew_wc_brown
Big yellow newsletter box interrupts my reading that I was compelled enough to
open inspector and remove it.

The pricing makes no sense, that or its not obvious what you are getting in
the full-course.

The testimonials appear phony. I believe in products when I recognize
programmer celebrities or the testimonials link to a github or something to
prove they are legit.

The pay box is sketch. Even though its powered by stripe. I'm not dumping my
credit card without CVC, expiry and postal code.

There's nothing on here you can't already find for free. The value to me is
saving time. I've done this before but forget because web-programming the last
10 years rarely required to commit this stuff to memory.

I'm a different use case I suppose but I want a super abridge version. I just
don't want to a spend a week. I want to spend a few hours.

Theres nothing telling me how much time I will spending having to read through
this course material.

------
pavlov
Hiring engineers based on data structure trivia is like hiring a marketing
department based on spelling bee scores.

~~~
seanwilson
You'd really be fine hiring a senior developer that had no idea how a linked
list, a hash table or a binary tree worked? Understanding which data
structures are good for speed and memory usage is at a minimum required for
memory constrained apps and dealing with large scale data.

~~~
sidlls
Yes,I'd be fine with it as long as they could read and understand a table of
data specifying the time and space complexity of various data structures and
algorithms.

The amount of programming done in memory constrained apps and for large scale
data is tiny in comparison to all programming, most of which is very basic
CRUD type work meant for use in resource rich environments at small scale.

~~~
seanwilson
> Yes,I'd be fine with it as long as they could read and understand a table of
> data specifying the time and space complexity of various data structures and
> algorithms.

I'd find it highly unlikely they could do that while being unfamiliar with
core data structures and algorithms. A big reason to learn basic algorithms
and data structures is not to reimplement them yourself but to help you design
and understand your own algorithms and data structures.

> The amount of programming done in memory constrained apps and for large
> scale data is tiny in comparison to all programming, most of which is very
> basic CRUD type work meant for use in resource rich environments at small
> scale.

Those were just examples. I've seen plenty of cases of code for CRUD apps that
had problems handling just a few 1000 records because the coder didn't
understand memory usage and algorithmic complexity. I'd certainly want
lead/senior developers to have this knowledge even if it's rare they have to
step in to help in this area.

~~~
lmm
> I'd find it highly unlikely they could do that while being unfamiliar with
> core data structures and algorithms. A big reason to learn basic algorithms
> and data structures is not to reimplement them yourself but to help you
> design and understand your own algorithms and data structures.

But you so rarely want to implement a new algorithm or data structure. I
suspect someone who knows how to implement a red-black tree is, all other
things being equal (and I know all other things would not be in practice, but
bear with me), worse for most programming jobs than someone who doesn't (but
who knows what its performance characteristics are) - you'd never want a
programmer to implement their own red-black tree, that's a maintenance
nightmare even if they do it correctly, you'd want them to use the one from
the standard library.

~~~
seanwilson
Yes, you should never be reimplementing something that's in a standard library
and for what it's worth I would never expect an interview candidate to know
how to implement a red-black tree.

What I meant was that knowing core algorithms and data structures is important
so you can recognise familiar problems so you avoid reinventing the wheel +
you know where to look for answers. Maybe you have to use some clever
combination of data structures to model your data efficiently. Maybe your data
is actually a graph so now you can lean on graph algorithms. Maybe you just
realised you're naive implementation to answer some question about your data
has n^2 growth so now you can consider if a different data structure would
help.

Personally, I find people that have poor knowledge of data structures and
algorithms are the ones that will reinvent the wheel the most as they don't
know what exists already.

~~~
lmm
What do you mean by "knowing core algorithms and data structures" then?
Because for me that phrase would definitely include knowing how to implement
your own red-black tree, hash table, linked list and so on.

~~~
ubernostrum
Being able to implement off the top of one's head is a skill that fades as
soon as one is no longer required to do so.

Requiring it as a criterion of hiring is, essentially, a back-door way of
saying "we only hire people fresh out of college", since they're the ones
who've recently been having to do this stuff on exams and have it fresh in
their minds.

~~~
seanwilson
> Being able to implement off the top of one's head is a skill that fades as
> soon as one is no longer required to do so.

I haven't implemented a hash table, linked list, growable array or binary tree
for years but know I could because I understand how they work and I select
which one to use often while coding. I find it hard to understand how you
could claim to know how those data structures work and not be able to
implement them.

~~~
sidlls
My point was that most of the time one doesn't need to know how they work in
the first place for the vast majority of programming. Simply memorizing or
referencing a card with very simple performance metrics (e.g. "dict: fast map
of keys to values; array: very fast lookup by integer index") is sufficient
for most cases today. Very few people who are doing any programming work need
to know that the "dict" is a hashtable or some esoteric data structure with
similar performance, or even anything else at all about it except for the API
for it.

~~~
seanwilson
If someone can memorise how a dictionary and an array work, why would they
have trouble quickly understanding how a hash table works for example? To me,
coding for years and never coming across or being curious about understanding
hash tables when they're applicable in so many places and not hard to
understand is a bad sign. I don't care about more esoteric data structures but
linked lists, hash tables, arrays and binary trees should be basic knowledge.

~~~
sidlls
They wouldn't necessarily have trouble understanding what's under the hood,
and that isn't my contention anyway: I contend that whether they _can_ and
whether they _need_ (or even _ought_ ) to do so are separate questions, most
of the time with the latter answered in the negative.

------
rzzzwilson
I read this

    
    
      What happens if we have the number 256 in an 8-bit unsigned
      integer (1111 1111 in binary) and we add 1? The answer 
      (257) needs a 9th bit (1 0000 0000).
    

and I didn't read any further. I don't think many interviewers would be eager
to continue after hearing that, either.

~~~
ahjones
I think you're being a little bit unfair. The same block then continues:

    
    
      This is called an integer overflow. At best, we might just get an error. At worst, our computer might compute the correct answer but then just throw out the 9th bit, giving us zero (0000 0000) instead of 257 (1 0000 0000)! (Python actually notices that the result won't fit and automatically allocates more bits to store the larger number.)
    

The article is introducing the concept of integer overflow.

~~~
ldite
1111 1111 = 255

1 0000 0000 = 256

Anyone who claims to understand integer overflow from actual experience,
rather than memorizing textbooks, should know that by inspection.

I'd forgive that in a CS grad (possibly) but if someone claimed to have been
working in C or other unsafe languages for more than a trivial amount of time
I'd be very suspicious.

~~~
fulafel
That's only assuming 0-based numbers :)

~~~
philh
(I know you're being tongue-in-cheek, but)

> our computer might compute the correct answer but then just throw out the
> 9th bit, giving us zero (0000 0000) instead of 257 (1 0000 0000)!

------
dcw303
This is a good cheat sheet for those who don't have (or have forgotten) the
knowledge but want to game an algorithm heavy interview. The problem I got
with this is exactly the same as when I tried reading the "Cracking the Coding
Interview" book:

I got through a few chapters and then the author mentions something off the
cuff with an assumption that the reader will know what they mean. But of
course, I don't, because these books are basically a collection of cheats and
hacks. I get frustrated that I don't understand it, so I seek out something
that starts with the fundamentals and expands from there.

What I'm trying to say is that I'd rather slog through 900 pages of Sedgewick
and come out with a thorough understanding rather than try 20 quiz questions
to be stumped by whatever the hell they were trying to get at with question 21
and then give up.

~~~
bsamuels
i have the same feelings about "cracking the coding interview"

the day someone unironically asks me to "Write an algorithm to print all ways
of arranging eight queens on a chess board so that none of them share the same
row, column or diagonal" \- I will jump off a bridge

~~~
rootlocus
I went to a CS high-school (not university) and we studied backtracking in the
first or second year. Everyone was supposed to know how to solve this and
similar problems for tests.

~~~
PeterisP
Sure, you'd know that _right_ after a CS high-school - however, if after that
school you go on to work on real problems for a decade or two, then you won't
know that anymore, since outside of very specific domains you don't really
write such things from scratch anymore; you'd always want to use existing,
optimized&tested implementations of all the common and less common data
structures and traversal algorithms instead of rewriting them.

You forget what you don't use, and this is stuff that you don't use.

IMHO the big problem is that they're missing the point on _why_ we ask
students do do these algorithm implementations - it's not so that they'd learn
how to do _that_ (though a bit of general programming practice is useful), we
put them there as _hands on exercises_ so that students would understand the
_usage_ of these algorithms better.

The implementations are just a learning aid, not a learning goal. Asking to
reimplement a red-black tree is somewhat comparable to asking what was shown
in a particular instructional video or what practice problems were assigned in
that class - checking if you remember the details of a particular teaching
instrument.

------
yeswecatan
I bombed an interview last week. Five straight hours of whiteboarding. One of
the interviewers (just a year or two out of school) admitted he got his
questions from interviews he went on in the past. What he didn't mention was
whether or not he answered the problems correctly. What if I was being judged
for not being able to solve something he could not solve himself?

People that ask these types of questions take the easy way out. It's a lot
harder to ask thoughtful questions that really try to gauge if somebody knows
what they're talking about because you have to really understand things
yourself. For instance, somebody can easily say they setup a pipeline that
scales. Sounds great. Asking questions that makes them go into finer detail to
make sure they're not bullshitting you is a bit tougher.

------
trevor-e
The article is really well written and has amazing design, but honestly does
not seem very helpful. Isn't most of this learned in the first year of
university? Who is the target audience in that case? Given the title, I hoped
to learn some lesser used data structures rather than what a pointer is. With
that said, I do look forward to future articles!

~~~
gameguy43
Author here :) Thanks for the note--this is interesting.

Target audience is folks who never learned this stuff, or learned it but
forgot it. Interesting to hear you had a different assumption from the title.

If you want something trickier, check these ones out:

[https://www.interviewcake.com/question/stock-
price](https://www.interviewcake.com/question/stock-price)

[https://www.interviewcake.com/question/swift/find-
duplicate-...](https://www.interviewcake.com/question/swift/find-duplicate-
optimize-for-space)

~~~
trevor-e
I suggest that you market the series in a different way, perhaps "An
Introduction to Data Structures", or something along those lines. Out of all
the bullets in your outline you really only cover lists (random access,
linked) and hash tables as actual data structures. That's partly why I
expected a totally different article based on the title.

You could argue that the others are technically data structures, but I'm
willing to bet most people will assume your standard list, map, heap, trie,
tree, graph, etc. It's kind of like saying "Calculus for AP tests" and then
only covering algebra up to Riemann sums.

Thanks for the links, I'll give them both a shot.

edit: just remembered that Calculus isn't on the SAT :)

~~~
gameguy43
Iiiiinteresting.

Definitely agree that the first half of the article isn't exactly data
structures yet.

But I just struggle with calling something "An inroduction to X." Have you
ever heard "an introduction" and thought "oh, that's what I need!" I picture a
super-dry textbook. Or one of those YouTube videos that promises to teach you
how to do a thing but starts off with the person saying, "Now, before we get
started..." and talks about nothing for 5 minutes before actually teaching you
the thing.

------
gameguy43
Original Author here. Happy to answer questions about this piece or coding
interviews in general!

And eager to receive any feedback.

Thanks for the post!

~~~
throwawaybbq1
You've got a cool site and I appreciate all the hard work creating high
quality content (I've looked at the free questions and considered subscribing
a few times in the past). I think your business model/pricing could use work.
Unless I'm mistaken and things are going well .. in that case, I'll withdraw
to my cave :-p

My suggestion would be to have a slightly cheaper tier (probably no more than
a hundred bucks). This mirrors the cost of two-to-three interview books. You
could add a custom grading or personalized tutoring option for the full 500,
or heck, even more (this is sort of like the GRE/GMAT prep option). Come to
think of it .. I wonder why the GRE/GMAT prep crowd hasn't tackled programming
interviews?

~~~
gameguy43
Thanks for the note. Definitely a great point. Not sure yet how we tier out
our product, but tiered pricing is definitely the state of the art.

We've been working on some /tech/ to enable tiered pricing in the meantime.
The Site's all custom, and so far there's no notion of a "product" yet...just
"paid" and "unpaid."

Share your question re: where's Kaplan on this stuff!

~~~
neerkumar
Price seems expensive to me as well. In data science there is a similar site
which has become pretty popular if you are interviewing in those top tech
companies, but it is cheaper.

As the guy above was suggesting, that data science site does personalized
feedback and that justifies the high price. Otherwise, the way it is now, it
feels like it should be priced similarly to CTCI.

~~~
gameguy43
What's the data science site!

~~~
neerkumar
[http://datascientistjobinterview.com](http://datascientistjobinterview.com)

~~~
gaius
It's crazy that there is a whole industry dedicated to cheating ahem gaming
job interviews in software/IT. Imagine if doctors or lawyers or real engineers
did this. No wonder we can't get taken seriously as a profession.

~~~
logfromblammo
Imagine if docs could be rejected from a new job because they failed to repeat
the obscure diagnosis that was featured on the last episode of House, that
really has nothing at all to do with the job they wanted to do.

Imagine if lawyers could be rejected for not being able to explain the
minority opinion in Foobar v. Bazquux, which again, has absolutely nothing to
do with their expected duties as prosecutor of poor people with small amounts
of marijuana.

Imagine if real engineers were asked to build a suspension bridge out of silly
putty, table salt, and carbon fiber.

The interviewees are simply doing their jobs, which is to analyze a problem
and implement the most cost-effective solution. The interviewers are the ones
causing the problem. Granted, it isn't always because they are non-technical
people trying to gauge the value of skills they don't understand. A lot of
times, it is because the interviewer is a tech person that still can't
effectively gauge the value of skills they do understand, and also wants to
look clever in front of a stranger, subtly discriminate to preserve "culture",
and do the same stuff to others that had been previously done to them in their
interviews.

~~~
gaius
_subtly discriminate to preserve "culture"_

Indeed; this is a point I make over and over. HR departments aren't smart
enough to detect ageism being openly practiced right under their noses...

------
nu2ycombinator
They are charging $200 for 40 odd questions. If this makes such a business,
this tells how fucked up the whole interview process is.

------
nichochar
> Don't worry—we'll skip the convoluted academic jargon and proofs.

Aaaaand this is why I hate using this as a method for interviewing. I actually
care a great deal about people that care about that stuff. I would rather you
know all the principles and can reason your way back up, however slowly, than
repeat something you've practiced enough for an interview.

I understand the author really only wants to help people, but let me tell you
as someone who works for one of the "cool unicorns" that the quality of
software engineers is really bad, most likely because of this efficient
"gaming of the system".

~~~
Mutinix
It's unfortunate, but all the companies are doing this.

Here's what a Google lead said in a tweet:

> Hello, my name is Tim. I'm a lead at Google with over 30 years coding
> experience and I need to look up how to get length of a python string.

DHH:

> Hello, my name is David. I would fail to write bubble sort on a whiteboard.
> I look code up on the internet all the time. I don't do riddles.

Max Howell:

> Google: 90% of our engineers use the software you wrote (Homebrew), but you
> can’t invert a binary tree on a whiteboard so fuck off.

And yet, everyone is asking these questions about print a string in zigzag
fashion or something silly like that.

Engineers are gaming the system because the system is garbage. None of us are
looking forward to waking up and solving HackerRank, LeetCode and CtCI
problems till the joy of programming leaves our bodies.

~~~
smnscu
Ah, the perennial apologetics of weaponized mediocrity. If you can't write a
simple recursive algorithm that swaps two values (Max Howell), two nested for
loops (DHH), or show me that you used Python at least once (uhh length? yes,
there is this builtin, I forgot its name...), why would I want to hire you
over someone who has seen a computer before?

And to avoid being called hypocritical, here's off the top of my head how the
answers would look like (I don't use Python very often either):

1\. len(thingie)

2.

    
    
      def bubsort(arr):
        if not arr: return None
        for i in range(len(arr)):
          for j in range(i+1, len(arr)):
            if arr[i] > arr[j]: arr[i], arr[j] = arr[j], arr[i]
        return arr
    

3.

    
    
      def revtree(node):
        if not node: return None
        node.left, node.right = revtree(node.right), revtree(node.left)
        return node
    

edit: works well for something coded on the toilet:
[https://gist.github.com/andreis/69a242330617b2a62753ce604e27...](https://gist.github.com/andreis/69a242330617b2a62753ce604e276c0d)

~~~
Mutinix
> why would I want to hire you over someone who has seen a computer before?

Because, you know, they invented Ruby on Rails and Homebrew? Incredible,
really. You were so adamant on being hostile that you managed to put yourself
over Max Howell and DHH in a couple of sentences. These people have made
valuable contributions to the tech industry as it stands today. This is a fact
and not an opinion. They invented Homebrew and Ruby on Rails.

Good job, you solved the problems and are more likely to be hired by Google
than Max Howell. Except he created the most popular package manager in OSX
history and companies still can't see that.

~~~
dozzie
> Except he created the most popular package manager in OSX history and
> companies still can't see that.

First, Homebrew is just a rehash of package managers that were available on
unices for more than a decade. Then, from what I hear, Homebrew was (still
is?) badly designed and implemented for quite a long time, which is not an
evidence of author's high skills (as a programmer, anyway).

~~~
Helmet
This is so ridiculous that I'm not sure if you're being sarcastic or not. If
not, you are the very definition of why n-gate.com exists.

~~~
dozzie
Which part is ridiculous? The fact that Dpkg, RPM, their peers, and
infrastructure on top of all that (APT, up2date, Yum, BSD ports, Gentoo
Portage, and so on) existed for a long time before Homebrew, the fact that
people were constantly complaining about Homebrew breaking their installed
packages on update, the fact that it used to require /usr/local to be user-
owned, or the fact that it wasn't using (still isn't? I haven't checked)
cryptographic signatures for downloading software to install?

------
nikofeyn
i actually have began to enjoy places that use these types of things for
interview questions. it's a good way for me to know that i don't want to work
there.

i once interviewed at a prominent company focusing on a certain language. they
specifically stated in their job application that they just wanted motivated,
enthusiastic, and smart people and that they didn't care if you knew said
language. i sent them my resume with some recent code from my job since i had,
within a few weeks, learned their language of choice on the job and on the fly
for a project. it got their attention since it was decent code for someone new
to the language. in the interview, they proceeded to quiz me on the language,
including very specific details of how the language is implemented and things
that don't even matter in day to day use of the language. and most of the
stuff was something you could easily learn over a period of days or a week by
just reading. it still boggles my mind. people, even very smart people, have
no idea how to interview.

~~~
CharlesLiuCN
That's true, but this kind of interview questions will always be asked even
for so called BAT in china.

~~~
thaumasiotes
What is BAT?

------
grassfedcode
I recently added data structure visualization to a gdb frontend called gdbgui,
which might be of interest to people trying to debug their algorithms.
[https://github.com/cs01/gdbgui](https://github.com/cs01/gdbgui)

------
bastijn
I once walked into an interview with such questions. On the first question I
asked them why they asked the question. The interviewer looked puzzled and
asked me to finish the question. I again asked him why, what part of my job
would require it. He couldn't answer that question whilst he was an engineer
at the department I was interviewed for. I asked a follow-up question if he
had the same questions when he joined, and if he ever felt the need for that
knowledge particularly. He responded it was good to know, companies like
Google and Amazon did the same. I walked out five minutes later thanking them
for their time. I could have answered the question easily but what for?

In the off chance that someone stumbles along and blindly copies this into
interview questions for his company. Think again, realize what your company
needs and tailor your recruiting process for that instead of copying stuff
others do.

Thanks.

~~~
ng12
> I could have answered the question easily but what for?

To show that you're not a complete diva who's willing to put in some work even
if it's unpleasant?

The question I ask is not real, either. It's entirely contrived. But I ask it
because it's the best way I know to identify candidates who:

    
    
      1. Can think critically about a data structure.
      2. Can communicate with me about how to solve non-trivial problems.
      3. Can translate an idea into code without thinking about it too hard.
    

Given lots of time there are much better ways to test a engineer for these
attributes. Given an hour it's about the best I can do. That's not to say
everyone who asks these types of questions does it well (I think there's a
fair bit of cargo-culting around "The Google Interview") but if you're
unwilling to even humour me I think walking out is the best response for both
parties.

~~~
bastijn
First, if he would have given that answer instead of saying others did it I
would have answered the question. However, his answer indicated they asked
just because of asking.

Second, even when you have those reasons ask questions on actual situations
that would occur on the job. You run a large C# code base that struggles with
its size and configuration complexity vs flexibility? Ask questions on how he
would design a new speculative module for the Platform. What kind of pitfalls
would he foresee? What would he focus on? See if his answer include your
struggles indicating he understands what his daily job is about. If you search
an engineer to speed up your image processing pipeline which is C++, data
structures can be fine but don't forget that before optimizing them you
probably have to spend a lot of time optimizing the design of the entire
pipeline so also ask questions about that part.

My main advice is think before you ask. If you have valid reasons, feel free
to ask data structures. If you don't, think again.

~~~
ng12
I think that's putting the cart before the horse. Every company I've worked
for has had a hard enough time just finding people with basic coding literacy.
Finding somebody with good problem solving, communication, and programming
skills is the hard part -- wondering if that person is the guy to architect a
specific aspect of our platform is secondary. I can't speak for that job in
particular but if half of your promising-looking candidates are getting weeded
out by simple programming puzzles the bar tends to shift.

~~~
bastijn
It was meant as an example. If I would interview for an architect I would
probably ask such a thing as I need to know if s/he would be capable of
thinking ahead and outside of the direct requirements.

For an engineer I would ask different questions. However, if I interview them
for a job that does not focus on performance or scalability I would rather ask
questions based on situations they run into than data structures. Data
structures would be a last resort if I had no other options for questions. For
most knowing when to use a certain data type is sufficient for me. Like math,
I don't need them to give me the full proof of the theorem as long as they
know it exists and can apply it in their daily work.

That doesn't mean I wouldn't like a candidate who has it all of course. But
those are scarce here, and probably everywhere as you mentioned. I am already
happy with a person who can do the job s/he was hired for and hopefully more.

Again, if you have valid reasons to ask what you ask, do. If not, think again
if there are better alternatives is all I advocate.

------
ShirsenduK
12 years of professional coding, still haven't been able to use my data
structures knowledge!

~~~
davidcbc
You've never chosen to use a set over a list because it is quicker to see if a
value exists in a set?

You've never had to choose between an array and a list?

------
axaxs
Maybe it's just me, but I hate these interviews. Why? Because it excites me to
do interesting things. Then I inevitably just end up writing REST APIs.

~~~
arwhatever
I've had the same thought - if I actually did the interview-type algorithms
and multi-system scalability challenges on a day-to-day basis, it might just
be a super cool job.

------
weatherlight
If you can't explain it simply, you don't understand it well enough. All these
CS Degree wizards and gatekeepers need to come out of their ivory towers.

------
asdq
Also, refer [http://www.techiedelight.com/list-of-
problems/](http://www.techiedelight.com/list-of-problems/)

~~~
AlgoLover
using STL - [http://www.techiedelight.com/data-structures-and-
algorithms-...](http://www.techiedelight.com/data-structures-and-algorithms-
interview-questions-stl/)

------
watwut
It is exceptionally well written. It also seems to be targeted at very
beginners, so I think it could also do good as targeted for students.

