

Ask HN: How to prepare for technical interviews? - thewarrior

I&#x27;m good at my day to day job but I suck at whiteboard style interviews. I&#x27;d like to hear form any HN&#x27;ers who have gone from Level Zero to pro at acing tech interviews. How you prepared , what resources you used and how long it took.
======
nailer
Whiteboard tests are an excellent way to tests someone's ability to:

\- write using their hands

\- face one direction and talk in another

\- talk while coding

\- estimate insertion space

\- write in horizontally straight lines

\- avoid getting ink on their sleeves

The best places I've interviewed at game me a machine, a problem, and some
quiet time to solve it.

However for others, I bring pencil and grid paper, and ask to sit beside
people and solve the problem with them looking over my shoulder.

~~~
kls
I could not have said it better, white-boarding is about as far away from a
persons coding routine as it gets. Not to mention we all rely on REPL and the
debugger from time to time to save us from simple mistakes, there is no
iterative process on the whiteboard. Interviewers that insist on white-
boarding should be viewed as companies that don't "get it" and you should
focus your time elsewhere.

~~~
dagw
I've never had a white board interview where the interviewer cared about
syntax or simple mistakes. I always 'code' in a mixture of pseudo code, math
notation and diagrams depending on what makes sense and no one has ever
complained.

------
mrcold
Practice. There is nothing else that can prepare you better. Assume that you
will fail the first 5 interviews and use them to learn. After a while, you get
the hang of it and learn how to fake it for the real thing.

And remember, you do your best when you don't care about the job. If you do
care, your nervousness and desire to impress will be perceived as
incompetence. And at that point, you're just sabotaging yourself.

~~~
sevilo
I hear the second point all the time and I can agree with it from my personal
experience, but what would be a good way to "not care"? For me, when I know
I'm interviewing with a company that I'm excited about, it seems a lot harder
to actually "not care" about it than just saying it.

~~~
dropit_sphere
The best way to not care is to actually not care---to have another interview
lined up with a company you're just as excited about.

------
khangsile
Some advice from when I studied for these no more than two months ago: 1\.
Cracking the Code - get ahold of it and read through it. It 'll give you all
the topics that you should study through and some tricks that are helpful in
implementations. You'll still need to use other resources in order to know the
topics in depth, like I don't think it goes too in depth into dynamic
programming, but the book does have a large amount of questions and solutions.
2\. oj.leetcode.com - This is just a website kind of like how interviewstreet
was, and something around 180 problems that are interview style problems. You
should be fine if you can do the almost all of the medium or easy level
problems and maybe some of the hard ones. For these, I'd definitely get out a
notebook and write out solutions and then throw type them up, to get a feel
for how whiteboarding is going to be. 3\. If you've got friends who are in the
same position, actual mock interviews in person are an enormous help. I had a
couple friends get together, and one of us would do one problem at a time
while the rest evaluated them - basically acted like the interviewer.

With regards to timeline, I think I started preparing for my first phone
interview a week early. The first couple of days were definitely slow, but
with 3 days left, I studied for a couple hours each day before. For my first
onsite, I found out about oj.leetcode.com about two weeks before and just did
those problems almost non-stop for the two weeks leading up. Five days before
the onsite, I rounded up some friends and we started doing whiteboard problems
for a couple hours each day.

I guess preparation time varies by person. I did a little bit of competitive
programming before this, so I would say I had a little bit of a head start.
However, before this, I probably couldn't program a binary search off the top
of my head, or approach dynamic programming problems, but now, I can probably
handle a decent amount of algorithmimc interview problems. I can't say I'm
pro, but I'm apparently good enough.

------
mathgeek
I'm sure you've heard it before, but Cracking the Coding Interview is still a
great resource. Do the problems on a whiteboard or on paper. The sections on
soft skills and interview prep are also gold.

Additionally, site likes Top Coder and Hacker Rank are great for brushing up
on your algorithms and problem solving.

------
Klockan
It is very important to understand that you can't expect that your mind will
work properly during an interview. So if you can't do it in your sleep then it
isn't good enough. There are only two ways to reach this stage, either it
becomes second nature to you or you memorize everything. If you still want to
proceed then you can try these steps:

Firstly you need to learn to code small 10-20 line programs in your head
(everything including proper syntax etc, if you printed a copy of your mental
image it would compile), without that you get crippled just from being unable
to properly reason about your code.

Secondly you need to build up an intuition for data structures and algorithms
so that you can easily come up with solutions on the fly. Very few do this,
some even thinks that it is impossible and assumes that the questions only
test memorization.

