Hacker Bits, April 2016

similar to something you’ve
seen, and you’ll know the answer.
If that is not the case, it’s
useful to think of what problems
you’ve seen that are most similar,
and bring these up with the
interviewer. Most interview questions
are slightly-obscured applications
of classic CS algorithms.
The interviewer will often guide
you to this algorithm, but only if
you begin the process.
Finally, after both you and
your interviewer agree that
you have a good solution, you
should write your code. Depending
on the company, this may be
on a computer or a whiteboard.
question, the candidate is asked
how he or she would design
a complex real-world system.
Examples include designing
Google maps, designing a social
network, or designing an API for
a bank.
The first observation is that
answering system design questions
requires some specific
knowledge. Obviously no one
actually expects you to design
Google maps (that took a lot of
people a long time). But they do
expect you to have some insight
into aspects of such a design.
The good news is that these
learn this is to read about how
other engineers have used the
concepts. The blog High Scalability
is a great resource for
this. It publishes detailed writeups
of the back-end architecture
at real companies. You can read
about how every concept on the
list above is used in real systems.
Once you’ve done this reading,
answering system design
questions is a matter of process.
Start at the highest level, and
move downward. At each level,
ask your interviewer for specifications
(should you suggest
a simple starting point, or talk
...you may also encounter system design
questions. Companies seem to like
these especially for more experienced
candidates.
But because you’ve already
come up with the solution, this
should be fairly straightforward.
For extra points, ask your interviewer
if they would like you to
write tests.
4. Talk about tradeoffs
Programming interviews are
primarily made up of programming
questions, and that is
what I have talked about so far.
However, you may also encounter
system design questions.
Companies seem to like these
especially for more experienced
candidates. In a system design
questions usually focus on web
backends, so you can make a
lot of progress by reading about
this area. An incomplete list of
things to understand is:
• HTTP (at the protocol level)
• Databases (indexes, query
planning)
• CDNs
• Caching (LRU cache, memcached,
redis)
• Load balancers
• Distributed worker systems
You need to understand
these concepts. But more importantly,
you need to understand
how they fit together to form
real systems. The best way to
about what a mature system
might look like?) and talk about
several options (applying the
ideas from your reading). Discussing
tradeoffs in your design
is key. Your interviewer cares
less about whether your design
is good in itself, and more about
whether you are able to talk
about the trade-offs (positives
and negatives) of your decisions.
Practice this.
5. Highlight results
The third type of question you
may encounter is the experience
question. This is where the interviewer
asks you to talk about
a programming project that
hacker bits
15