Not to take away from this post but I wanted to share a little bit about my own job search. Hopefully engineers who regularly interview candidates have some int

Not to take away from this post but I wanted to share a little bit about my own job search. Hopefully engineers who regularly interview candidates have some interesting feedback to share. There was a post I actually just hearted on Secret this morning where someone equated "hard algorithm" questions to "hazing." That may be a little dramatic sounding, but I do think there is some truth to that. So much of the early 2000s tech interviews were full of brain teasers that either through sheer luck of the candidate or someone who read the popular book "How would you move Mt. Fuji?" would ever have a shot at solving them. Microsoft pioneered it apparently and Google took it to the next level. They even went so far as to post them on billboards for anyone "clever" enough to figure them out. At some point they went out of favor and the new favorites became these multi-step dynamic programming questions, or quad-trie/kd-tree disguised problems. The unfortunate truth is, if you want to get a job in the valley beyond your first out of school job, you're going to need to study and refresh your brain on those last chapter algorithms. Make sure to practice doing them recursively as well because with 45-60 min interviews you won't have time to do it iteratively. Just like the OP mentioned too, it also couldn't hurt to practice writing code on paper in front of a friend. The biggest thing I found writing code on a white-board vs. a laptop is that you lose all the things that make coding in an editor so much faster. You can't just erase a line if you need to insert something above it. You need to be extremely thoughtful of your order of operations from line #1. Usually what I found worked for me was writing a checklist of how to solve the problem in English, so as not to confuse the interviewer that I'm writing code/pseudocode. Then I rearrange the steps until I get a solution that works. From there I can quickly write out the actual code that then becomes the easiest part of the interview. So the BIGGEST tip I can add when doing white-board coding, write as polished as you can. Interviewers always seem to proclaim they won't judge your chicken scratch, but I've never been in a feedback session where someone joked "his handwriting was so messy, but I was very impressed." In fact I've always heard the opposite, "wow, they wrote crap all over the place, even though they figured it out it was very unorganized, so I dunno, it's a maaayybe from me." Also, when asked one of these questions, DO NOT take your time trying to be clever upfront. Get the worst case on the board, 1) it will give you and the interviewer a chance to to talk about it and 2) they will want to ask you how to optimize it anyway.