This was supposed to be a series on how Google hires folks in the Test / QA side of things. After getting past the step listed below we (my wife and I) decided it would be too disruptive to move to where a Google Engineering office is so I ended the process there. It would have been interesting to go through the entire process for the ego boost of getting a job offer and a trip to Mountain View, but going to the park with the kid seemed like a better use of time than answer syntax questions about Python for 2 hours.

Before I start this post, I should note that Google approached me about starting the hiring process so I’m not sure how you would get the process going without having someone think you would make a good candidate already. I also do not know if this alters the process in any way.

The phone screen is an hour long conversation with an internal technical recruiter. The key word in that title is technical. The person I was speaking with knew his testing philosophies and could code (we were discussing python for awhile) to a degree beyond what you could train an HR person. They hold they gatekeeper role because you have to convince them of your might before you enter into the full process.

Google’s hiring goals right now are all about bodies. Most organizations have a role in mind when they are hiring, but Google takes a different approach in that they only determine which role you might take at the end of the process. And even then they give you a choice of 2 or 3 groups in multiple locations. This was pointed out a couple times. Statistically 30% of the positions will be in Search, 30% in Advertising and the remainder will be in Content and Communication (Gmail, Picassa, Maps, etc.) and given that 4k of the 8k developers work out of Mountain View, the bulk of positions are there as well. That said, Google operates on a project basis with projects lasting 9 – 12 months so if you are not feeling the motivational love in that group there is opportunity to switch groups.

One thing that has always confused me about Google’s test group is it’s titles, or lack thereof. My understanding of the two main ones is now something like

  • Software Engineer in Test – Develop testing tools and have a pretty broad application scope. Harry Robinson, the Model Based Testing guru is one of these.
  • Software Quality Engineer – These are people with great testing skills and a pretty good handle on at least one programming or scripting language. They are also the ones who write the test scripts for products using the tools the Software Engineers in Test produced. Jason Huggins the creator of Selenium is one of these, though I would have guessed he was the former.

There is a pretty fuzzy line between the two though apparently. It all depends on the composition of the group you are with and the testing challenges you are facing.

At this point the recruiter had me give my pitch as to what I would bring to the table and we discussed that clarifying some points, etc. Standard boring stuff. Blah, blah, blah.

Now the recruiter is driving again and we’re reminded that first and foremost Google wants techies that just happen to also test. Using a 0 – 10 scale, he had me rate myself on C, C++, Java, SQL, Perl, Python, Shell, Unix, OS X, win32 (COM, etc), networking, testing web applications, testing client server applications, test automation, version control (Perforce specifically). The sclae they use is pretty well thought out and has some built-in BS detection.

  • 0: no experience
  • 1 – 3: Can read and understand
  • 4 – 6: Can read and understand as well as use it to create something from scratch
  • 7 – 8: Extemely proficient
  • 9: ‘Expert’
  • 10: Industry recognized expert (wrote a book, on the speaker circuit)

As you can see, the rating are going to fit pretty nicely on a bell curve. If you claim to be an 8 or 9 in every subject they know you are trying to con them. Same with a 10 — they already know you are a 10 before asking the question. I’m guessing too that the desired distribution depends on the type of role you are being considered for. As someone in QA, being a expert at producing Java code from scratch is not necessarily the most important skill, but being able to read and understand what the developers have written most certainly is.

From there you move into the ‘calibration’ questions which are designed to help select who will be on the group conducting the technical calls (there are two with the second there to verify the findings of the first). These also give you an insight as to how un-fun the technical interview promises to be.

  • Python – The difference between a list and a tuple? I guessed the right answer, and added ‘one is useful, the other is not’
  • Python – A function with one or more yield statements is used for? Apparently the answer is generator which is part of python I’ve never used before
  • Python – What does xrange do? I’ve always used range, but according to this article it has to do with optimization so it makes sense that you would use it instead of range in the Google context given the size of their data sets
  • Unix – How do you determine the IP address of a machine?
  • Networking – What are the 3 packets used in establishing a TCP/IP connection?
  • Testing – What is code coverage?

As mentioned, the rest of the process is 2 technical interviews (2h each, code to be produced using Google Docs) and if those are deemed acceptable then the candidate is flown to the main Google campus for in person interviews. And then the offer / placement process. All told the average length is 5 – 7 weeks.