
Preparing for a Technical Interview: Algorithms and Data Structures - primaryobjects
http://www.primaryobjects.com/2017/03/28/preparing-for-a-technical-interview-algorithms-data-structures-and-computer-science/
======
jasode
Some constructive criticism... I would review your explanations to see if any
imprecise sentences can be replaced with more accurate definitions. I get that
you're going for a friendly tone but many times, the more accurate definition
is just as easy to read.

For example this text:

 _> In the case accessing an element within an array or hash, it takes 1
operation to perform. Thus, we can describe the complexity as O(1) for this
code example. This is about as good as it gets for algorithm complexity. Of
course, while O(1) runtime code is quite fast, it may often come at the
expense of storage._

It's clearer to say that O(1) means _constant time_ access in relation to
input size. The "1" doesn't mean one operation. The alternative explanations
you wrote are actually misleading.

------
csnewb
This is a great guide, thanks for sharing.

Out of curiosity, how do other employed developers allocate time to study this
stuff? Immediately after graduating from college I could spend 4-8 hours a day
most days of the week reviewing algorithms and solving problems without
issues. Now, after a full day of coding at work, going to the gym, coming home
to prepare dinner and run other errands, I'm physically and mentally drained.
I might spend an hour or two before bedtime trying to study this stuff (since
I completely forgot it since I last did technical interviews 1+ years ago) but
progress is slow. Of course there are weekends, but that's usually the only
time I get to relax and go outside to see the sun. I now understand why it
takes 6+ months for working professionals to find new jobs.

~~~
nullundefined
Honestly, don't bother practicing "this stuff". Instead, spend your time doing
what is important to you (family, friends, side projects, side business,
whatever).

If you need a job, then practice. While doing your job, do it well. Don't
waste your personal time on this "stuff". That's really a waste of time and
effort.

------
scott_s
The text does not differentiate between worst-case and average-case analysis.
Quicksort is worst-case O(n^2), but average-case O(n logn). Yes, I know the
text says "on average" in parenthesis, but that's not going to help a reader
understand what that means. For an article that is meant to prepare people for
a technical interview, I think it's important to make this kind of
distinction.

The article also says that merge sort is average-case O(n logn), which is
true, but is likely to confuse readers, as merge sort is also worst-case O(n
logn).

------
ggggtez
The BFS tree traversal algorithm is also O(N^2). Very sloppy, I'd take off
points.

~~~
kafkaesq
"Points"?

That kind of oversight is simply unacceptable in a modern, agile engineering
environment. Especially not in the august company of hand-picked, top-shelf
developers such as you've been able to compose your build your team out of,
thus far. So I'd fire them (or that is, shift ever-so-glibly to "Do you have
any questions for me?" mode) on the spot. And instruct my internal recruiter
to make a point of not bothering with any kind of follow-up after the
interview -- dense as they are, sooner or later they'll get the hint.†

† Again, I'm being blatantly facetious. But this is exactly how the "modern"
(Google-inspired) interview process seems to work much of the time, in
practice.

~~~
ggggtez
Is there something wrong with not wanting someone to write an n^2 function
that should only take O(n)? And the person who wrote this is supposedly giving
advice on how to pass such interviews for "top-shelf" programmers. So I don't
see how complaining about the existence of the process is relevant.

~~~
kafkaesq
_Is there something wrong with not wanting someone to write an n^2 function
that should only take O(n)?_

But that's not what the typical whiteboard session actually assesses -- that
is, whether you'd _never_ catch yourself, in _the normal course of
development_ , from implementing a grossly inefficient algorithm before
catching yourself, and long before significant damage has been done. BTW the
operative phrase here is "normal"; as in, the normal unhurried pace at which
we work, with time to reflect on these things during coffee and bathroom
breaks. And of course without being surrounded by tag teams of 20-something
dudes you've never met, comfortably assessing your every move -- secure in the
knowledge that they'll still be in a reasonably tolerable job, no matter what,
at the end of the afternoon; but as to whether you'll get out of your current
situation -- that's a total crapshoot, of course.†

What they test, rather, is whether your _immediate_ , muscle-memory recall of
the complexity class for _each and every use case_ is 100% correct -- subject
to the above-mentioned adverse conditions. Because no matter what they say
about "just wanting to see how you think through a problem" \-- in reality
these quickly devolve into zombie-like grading sessions (and, depending on
your state of nourishment and general composure, sometimes outright death
marches). Where -- very much unlike under real working conditions -- at the
slightest misstep, however temporary -- you start losing "points", and very
significantly risk the prospect of failing the process altogether.

 _So I don 't see how complaining about the existence of the process is
relevant._

It's an observation about a process that has been widely observed to be deeply
flawed, on multiple fronts. There's no need to label it as a complaint.

† Like as not, without adequate breaks for nourishment or bathroom needs -- or
a significant portion of the time, without a break of _any_ kind -- during the
whole multi-hour ordeal.

