Hiring at an "Insane" Pace

Google wants to grow. Some would call the growth plan aggressive, others call it insane. I prefer to think of it as ambitious. While the exact numbers are sometimes tough to come by, you can get some approximate numbers on many websites. Take for example, the numbers here. If these numbers are to be believed, Google grew at a rate of 100% per year for the past two years. For a company with several thousand employees, this is pretty good. The growth rates show Google passing Microsoft by 2010. Of course, it's very unlikely that the growth rates can be sustained. But we want them to be.

First, it's clear that we could hit these goals in the short term. We get many, many, many resumes a day. In fact, if we hired everyone that applied, we could probably double in one day. Is this a good idea? Probably not. Clearly, many of the applicants would not be qualified, meaning we would not necessarily get much production from many of the hires. Worse, many of the hires may not be "Googley". I personally believe that this is the most dangerous hire to make.

This deserves more attention, because I haven't seen enough focus placed on this in any other company. Anyone who does not fit the culture of their group, office, or company is very damaging. For example, when I interview someone, the only attribute of a candidate that essentially guarantees an unfavourable review (from me) is arrogance. Don't get me wrong - some people are absolute superstars and they should be confident and proud. But Google is full of smart people, many whom were at the top of their class and were suffocating in school or in other work environments. I don't care who you are, you're applying for a company that employs Vint Cerf. This guarantees one thing - no matter who you are, you will no longer be the smartest person in your company. This is a good thing! This is (or should be) why you want to be here.

Google offers lots of benefits. Everyone's seen the cafeterias, the massage chairs, the gyms, the prestigious visitors, the big monitors... whatever you consider a benefit - Google probably offers it free. But this is not why people want to work for Google. They want to work there because some of the greatest minds in the world are there. People at Google solve interesting problems in interesting ways, because some very smart people are bouncing ideas off even smarter people. If you were in the top 1% of your class, this is probably the exact environment you've been dying for all these years.

Okay, enough of that... Back to the matter at hand. How can you possibly sustain this growth rate (intelligently):

1) Don't lower your standards. Google has lots of smart people now and these people love working with/for other smart people. It's extremely valuable to know that (nearly) every line of code you will come in contact with was written by someone you can trust. There's nothing more frustrating than struggling with code, or a person, or a group that you don't think you can trust. This means you need to believe that everyone in the company knows how to identify, formulate, and solve problems intelligently.

2) Get a lot of referrals. Referrals are (and have always been) the best source of potential candidates. It's often the case that good, smart people know other good, smart people. They may be former classmates, co-workers, friends, anything. There are clear advantages to these people. For one, they probably come with positive comments and information, before you even interview them. Second, they have some attachment to the company, however small, through their referrer. Third, they often consider referrals flattering. I think lots of people would be happier having a company that wants to woo them, as opposed to having to seek out companies to sell themselves to.

3) Get a lot of resumes. No matter how many people you have, they aren't connected to everyone. Always allow people to apply directly and be diligent about finding the best resumes as they arrive. This bring us to...

4) Filter aggressively. This may seem cruel, but is very important. Interviewing a candidate is very expensive. A phone interview is not as expensive, but still requires anywhere from 30 minutes to 2 hours for someone to prepare for the interview, conduct it, and write feedback. It's frustrating (and sometimes even depressing) for an employee to interview candidate after candidate that is clearly not qualified. This means you want to get to the point where most (or ideally all) candidates that you contact have some reasonable chance of succeeding. This is important because it reduces the strain that the hiring process places on existing employees. Perhaps even more important is that it reduces the negative impact on unsuccessful hires. This brings us to...

