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...

...and which seem to largely be collected in the book Cracking the Coding Interview [1]. If you can answer all of their sample questions, you should do fine at a Google interview -- once your brain is used to the task of solving small algorithmic problems, it should get easier, even if the precise question they ask isn't in that book.

Easy for me to say, since I find problems like those easy; I cranked through a few dozen of them with only having to really think about a couple.

If you can't answer them all yet...well, now you have something specific to study.

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

So true; the Google, Facebook, Microsoft, Fill in Here puzzle interviews are pretty silly. Rather than splitting people into groups of "good developers" and "bad developers" they can really be split up into these two categories.

1) People who read Cracking the Coding Interview 2) People who haven't heard of this book.

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

Seriously; any competent programmer can crank through the stuff in that book in a week or two and be solid for the types of silly questions they will be asked in those interviews.

Honestly the best interview I ever had was one where I interviewed with a highly technical IT director and it was just very conversational. We spent about two hours of just chatting about the different types of technologies we had been working with and kept diving deeper and deeper into knowledge areas. At the end of it he just says, "Ok, you are obviously a smart guy; I'm going to send you over to see the VP now so you two can discuss salary requirements."

An alternative view on this, which may seem cynical but which I find empowering:

In their best form, these types of questions are a litmus test for whether you have a certain type of background. When they fail it's because they test for skills not required by the job. It's fashionable to complain about this, but it seems to me to be more practical and useful to just get better at answering these sorts of questions. Leveling up from "terrible" to "adequate" at this will take less time than you think, and due to the craigslist penis effect[1] will put you way ahead of the game.

Easy resource to get started: https://www.interviewcake.com/

This book is pretty well regarded: http://www.amazon.com/Cracking-Coding-Interview-Programming-...

Btw, anyone with better starting places for this, please jump in.

[1] http://www.iwillteachyoutoberich.com/blog/the-craigslist-pen...

EDIT: formatting

I've felt the same way for a long time... and the only way to get over it is to practice. Buy a whiteboard and practice at home. Buy some books (e.g. http://www.amazon.com/Introduction-Algorithms-Edition-Thomas... and/or http://www.amazon.com/Cracking-Coding-Interview-Programming-...). You can also subscribe to http://codingforinterviews.com/.

Not exactly an answer to your question, I know. Most startups I know in SF/Bay Area at least do a technical test (either coding or just regular questions) on the spot. It is stressful, but as anything, you can learn how to do it.

thanks a lot for your post. input from active professionals is invaluable to me.

i've actually been working on learning angular for the past few weeks. i've stopped updating my github in that time since i'm just doing basic stuff, but once i finish some more tutorials and documentation i plan on building an angular project to display on my github. are there any particular features that would really catch your eye as someone who hires programmers?

any suggestions regarding the coding interview problem? i see http://www.amazon.com/Cracking-Coding-Interview-Programming-... recommended a lot.

>> you ask me to do something I believe is a waste of time

You can see the proof for yourself when you burn through the following two books within the three months. a) http://www.amazon.com/Elements-Programming-Interviews-Inside... b) http://www.amazon.com/Cracking-Coding-Interview-Programming-...

You need to spend 4hrs+ on weekends though. You will get to talk to candidates already working in the top companies and will be working in a group of 20+ highly motivated and intelligent peers.

1.) Read up on the routine where you're going to be interviewing. If it's a better-known company there will be plenty available.

2.) Work through one of the popular coding interview books [1][2].

3.) Practice off-keyboard things like white-boarding and public speaking. Get up in front of your white board and work through a problem like you're teaching a class on the subject.

I recognize that 1 and 2 might feel like gaming the system a bit - they are, but as long as companies continue to practice contrived interviews targeted preparation will naturally follow.

As stated, you don't lack the ability to perform in general, just within the artificial confines of an interview.

1: http://www.amazon.com/dp/098478280X

2: http://www.amazon.com/dp/1479274836