As an alternative to the second step you can memorize a ton of algorithms and
continue going to interviews till you get a question you have memorized. This
is what people usually do which isn't strange since this is how most pass
their CS exams.

The first step is easy, just stop using your favorite IDE and use something
simple like notepad. When you are comfortable with writing code in notepad
then you are ready for interview programming.

The second step is harder and will take years. The easiest way to get better
at this is to try to solve problems without help. You can start by reading up
on different data structures/algorithms on wikipedia and then try to implement
them in your favorite language. You can do competitive programming in parallel
to practice speed and try out your implementations on tests which are much
better at finding bugs than any interviewer.

The alternative second step can take any amount of time depending on how lucky
you are. Minimum is to memorize FizzBuzz by writing it over and over in
notepad till you get it right 20 times in a row. This can be done in a day
even if you are an idiot. From there you can continue adding solutions to
problems till you get the job you want. Then just forget everything and come
back complaining once you want another job. This already happened once for
fresh CS graduates since they forgot what they crammed for their tests so now
they need to cram again and again for every interview.

------
dagw
The problem most people have with whiteboard interviews is that they have no
strategy in mind before they start. They just step up to the whiteboard and
hope inspiration will strike. My recommendation is to read Polya's How to
Solve It. Then just follow the steps it presents once you get in front of the
whiteboard. This way even if you don't immediately know how to solve the
problem they present you at least have somewhere reasonable to start and a
general map to follow.

------
smt88
Whiteboard interviews are complete bullshit. I know that not everyone is lucky
enough to work for companies that know that, but you should try.

Slightly more related to your question: once you get to a certain point, you
shouldn't still be doing whiteboard interviews. Your resume and completed
projects should tell the interviewers that you can code, or you should be
moving to management (if that's your thing). I never even ask technical
questions of someone who has good references from a few companies.

~~~
mrcold
Unfortunately it doesn't work like that. At multiple interviews I was asked to
do code challenges or solve FizzBuzz exercises. I replied something along the
lines of _" I built a commercial product all by myself. Here is the website so
you can play with it. Here are some code samples."_.

And the answer I got always left me speechless: _" Well, I don't really know
what code you used or if you actually wrote it. So we're just going to
fizzbuzz you to make sure you're good. We do this with everybody"_.

This didn't happen just once. It was actually the vast majority. The no-
whiteboard approach seems to work only with early-stage startups. Once a
company starts settling, say hello to mindless bureaucracy.

~~~
valdiorn
It's not mindless to make sure a candidate can actually produce some code.
You'd be surprised how often people are hopelessly fucking incompetent at
actual coding.

I'm used to getting these alpha dog; VP-of-whatever from big investment banks
(I work in finance), with a laundry list of stuff they have done. Sure ok,
good for you, now write up a skeleton class for a linked list in _any language
of your choice_... what's that, you're stuck? You can't remember the keywords
for defining a new class in the language you've labeled yourself as an EXPERT
in? really?

~~~
mrcold
When you hire a lawyer, do you test him with imaginary laws? If not, why are
you doing it with engineers?

Engineers solve problems. That's it. They use tools, they try things and they
provide solutions. Asking an engineer to solve an imaginary problem on the
spot is idiotic. You may have glided through school memorizing stuff and
barfing them during exams. But engineers didn't. They understood how things
work and why.

So when you ask an engineer to write a skeleton class for a linked list, his
answer will always be _" Why? What problem are you trying to solve?"_. They
don't have it memorized. They build it as they go along, based on the
specified requirements.

Unlike you, most engineers are friendly people. And not as aggressive. All
they want to do is build something or help you do it. You on the other hand
seem to have some envy problems. The _" AHA! Not so smart now, mr VP of
whatever..."_ attitude is exactly what's wrong with the tech industry.

Leave it to a bureaucrat to fuck things up.

~~~
babygoat
Are you talking about memorizing what a linked list is, or someone else's
code? I don't understand what is imaginary about such a ubiquitous construct.

~~~
jaredsohn
I think the GP considered it an "imaginary problem" in that if you really
needed a linked list for something, you would probably just make use of an
existing library rather than write it yourself.

------
MalcolmDiggs
The best technical interview prep (IMHO) is to go on lots of warmup
interviews. In other words, apply to lots of companies, and start with the
interviews at places you _might_ not actually want to work. Gradually build up
to the high-pressure interview at your dream employer. Once you're in that
room you'll be well practiced and ready for anything.

------
loumf
Ask friends for mock interviews.

~~~
bengali3
this. I think there was a show HN in the past few months that offered this
service?

~~~
loumf
I'm pretty sure any random person that has contact info in HN would mock
interview you for practice.

