I had to sign several NDAs with Google and I am honestly too lazy to check what I can and cannot disclose. In light of that, I'll keep this vague and hopefully avoid getting sued (fingers-crossed).
I still remember being in high school and reading about how amazing it was to work at Google. About how amazing their free cafeterias were, their company gyms, massage chairs, and on-site laundry machines. Not to mention the brightly colored walls and hip decorations, which were a stark contrast to Intel where I interned. Conan O’Brien once compared Intel's offices to a parking garage, and complimented them on their excellent design choice to match the grey trim with the grey walls. When I was in university, and I learned more about the ground breaking projects Google had, the brilliant people they employed, and the amazing resources they provided their engineers, I knew that Google was a company I wanted to work for. What computer science undergraduate didn't dream of working at Google? To work at the same company with brilliant minds like Guido van Rossum, Leonard Kleinrock, and Ken Thompson? But in college, after two phone interviews I was rejected from a summer internship, and turned down for a full time position after another three phone interviews.
But not too long ago I interviewed with Google again. The entire experience, from first e-mail to final phone call stretched from the end of November to the beginning of April. I passed the phone interviews and the on-site interviews, all of which were arduous but not unmanageable.
After finding out I passed the interviews, and Google finished doing my background check, I spent the next two months on an emotional roller-coaster. I spoke to a couple hiring mangers, exchanged many confused and angry emails with friends and colleagues at Google, and had numerous phone calls with my recruiter, whose tone ranged from apologetic to congratulatory. At various times, I was not entirely sure if I was fully rejected, or if the only thing standing between me and a formal job offer was some paper work. Many phone calls with the recruiter (who was very kind and helpful) were required for clarification, but did little to assuage my annoyance as she was not allowed to explain any of the inner workings of the hiring process. As the weeks dragged on I received job offers from two other companies, so I gave the Google recruiter a deadline and the inscrutable bureaucracy missed it with all the grace of a three-legged elephant.
I am not overly found of interviews. They can be difficult and uncomfortable and require me taking time off from my current job, and getting my chain jerked around does nothing to help improve the situation. I was contacted by another Google recruiter two months back, who asked me if I was interested in the exciting new job opportunity she had (I wasn't, my current job is more interesting). The caveat was that I would have to do some more interviews. I was surprised to discover that although working at Google has been my dream job for many years, I turned down this opportunity with no difficulty whatsoever. The time and the trouble involved just didn't seem worth it anymore. While I still believe Google is doing great things, there are also other companies in the industry doing groundbreaking work, many of whom can reach a decision over an applicant in three months or less.
The problem is not the fault of the excellent people that Google employs, but rather the creaking, rambling structure of their hiring process. Why is the whole process so obfuscated? Why are they doing background checks and calling references before they are even close to being ready to make an offer? Why is some arbitrary committee rejecting a candidate at the eleventh hour after everything else has been approved? Why does the rain fall from up-above? How many licks does it take to get to the center of a tootsie pop?
These are questions that us non-Googlers (non-ooglers? nono-oglers?) may never know the answer to. But we can take solace in the fact that the Silicon Valley is a big place with many wonderful opportunities. And hey, I hear Facebook is hiring
(EDIT: see hackernews discussion)
(Because titles with broad, sweeping statements (that may not actually totally reflect the author's opinion) are wonderful at garnering attention... So maybe read all the way through before deciding to lambaste me?)
I work in the Silicon Valley and my team works with people scattered across America, Singapore, Israel, and India. A terrific feat, that without technologies like desktop sharing, VoIP, and IM would be virtually impossible. Many tech companies support and even encourage remote workers these days. And why shouldn't they? It allows the company to hire the best engineers around the world without having to worry about providing a physical space for the engineers to work out of.
But communicating with people that are 12 hours ahead of you is hard. At 9 PM in California, it's 9:30 AM in India. So by the time that 9 PM meeting is done, it's 10 PM (or 1 AM(!) on the east coast), just enough time to talk "off-line" to individual people, wrap up loose ends, and go to sleep. You'll try to share the pain, alternating who has to take the late night meeting, so that everyone only loses one night a week. But things don't always work out according to plan. People are busy or sick, so meetings get moved, and then the management bureaucracy rears it's head and suddenly you're spending two or three nights a week in meetings.
Do you need some help from your co-workers that are abroad? Well I hope you enjoy working till 2 AM to accommodate their schedule. Do make sure to load up on coffee before tomorrow's 9 AM meeting.
And you'll especially love dragging yourself to work for your early morning meeting only to find it's been rescheduled (Hey, it was your fault. Maybe you should have checked your e-mails before you drove to work).
Social life? What's that? Maybe you'll make the mistake of going out with friends and accidentally miss your 8 PM meeting, much to the displeasure of your manager(s).
So now that I've raised your ire and piqued your interest, I can afford to be a little more reasonable. I do in fact work quite a lot, but it is not a 24/7 lifeless schedule. I have no trouble working with people in the midwest or the east coast; the time difference is not so substantial to be a burden. I've on occasion worked from home, or some other remote location and found it to be fairly easy and enjoyable.
This is not my attempt to publicly flame my company or deride my co-workers or managers. I actually like my company and enjoy the people I work with, but like all relationships it often needs work. The idea of remote workers working closely together as a team is relatively new to this world and difficult to pull off. They are plenty of success stories (just look at the open source community), but also many stories more like mine. I do not believe we created this globally distributed team without fully considering it's implication or the strain it would place on the engineers, and now that we're knee deep into it, happiness and normalcy is a long slog away.
TLDR: Long distance relationships are hard work. Make sure you've considered the challenges and set guidelines before you jump feet first into it.
I am very much a "C" style programmer, so exceptions are not something I use, or see on an everyday basis. Despite this, I've always had a love/hate relationship with exceptions, with my emotions depending on the situation I'm in.
In the past few years, I've used OCaml and Python on occasion to do some quick prototyping (and even some not-too-quick prototyping), and I found the languages' support for exceptions to be quite useful. Being able to call library functions without having to continuously check their return values, and instead be able to rely on the called functions to throw an exception when something bad happens, allows me to write much more quickly. Compare this, for example, to OpenCL in C (because C doesn't have exceptions), which I've been exploring recently. Even the most basic of OpenCL programs, to multiply two vectors, requires 50+ lines of boilerplate code, half of which is "if" statements checking to make sure a cl function didn't return -1. When I was writing my first OpenCL program, I was muttering in annoyance with how much boilerplate cruft I had to spew out and dreaming of exceptions. What I wanted, was for the cl functions to throw an exception on error, which would then allow me to have a single generic catch-all exception handler to dump some error messages and gracefully die.
But we shouldn't forget that exceptions have a place outside of simple prototyping also. Some level of terseness is always appreciated, especially when it allows the programmer to focus on the real task at hand, instead of writing an error check for every function call.
The real magic of exception handlers is that they allow the program to unwind the call stack all in one go, without actually having to jump to each and every return address on the stack as it goes. This is quite powerful, allowing the program to immediately handle the exception when it occurs, and removing the need for the programmer to organize her code to pass the error back up the call stack to where it can be processed.
But as Uncle Ben reminded us, with great power comes great responsibility. The power of exception handlers also gives programmers the ability to screw things up in remarkable ways. Because the exception basically forces a jump to the closest exception handler, all the code in between the exception and the handler won't get executed. This may include important bits like free() and close(), or even just simple things like finishing up printing parts of an output message. While the exception handler is *supposed* to handle all those bits, it's not uncommon for them to be forgotten. A common reason for this, is placing the exception handler very far away from where the exception might be thrown.
Which leads me nicely into my next story. I was working on a bug in some Python code last week, where an exception was thrown somewhere within several thousand lines of code and then handled way at the top of the program. The error message printed was "Exception occurred in <wubwubwub> server," making it quite possibly one of the most useless error messages of all time. I spent a good five minutes raging silently at the programming gods before trying to identify a root cause. It's important to remember that the point of exception handlers is to improve our lives not just in the short term, but also for the long term when code needs to be fixed and maintained.
There are of course many other reasons to love or hate exceptions. But these are the ones that strike a particular chord with me because of my limited experiences. I don't believe exceptions are totally bad, it is merely a powerful tool that is far too often misused, much like "goto" (let's not get ourselves muddled in that argument though...). My personal belief is that the power and terseness of exceptions is sufficient enough that it shouldn't be completely eschewed, but simply used sparingly and with great care. The problem with that idea of course, is that software development sits in the real world, not some lovey-dovey happy-place, where there is always plenty of time to work on projects, everyone is properly trained, all code is properly reviewed, and vampires sparkle in the sun.
We all know the career fair drill, you push your way through a mass of humanity to stand in line for a company that you hope will offer you a job. After five or ten minutes of waiting, you finally get to yell at an engineer over the din of hundreds for a few minutes, barely enough time to introduce yourself, get asked a few questions, and maybe even ask a few questions yourself. Hardly enough time to make a lasting impression. I attended a few college career fairs earlier this year while recruiting for my company, and throughout the process I realized that a vast number of students were completely misusing their oppertunities at the fairs.
Now, college career fairs present a fantastic opportunity for students. Whereas applying to a job online simply places your name into a bucket with dozens, if not hundreds, or even thousands of faceless applicants, a career fair allows students to cut through the HR and automated resume screener bullsh*t and immediately talk directly with a real life engineer, thereby allowing the student to show off their skills and express their interests. The importance of this opportunity cannot be overstated.
When I was a student, I had a few companies start scheduling me for interviews on the spot when I impressed their engineers at the fair. Now this isn't my company's style, but for a few people, I've scribbled on the back of their resumes phrases such as, "AWESOME, HIRE HIM NOW," and "AMAZING!!." I can assure you those resumes went to the top of the list.