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

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?