
Ask HN: How to prepare for a technical interview? - 40acres
I have a phone interview lined up with Google in 3 weeks which will hopefully lead to an onsite. I also have been reached by Facebook to set up times for a phone interview in the next couple of weeks.<p>I couldn&#x27;t pass either interview on short notice so I&#x27;ve scheduled my Google interview about 5 weeks in advance and have been brushing up on Algorithms &amp; Data Structures by following MIT&#x27;s Introduction to Algorithms (Fall 2011)[1] course on Open CourseWare to prepare. It&#x27;s been really helpful but lately I&#x27;ve been wondering if this is enough to properly prepare myself.<p>In doing research regarding other common interview preparation tools I&#x27;ve come across multiple books (Cracking the Coding Interview, Elements of Programming Interviews Exposed, etc.) and online resources (LeetCode, InterviewBit), even sites where you can set up mock interviews. It&#x27;s great that so many options exist but it&#x27;s given me a bit of decision paralysis when it comes to picking the best &#x27;curriculum&#x27; to study to pass these interviews.<p>For those of you who&#x27;ve had technical interviews recently, can you share your preparation strategy? What did you use to study? What went well, what would you change?<p>As a side note, judging by HN Search it seems like this community has a negative outlook on modern technical interviews, especially the types used by more &#x27;SV centric&#x27; companies which lean towards academic knowledge, and I understand that, but I&#x27;m unhappy at my current job and am open to interviewing for a new position, it just so happened that I was contacted by these two companies and I&#x27;d like to put my best foot forward.<p>[1] - https:&#x2F;&#x2F;ocw.mit.edu&#x2F;courses&#x2F;electrical-engineering-and-computer-science&#x2F;6-006-introduction-to-algorithms-fall-2011&#x2F;
======
itamarst
1\. Skim an algorithms text book.

2\. Do some exercises. Doesn't matter from where, it's just about mindset and
reminding yourself of all the algorithms you've never used at previous jobs
and will never use once you're hired.

I recommend that during actual interview you pre-write tests, write code, and
then "run" tests: this shows you're careful, helps you find problems and helps
you take control of the interview. See
[https://codewithoutrules.com/2016/04/04/interview-
puzzles/](https://codewithoutrules.com/2016/04/04/interview-puzzles/) for
details on how to do this.

------
wwalser
* Prepare. It's crummy that highly skilled practitioners have to do this in order to jump the sometimes silly hurdles put in place by technical interviews but it's a fact. No point bristling against it. I've always scheduled interviews in fairly intense blocks, interviewing at 4-8 companies over the course of a month. In the month prior to the interview month I spend about 100 hours preparing.

* The best practice for technical interviews is technical interviews. They are easy enough to set up, all growing companies are hungry for new talent and their pipeline is setup to create technical interviews, not filter people prior to technical interviews. Additionally, even if you're very good the failure rate is still relatively high. I'm a very confident interviewer for correctly matches roles and still get turned down about 1/4 of the time.

* Be prepared to talk, plan or converse about scalable architectures and approaches. For my last round of interviews I read a large portion of The Architecture of Open Source Applications[1] as prep work.

* Brush up on algorithms. There are so many places to do this that I honestly don't think any advice I can give you here will be more helpful than other resources on the web.

* Last but really first: Have a history of working at the same or just below the level as the job that you're applying for. Having both a depth and breadth of experience matters. If for some reason you don't have access to this type of experience you should seek it out via relocation, open source or remote work.

1\. [http://aosabook.org/en/index.html](http://aosabook.org/en/index.html)

------
daxfohl
You're on the right track. I went through the algorithms book and did some
leetcode and hackerrank problems, and did well on onsite interviews with four
large software companies this month. Leet is nice because they categorize
their problems, so you can make sure you're getting a good variety, and can
identify any gaps you may have. Even if you're a genius and have a ton of
experience, it's still important to work through some leet-style problems,
just to get back into the mind-set of how to quickly solve these types of
things, which don't come up often in day-to-day work situations.

Don't get terribly bogged down memorizing the details of e.g. red-black tree
implementation, nobody asks much about that. It's more about knowing what
algorithm to use for what job, and big-O complexity. Also make sure you know
how to use a trie (prefix tree): it's not in the algo book but seems to be a
popular interview topic.

In general, most interviews are similar to the kind of thing you find on
leetcode, generally at the easy to medium level. Write some code that does X.
Then it usually progresses to "what if you had a gazillion elements" or "what
if you had to do it in 64 bits of memory", etc.

In addition there are usually some high level design like "how would you
design a google search competitor?" which can go any direction from
distribution to redundancy to security (all high-ish level; you don't have to
know the details of these topics, just how to draw boxes and arrows). And
there may or may not be some situational "tell me about a time when" style
questions, so have some good examples prepared.

Practice your handwriting on a whiteboard. Practice going through your
solutions and describing them coherently. (Hint: draw some diagrams and slow
down, like every word you say costs a dollar). Don't give up: if you are
totally stumped, something along the lines of "Okay here's what I'm thinking
... but here's why I think it won't work ... am I on the right path or would
you suggest a different approach?". Ask questions to make sure you're using
your time wisely: does the interviewer want to see the "best possible"
solution, or does the interviewer just want to see the first thing that pops
into your head; does the interviewer want to see code or are we just talking
about it?

------
soham
[Shameless plug] We're one more option for preparation:
[http://interviewkickstart.com](http://interviewkickstart.com). We're a
bootcamp, which continually tries to answer this very same question - where to
start and how far to go, when it comes to preparing for technical interviews?

We usually remain booked very far out though. But if we can help you any time
in the future, please feel free to reach out!

------
dudul
Google and Facebook are known for always using the same set of questions
during phone screens. Just google for past experience and you'll be able to
compile a good collection of questions you'll be asked.