5) Try to make the process pleasant. Not everyone is going to get hired. This is a fact at any company. And in a company with a very selective interview process like Google, most people will not get hired. Or at least, they will not get hired on their first try. Not getting hired sucks. You can find many blog posts on the web about people who were mad about not getting hired. They blame the interviewer, the company, the weather, anything. This reflects badly on the company and fosters an unpleasant image of the company's hiring process. There are two important scenarios here: 1. If someone does not get hired (but nearly did), you want them to want to try again. Make sure they enjoy their process, get them excited about working for your company, and encourage them to try again. In a commitee-based hiring process (like many companies, including Google, use), if you nearly get hired this time, you may get hired next time. Companies strive for consistency in the process (and this is especially true of Google), but the process is never precise enough to always make the right call on cases which are not clear-cut. The process should always work for the superstars (the top, say 20-30% of your hires) and the definite not-hires, but in a competitive hiring environment (like Google's) the other 70-80% of the current employees are probably "borderline hires". By this, I mean, for example, that if they went through the same type of interview process 10 times, at least one or two of those times, they would not pass. If this represents the majority of your current employees, it will likely also make up the majority of your future employees. Protect this resource! 2. If someone does not get hired because they are clearly unqualified, you want them to enjoy their process but accept that this is not the job for them. There are many smart people, who simply apply for the wrong job. We want them to enjoy the process (even if they didn't do that well) and understand that it's not that they're not smart, but simply that this is not the job for them. Keep them in good spirits and thinking positive about your company and how you treated them. They might have friends that are a perfect fit and you don't want to lose them.

6) Hire everywhere. This is obvious, but is key. If you can set up offices all over do it. If not, travel everywhere to find the best people. Seek them out and bring them in. This subject doesn't get me as passionate as (5) though, so let's leave it there.

I spent the most time talking about point (5) and there's a good reason for this. This is the one thing companies seem to worry the least about. Lots of people leave their interview unhappy. And when they don't get hired, they carry around a grudge. Your company does not want people carrying grudges around. The tech sector is large, but the clique of top people in the tech sector is small. Part of staying on good terms with these cliques is keeping everybody as happy as possible, whether things go well or badly for them.

If you take nothing else away from this, take this one thing that I now firmly believe is essential to growing quickly and effectively: be good to both the hires and the passes.

Review of "The Tipping Point"

Finished reading Malcolm Gladwell's "The Tipping Point". This is quite an interesting book, but I can't say there were too many new insights here.

The basic idea here is pretty simple: small things (or several small things) can lead to epidemics. He gives many examples including crime waves, diseases, fashion, TV shows, etc. He uses this to motivate word-of-mouth marketing. This comes down to the Mavens (well-informed, early adopters, trusted by others for advice), Connectors (who communicate effortlessly with others in many different walks of life - experts in "weak relationships"), and Salesmen (who can sell anything to anyone anytime). To simplify all his arguments: win favour with the Mavens; facilitate communication with the connectors; wait for the salesmen to make you rich.

The book is worth a read, but don't expect any answers. Yes, everyone wants word-of-mouth (or "viral") marketing. Everyone wants their new website to be the next YouTube. But I'm telling you right now, it won't happen. Or it probably won't. You want to be in the 0.001% and so do I. Right now, we're not. And we might as well get used to it.

Everything the author says about how products "tip" (i.e., go from relative unknowns to huge money makers) is believable; however, as the book says, you can't force this process. Any attempt at viral marketing comes off as phony. So although you want this, and in a sense you need it; if you're thinking about trying to make this happen, you should probably forget it. Know that many, many people have failed before you. Think hard about all the issues that can come from this and make sure you avoid them.

There's so much to say on this topic that I will certainly come back to it later. For now, let's just say that mastering viral marketing is like finding the holy grail, and your chances of achieving it are about as slim.

Google Beyond Waterloo

As Google grows, it helps to get out and visit new people and new offices around the world. Travel is a small part of my job, but I'm always up for it. In the last couple of months, I was in London (England) for one week and California for another. There's nothing like drinking pints of English beer in a real British pub. And visiting California (at +20c) during a Waterloo winter (at -20c) is not too bad either. The plan is to visit as many Google offices as I can find excuses for. Next stop: New York. Or Montreal. Or Hong Kong. Or Sydney, Australia. Or Sao Paulo. Or Bangalore . Or Dublin. Or Munich. Or Istanbul. Or wherever Google opened a new office this week.

Launching a Mobile Client

We launched the Gmail for Mobile app in the UK, France, Italy, Germany, and Spain this week. This is a really difficult thing to do. Of course there's a lot of work in getting all the strings translated and making sure everything shows up nicely, but this is only the start.

Carriers in different countries have different devices, data plans, network restrictions, gateways, etc. It's never clear whether or not the application will run in any of the countries where you want to launch. The way things are now, the only way to know for sure is either (1) know someone in the country who has a phone and/or can buy one or (2) fly someone there. Seems crazy, but this is the only real way to know for sure.

