Ask HN: How to prepare for a technical interview?

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.

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/ for details on how to do this.

[Shameless plug] We're one more option for preparation: 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!

* 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

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?