People often ask me for advice about how to get a job at Google, especially research mathematicians. This post is basically the common parts from my emails on the topic, for better discoverability.
This often breaks down into one of two questions:
Would I be happy working as a software engineer at (a place like) Google?
What should I do to get ready for the interview?
Some of this was from a discussion with William Stein, who used it in a nice and related blog post.
My main piece of advice to potential Google applicants is “start writing as much code as you can, right now.” The main goal here is to find out whether you'd actually enjoy working for a company like Google, where a large chunk of your job is coding in front of a screen. I've had several friends from math discover (the hard way) that they don't really enjoy full-time programming (any more than they enjoy full-time teaching?), but only once they were 6 months into a job.
Part of this is really a question about your own personality: if you're the type of person that finds engrossing new problems everywhere you look, then industry may well be a lot of fun. On the other hand, if you've got an area of research that you love, and you can't imagine working on anything else, academia is the place to be … unless that area of research happens to be ad click prediction, in which case you can pick either. :P
Start throwing things on github now. Potential interviewers are going to check out your github profile; having some cool stuff at the top is great, but seeing a regular stream of commits is also a useful signal.
I liken the interview process at the top companies as much like applying to grad school: it's quite hard to say “I'm going to go to this school,” because there's just too much randomness in the process. Instead, you should apply to at least 3 good companies, and have a fallback or two.
If someone has no real experience in any language, I generally say “start with Java.” Some people will tell you it's a boring language, but it's used lots of places, and as they say, “no one ever got fired for choosing Java.” Plus, Java is a lot snazzier than it used to be.
So there's lots of good advice out there – I think Steve Yegge's post (from which I stole the title here) gives a great overview. I'll give a few pieces of advice that he doesn't highlight:
During the interview, think out loud as much as possible. Honestly, the interviewers are much more interested in how you work on the problem than what you end up coding. This is sometimes hard to do (especially without feeling a little self-conscious when you're stuck), but it's well worth it.
Between now and the interview, spend as much time as you can coding. I know this sounds obvious, but it's easy to lose track of, especially if you're busy with your current job. All the stuff you read online will tell you that you need to know every algorithms book backwards and forwards; the most complicated data structure I used in my interview was a linked list. It's good to have a bunch of that in your head, but it's more important to make it clear that you're comfortable actually coding. Multiple folks I've referred got tripped up by this.
If you've never done a software interview before, try to get some friends to do mock interviews. This will be good for thinking out loud, but also to get you in the habit of writing code at a board. It's not something many people do often, especially in these days of omnipresent computing … I've written more code via cellphone than whiteboard in the last year, I think.