Ask HN: How do you prepare for interviews?
How do you prepare for technical interviews, especially those that you know will involve whiteboard coding? How much time do you invest in reviewing algorithms that you haven't used in a while? What are the best prep resources?
11 comments
[ 5.4 ms ] story [ 42.8 ms ] threadDisassemble their products and research whatever tech they used to build them for strengths & weaknesses.
Dig up whatever background info you can on the people who will be interviewing you.
None. I don't want to work at companies that only hire people who memorized Red-Black trees.
If you don't remember, just say so. Try to reason about it, stating what you do know and can calculate on the back of an envelope. (I know quicksort is faster than N^2). You don't even need a google search to look up the details on an algorithm. Knowing when to use what algorithm is far more important.
In other words, it's just like they said in school: Show your work. Tell us how you arrived at your answer. Tell us how confident you are in the answer.
If you do want to practice, open a (non-highlighting) text editor and code something trivial. See if you can get it to compile on the first time. Repeat with other small problems. (This is how we did it in the old days.)
> What are the best prep resources?
Your stories. Passion projects you've completed. Interesting debugging techniques. What you did when the answer was not in the documentation.
Actually, RedBlack trees shouldn't be memorized. You can infer them from scratch, if you really understand motivation behind them. They can be modeled as a way to represent 2-3-4 trees in binary tree form. In this way, it's very easy to implement both inserts and removes.
The biggest issue I see is not being able to be coherent in explaining a tech project or concept. I would practice succint answers to technical questions.
In addition, if you are not comfortable coding in front of someone and explaining as you go, practice it with friends in mock interviews.
The fact you have an interview in the first place is a good sign - your résumé showed that you have the skills they need. A lot of the time, an interview is used to determine if you're a good fit socially. As for whiteboard coding, it's just used to show your thinking. Even if you screw it up, as long as you can explain what your thought process was they won't mind.
Anyways, I find the best thing you can do is research the company, come up with a few good questions, and tell the interviewer how it would be great to work with them. If they hit you with a curveball during the interview code test, you probably wouldn't want to work there anyways.