Hacker Bits, April 2016

as hard as many of the people
we talk to fear. Algorithms
are usually described in academic
language, and this can
be off-putting. But at its core,
nothing on this list is more complicated
than the architecture of
a modern web app. If you can
build a web app (well), you can
learn these things.
The resource that I recommend
is the book The Algorithm
Design Manual by Steven Skiena.
Chapters 3 through 5 do a great
job of going over this material,
in a straightforward way. It does
use C and some math syntax,
but it explains the material well.
Coursera also has several good
algorithms courses. This one,
in particular, focuses on the
concepts that are important in
interviews.
Studying algorithms and
data structures helps not only
because the material comes up
in interviews, but also because
the approach to problems taken
in an algorithm course is the
same approach that works best
in interviews. Studying algorithms
will get you in an interview
mindset.
3. Get help from your
interviewer
Interviewers help candidates.
They give hints, they respond to
ideas, and they generally guide
the process. But they don’t help
all candidates equally. Some
programmers are able to extract
significant help, without the
interviewer holding it against
them. Others are judged harshly
for any hints they are given. You
want to be helped.
This comes down to process
and communication. If the
interviewer likes your process
and you communicate well with
them, they will not mind helping.
You can make this more
likely by following a careful
process. The steps I recommend
are:
1. Ask questions
2. Talk through a brute-force
solution
3. Talk through an optimized
solution
4. Write code
After you are asked an interview
question, start by clarifying
what was asked. This is
the time to be pedantic. Clarify
every ambiguity you can think
of. Ask about edge cases. Bring
up specific examples of input,
and make sure you are correct
about the expected output. Ask
questions even if you’re almost
sure you know the answers.
This is useful because it gives
you a chance to come up with
edge cases and fully spec the
problem (seeing how you handle
edge-cases is one of the main
things that interviewers look for
when evaluating an interview),
and also because it gives you a
minute to collect your thoughts
before you need to start solving
the problem.
Next, you should talk
through the simplest brute-force
solution to the problem that you
can think of. You should talk,
rather than jump right into coding,
because you can move faster
when talking, and it’s more
engaging for the interviewer. If
the interviewer is engaged, they
will step in and offer pointers.
If you retreat into writing code,
however, you'll miss this opportunity.
Candidates often skip the
brute-force step, assuming
that the brute-force solution to
the problem is too obvious, or
wrong. This is a mistake. Make
sure that you always give a solution
to the problem you’ve been
asked (even if it takes exponential
time, or an NSA super computer).
When you’ve described a
brute-force solution, ask the interviewer
if they would like you
to implement it, or come up with
more efficient solution. Normally
they will tell you to come up
with a more efficient solution.
The process for the more
efficient solution is the same as
for the brute force. Again talk,
don’t write code, and bounce
ideas off of the interviewer.
Hopefully, the question will be
Some programmers are able to extract
significant help, without the interviewer
holding it against them.
14 hacker bits