I am a SQA engineer working on CFD software but eventually want to make the jump to web development. When I am confident enough to start sending my resume out, I planned on buying Cracking the Coding Interview: 150 Programming Questions and Solutions (http://www.amazon.com/dp/098478280X/ref=wl_it_dp_o_pC_nS_ttl... help me prepare for a technical interview.

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

Casually mentioning that your day is full of interviews should help you appear more desirable..

I saw this on Reddit yesterday.

http://www.grokit.ca/spc/computer_science_review/

So, perhaps this can get you started.

I plan on getting a copy of: http://www.amazon.com/Cracking-Coding-Interview-Programming-... too.

I'm a Devbootcamp alumni, now working in a full time position. Just like you, I wanted to continue my learning and get more knowledge on algorithms, data-structures, and other things DevBootcamp doesn't teach you.

I strongly recommend - Algorithms in a nutshell from O'Reilly (http://www.amazon.com/Algorithms-Nutshell-In-OReilly/dp/0596...)

and - Cracking the Coding interview (http://www.amazon.com/Cracking-Coding-Interview-Programming-...)

Those two books are perfectly concise and straight to the point to understand and learn exactly what you feel you are lacking as a self-taught programmer.

The first one will teach you what you have to know, putting everything into work context, making it really easy to understand why and how this or that algorithm is useful.

Cracking the coding interview then offers really good challenges to practice and master those algorithms. And of course, if you are interested in getting a job, will perfectly prepare you for that ;)

I'm in a VERY similar situation. Self taught 23 year old developer with a BS in business/marketing, Front End + Ruby experience, and interviewing for software engineering jobs.

Prior to my first technical interview I spent tons of time studying algorithms and data structures. Looking back I feel that my time would have been better spent selecting several sample questions (such as the ones you included) and solving them on a whiteboard over and over again (and checking and improving them along the way).

For questions check out careercup.com, glassdoor.com, project euler, and the Cracking the Coding Interview book: http://www.amazon.com/Cracking-Coding-Interview-Programming-...

The more practice you have, the faster you will be able to: recognize what type of problem a particular question is, come to an initial solution, and improve upon that solution.

Feel free to reach out to me with any questions! (contact info in my profile)

No sympathy here. "I am a bad developer"... so? At least you have recognition of a problem, now time to improve.

Why the rejetions? Has any company told you what exactly were the reasons for rejection? Ask for a reply from the interviewers and the specific questions. Don't get those questions wrong again.

  I contribute to a plethora of open source projects in a range of languages such as    C++, Perl, Python, and even various Lisp-like languages. 

How about a link to the contributions? Perhaps you can get some better feedback from people looking at those.

  Well my bookshelf is stocked...   ...   I enjoy mathematics. ...   ...   And for all of this I still blunder my way through...   ...   I still draw a blank when asked what the magnitude of complexity is for the guests   function I just wrote. 

Why the blundering? It's not a memorization exercise, it's an exercise in counting and math:

  My input is N, and I loop from 0 to N, hence complexity is O(N).    I loop twice, so complexity is O(2N).    The input is M and N, my function has nested loops, 0 to M, 0 to N,   complexity is O(M * N).      My input is N and I divide and conquer recursively cutting in half...    that's (N/2)/2)/2)/2... lg N! 

I think most good interviewers will be ecstatic if you can reason your algorithm out loud, even if you're a little off. It's the reasoning and thinking that matters more.

I'd also recommend studying for interviews seriously. Cracking the code interview, http://www.amazon.com/Cracking-Coding-Interview-Programming-..., it helps quite a bit.

I found this to be pretty helpful: http://www.amazon.com/Cracking-Coding-Interview-Programming-...

If you have enough time I would highly recommend reading "Cracking the Coding Interview" by Gayle Laakmann McDowell [1]. She does a very good job covering all aspects of the interview process and the problems and solutions will most definitely help you improve your algorithm and data structure skills.

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

Isn't there a book dedicated to coding interviews?

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