And what if it doesn't work? How do you fix it? You could fly a developer there which is bad because (1) it's expensive (2) it's often not clear that the problem can ever be fixed (3) developers don't like having to fly all over all the time to fix very specific bugs - they like fixing more general problems or implementing cool new features. Debugging remotely is (needless to say) a nightmare. So, no matter what you do, it won't be pleasant.

I guess this is part of why mobile applications are so slow to gain popularity around the globe. Most are only popular in certain countries and are unheard of everywhere else. If it's a hassle for a company like Google, with all our resources, I can't imagine what it must be like for all the little startups.

Laptop Magazine - Editor's Choice Award for Gmail for Mobile

One of the projects I work on at Google is the Gmail for Mobile client for cell phones. It was released back on Nov. 2, 2006 and has received lots of press since then. In February's edition of Laptop Magazine, it was given the Editor's Choice award, which is nice. I think our most common compliments have been on the usability and Gmail-y feel of the app. The most common complaint is: "It's missing feature X", where X is one of many, many possible features. Some X's can be implemented on many phones, some on a few phones, and some on about one phone. Hopefully as phones become more and more capable, all these X's will be at least technically feasible. Then it will just be a matter of finding the time to get all these things working. Which is, of course, a much harder problem.

User Agent Switcher

If you do any mobile development, you should definitely get to know the User Agent Switcher add-on for Firefox. What does it do?

Well, when a browser sends a request for a webpage, it includes a string describing some information about who is sending the request (e.g., the browser name, version, etc.). Mobile browsers (well, most of them) send information about the device make, model, MIDP version, etc. Websites can use this information to decide what page to serve up (if any).

The User Agent Switcher add-on allows you to pretend that the request is coming from any device. This means you can see exactly what page would be served up if that device visited the website. How does it do this? By spoofing the user agent, of course. For example, if you want to see what a website would display if you hit it with a Nokia 6230i, you can have the User Agent Switcher send the following user agent: Nokia6230i/2.0 (03.23) Profile/MIDP-2.0 Configuration/CLDC-1.1

I won't go into details about how to use it - it's pretty simple. But, it can be extremely useful for debugging websites, especially those that only have issues on certain devices. There are lots of other nice tricks you can play with the User Agent Switcher to test and debug problems. I'll go into more details in a later post.

Verification Errors With Blackberry Applications

If you've worked on applications for the Blackberry and you're unlucky (like me), you may have tried to run your application on the simulator or a device and seen an error message something like this:

"Error starting MyApp: Module 'MyApp' has verification error 2778 at offset 3fce"

It appears that the two numbers (2778 and 3fce, in this case) are not helpful in diagnosing the problem. Basically, you're on your own. And it's going to get ugly.

According to RIM, it's likely that the COD files have been corrupted. Unfortunately, this can happen just by building with the rapc compiler, and optionally signing the app. So, what can you do? Well, I've fought with this a few times and I can at least give you some suggestions to try:

1) If you started by building a JAR and then used the rapc compiler to create COD files, make sure you turn obfuscation off when building the JAR. The rapc compiler will do its own obfuscating and it often has issues if the code is already obfuscated.

2) Comment out dead code. Sometimes the verification errors seem to have something to do with the size of the main code file and the library files. If you comment out some code that never gets called, the file sizes change somewhat, and this often fixes the problem.

3) Remove references to a static instance variable from an inner class. For example, code like the following can sometimes be a problem:

public class MyOuterClass {
static int var;

class MyInnerClass {
  public void doSomething() {
    var = 7;
  }
}
}

There are a few ways you can try to remove these references. E.g., create get/set methods for var in the outer class, or modify your logic so you can pull MyInnerClass out of MyOuterClass.

4) Remove any System.out.* calls. These generally do nothing on the Blackberry, but sometimes cause verification errors.

5) Remove unused import statements.

6) Explicitly specify the access for every function or variable (i.e., make sure every one is specified as public, private, or protected). It's pretty easy to grep your Java code to find the missing access specifications.

Now, it's not clear to me whether these changes actually fix anything. However, you're really just stabbing in the dark with verification errors, so any changes you can think to make may help. My best advice is to use source control and build/test often. You're really just trying to avoid code that makes the compiler unhappy. And it's much easier to do this if 15 lines of code have been checked in since it last worked, as opposed to 1000.