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.

Well, yeah

[dtm]

I mean sure, it's not rationally called for, especially since it really does seem like they almost hired me. (I was supposed to hear back from them Monday before last, and what I heard at that point was "You did great, but we have one concern, so we're going to give you a last chance second phone interview on the topic you didn't do so great on")

But emotional responses are not by and large rational, so that doesn't really help. What would help is taking some direct action to push myself down one of the other possible paths, since it would give me a new way to engage with this.

[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?"

[dtm]

Well, that's a good point. I think that the main reason to avoid option 1 is that that kind of reaction leads all too easily for me to option 2.

As for what Google has to offer that I don't get here, I'll have to think about that.

What Google has to offer you

[(Anonymous)]

Well, I remember when you were at an employer with really stupid corporate policies.

For instance, the "you must not speak your name" policy, or the "we own all your code" policy.

If your current employer has reasonable policies and treats you reasonably, then indeed you may not gain much of anything by going to Google.

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

[dtm]

Yeah, I've read that article, although actually the article that really explained MapReduce for me was the article linked to from here: http://lambda-the-ultimate.org/node/1669

The thing is, though, I don't by and large need help on the higher-level, academic side of things. Things like higher-order functions or the lambda calculus I'm pretty much OK on. I'm not ready for a computer science research position, but I know more about that than is really needed for where I am and for where I want to be.

My problem is more the little practical bits: knowing, for example, that a disk seek takes on the order of 10**(-2) seconds, and that therefore a solution that ends up involving 10**10 disk seeks just isn't going to work. Knowing how network traffic behaves, and what things are going to cause just awful congestion. Knowing that you can expect hash collisions once you have a number of items that's approximately a square root of the number of hash buckets. Most importantly, knowing that you know all of these concerns and knowing to check for them as you're coming up with a design.