Rational response to a professional rejection

[dtm]

So the "interesting news" mentioned in my previous entry is that I was at the time doing the interviewing and recruiting dance with Google. I heard the final word from them yesterday, and they aren't going to offer me a job. I may post some more detail later about the interview process (the non-technical details. The technical details are covered by an NDA), but not tonight. It seems that at this point I have a few choices of how to deal with the upset from being told "you don't have what we need":

• Screw them, screw the recruiter who contacted me out of the blue, screw it all. Throw a temper-tantrum.
  
• Ponder the inadequate nature of me, and get (more) depressed.
  
• Forget it all, and try to just go on like they never talked to me in the first place.
  
• Try to come up with a list of what they didn't like about me, and see if I can figure out how to improve those areas
  
• Same as above, but set as a specific goal re-applying to Google in a year. (Though this time, I'd limit myself to the NYC office, given how jmartin2 greeted the prospect of a move)

Obviously, I'd like to be able to embark on one of those last two options. So what, from Google's point of view, are my weaknesses?

Well, without getting into the details of it, the spot where I fell through on the interviews was in two questions of the form "design a system that hooks up a bunch of commodity PCs to do $TASK". I kept reaching for designs that were amazingly impractical in terms of network usage or other things (again, without going into details, you can't have a batch job that requires 10¹⁰ disk seeks per machine when a disk can only seek at something like 100 seeks per second). So clearly, this needs to improve; the only problem is that I can't figure out how one would go about doing that - practice designing systems really only works if I am able to get good feedback about what is a good design and what isn't. Also, I'd need a steady stream of design problems to chew on first.

There are also some technical areas I could afford to improve on. I need more python experience, which may just be a matter of making myself do it - the problem there is that I find python significantly more cumbersome and annoying than comparable scripting languages, and so am unlikely to use it for fun (I'd rather use ruby), or work (where we use perl). I also need more C++ experience, but I think my job is about to provide me with that as we port a system from ancient pre-ISO C++ to modern machines. I think that perhaps I could also use academically the equivalent of a really good undergraduate software engineering program; I'm not at all sure how to do that, though I'm starting by looking through MIT's opencourseware site.

So, anyone have suggestions on how I go about doing this?

Comments

[space-parasite.livejournal.com]

Do remember that Google will take any conceivable excuse to not hire someone. Unless everyone you interviewed with gave you a perfect score and people who never met you give you a perfect score and a coin toss comes up heads, you're out. So option B is really not at all called for.

[chrysoula.livejournal.com]

Did you really really want it? I mean, what's wrong with option 1? That you'd like to embark on one of the latter two options doesn't seem entirely obvious. For example, an option 6 would be 'why were you so interested in Google-- what were they offering that was so exciting to you. Can you identify that and find it somewhere else?"

[sneakilyalto.livejournal.com]

What chrysoula said. It seems like if you are interested in a job change, Google is not your only option for a cool place to work, and there might be options available to you that are more suited to the (ample) skills you already have. Or, alternatively, you are happy where you are and dont really want to move anyway.

[joxn.livejournal.com]

Do you read Joel on Software? http://www.joelonsoftware.com/items/2006/08/01.html discusses functional programming in order to talk about Google MapReduce, and he provides you with a link to a paper by some Google boffins. That might be a good place to start thinking about how Google likes to design large networks of PCs that do $TASK.

Heck, alternatively, go work for Joel himself.