Personally I think you would learn more from solving algorithm puzzle problems independently than taking algorithms and analysis courses.

A couple that come to mind are Project Euler [1] and CodeKata [2].

The problem with most courses is that they teach the very basic types of data structures, a couple search algorithms, etc but not enough. They didn't give me the intuition I was looking for.

Alternatively, the most recommended books I've seen for your use case are _Programming Interviews Exposed_ (PIE) [3] and _Cracking the Coding Interview_ [4].

[1]: https://projecteuler.net/

[2]: http://codekata.com/

[3]: https://www.amazon.com/Programming-Interviews-Exposed-Secret...

[4]: https://www.amazon.com/Cracking-Coding-Interview-Programming...

You would span that prep over more than one month if you're still in college. Then if you get to do some other interview later in your career, going over those same materials won't take you as long. so the up-front cost is paid only "once".

>I've always felt that if I can't get through an interview with a little prep and my existing skills, I don't belong.

The problem here is that your existing day-to-day skills are very different from what is being asked at the interview. See every Hacker news discussions about how broken interviews are. The author's job at Amazon is not going to be "how would you find the common ancestor of these 2 nodes in a toy struct Node{ int value; Node* left; Node* right ; }; binary tree"

For the brushup on algorithms and data structures I would add this one, missing from many books: Implement a simple queue based BFS/DFS algorithm on a toy graph (struct Vertex{ T data; std::vector<Vertex*> neighbors; }; use of basic data structures like std::queue and std::unordered_map/set allowed). Being able to code a sssp on an unweighted graph should be a doable objective.

PS: Another resource I enjoy that the author didn't mention : https://www.amazon.com/Programming-Interviews-Exposed-Secret...

There are also a number of books. The most well known is Gayle Laakmann McDowell's Cracking the Coding Interview

http://www.amazon.com/Cracking-Coding-Interview-Programming-...

Gayle also has a number of YouTube videos such as:

https://youtu.be/rEJzOhC5ZtQ

and a web site:

http://www.careercup.com

Others include:

Elements of Programming Interviews: The Insider's Guide by Adnan Aziz

http://www.amazon.com/Elements-Programming-Interviews-Inside...

Programming Interviews Exposed: Secrets to Landing Your Next Job by John Mongan, Noah Kinder, and Eric Giguire

http://www.amazon.com/Programming-Interviews-Exposed-Secrets...

I read Programming Interviews Exposed (http://www.amazon.com/Programming-Interviews-Exposed-Secrets...) - which covers lot of topics that come up during interview.

Through most of my life I always looked at any form of rejection as a form of motivation, and adhered to a sort of "next time, be so damn good they can't ignore you" mindset. I think one can take that too far, to a point where it isn't healthy, but if you channel the emotion the right way it can help you keep moving forward and keep climbing to progressively higher heights.

If you want to take that approach, and say "f%!# it, I'm going to buckle down and work my ass off so I do get the job next time" there are a few concrete steps you can take.

1. Find, read, and do the exercises in two or three of the various popular books on "programming interviews". I'm thinking of books like Cracking the Coding Interview[1], Programming Interviews Exposed[2], Ace the Programming Interview[3], etc.

2. The companies you mentioned are well known for asking lots of detailed questions on fundamental computer sciences concepts. If doing "big o" analysis and talking about algorithms in detail isn't your forte, get a couple of good Algorithms course books and go through them. Personally, I'm a fan of the Robert Sedgwick books[4][5][6][7], and the CLR[8] book is a standard in this area.

3. Look over the many various articles / blogs / etc. written about preparing for Google interviews.

https://www.google.com/search?q=google+interview+preparation

I have never applied to Google myself, so I can't speak to that from first-hand experience, but this Steve Yegge blog post always struck me as being excellent:

http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...

4. Take as many interesting Coursera, EdX, Udemy, etc. courses as you can find time for.

5. Write code any chance you can. Get involved in, or start, an open source project (or two). Volunteer to code for a non-profit / charity or something in your area. Write an app for yourself, to fill a need of your own.

6. Make sure you broaden your horizons and challenge yourself. If you've always written, say, Java or C++ or Ruby code, then make an effort to learn Go, or Erlang or Haskell or Prolog.

All of that said, as I've gotten older, I probably feel a little bit less of the "I'll show you!" thing. I've developed more of a stoic approach, and almost a bit of a zen mindset. There's a lot to be said for a sort of calm, peaceful acceptance of things, even when they are negative. There's a lot more one could say about this, but I don't want to get too philosophical here. I'll just point out that you applied to two... TWO.... companies. Out of like a BILLION possible companies you could work for. Ok, maybe not a billion, but certainly millions, or thousands, depending on where you live and your willingness / ability to travel.

My point is, don't put too much weight on what happened with Google or Amazon. The whole "dream companies" thing is a crock of shit, IMO, looking back on it with hindsight. I've worked for two companies in my career that I once thought of as my "dream" destinations, and neither experience was anything special (neither was bad either), and not worth getting all worked up over.

Final last bits of advice.

1. Read Nietzsche

2. Read Ayn Rand

3. Get drunk

4. Listen to some Queensryche

5. Profit???

[1]: http://www.amazon.com/Cracking-Coding-Interview-Programming-...

[2]: http://www.amazon.com/Programming-Interviews-Exposed-Secrets...

[3]: http://www.amazon.com/Ace-Programming-Interview-Questions-An...

[4]: http://www.amazon.com/Algorithms-Java-Parts-1-4-Pts-1-4/dp/0...

[5]: http://www.amazon.com/Algorithms-Java-Part-Graph-Edition/dp/...

[6]: http://www.amazon.com/Algorithms-Parts-1-4-Fundamentals-Stru...

[7]: http://www.amazon.com/Algorithms-Part-Graph-Edition-Pt-5/dp/...

[8]: http://www.amazon.com/Introduction-Algorithms-Edition-Thomas...

This book was very useful to me: http://www.amazon.com/Programming-Interviews-Exposed-Secrets...

Definitely this!

I'm passionate about becoming a great hacker and I'm regularly trying to improve my skills in both hardware and software hacking (20/80 split at the moment).

My main issue is that I require a lot of structure in terms of the way that I learn, to deal with this I've borrowed "Programming Interview Explained" [ http://www.amazon.com/Programming-Interviews-Exposed-Secrets... ] from a friend. It's a fairly short book but outlines what knowledge would be requisite for getting a job at Microsoft back in the early 2000s.

I'm going through the book and finding out what knowledge areas are currently lacking and supplementing them with books which are considered to be good for that specific subset of computing. E.g. I found out I was terrible at bit manipulation, so I've bought "Hacker's Delight" [ http://www.hackersdelight.org/ ], which is helping in both my software knowledge and hardware knowledge.

I figure that this method of learning will likely take me over a year if I limit the supplementing books to just 1 or 2 at most. After that I can go through it again, covering all of the topics that I thought I knew well enough to make sure my knowledge is all up to scratch.

TL;DR Persistance is key if you want to gain domain knowledge in your field. I'm taking a backwards approach and using a book to define my learning path.