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