The Google interns recruitment process

This is something I've been meaning to talk about for some time now. As I mentioned in a previous post, I'll be interning at Google this summer. I have been recruited by the JavaScript minimizer team for a 3 months internship in Mountain View.

Google is well known for their overly complex recruitment process. I think full times employees have to go through 6-8 interviews before being hire. I've seen detailed description on the web of the process for full timers, but never for interns. The most annoying thing about it was not knowing what is coming next. The recruiters seem to keep you in the dark and the engineers you talk to aren't really aware of the process for interns. So this is the story of how it happened for me.

Before I start, I need to mentioned that I applied twice before being selected. The first time, I got selected for the technicals interview but did not make the cut.

Applying

The first step is obviously applying. You need to do that online here. You are asked for a resume, a motivation letter and a transcript of you grades. This part is pretty standard, but keep in mind that Google receive tons and tons of resume. Yours needs to stand out. One of Google recruiter I talked to told me that he spends around 15 seconds on each resume on the first cut.

One thing they seem to insist on is Linux experience. Most of their developments are on Linux, so you should probably try to put emphasis on your Linux experiences.

Also, the "officials" Google programming languages are C/C++, Java and Python. If you have experience with any of those, make sure they are easy to spot on your resume.

The other thing you need to consider is when to apply. Google's recruitment is painfully slow. If, like me, you have fixed internship period set but your university, you need to apply at least 4-6 months before that period.

First Contact

Now, if you've done things right and, lets admit it, if you're lucky, you'll be contacted by a recruiter. The first time I applied, I had a screening interview where the recruiter asked me a few technical questions and asked me to grade my knowledge of Java, C++, Python, Algorithms and few other things from 1 to 10. The second time around the interviewer just scheduled me two interviews with engineers.

The technicals interviews

You'll have at least two technical interviews over the phone. The content of the interviews varies from interviewer to another, but here's a few tip. Google engineers love algorithms and data structures. Be ready for in depth questions about queues, binary trees, heaps, stacks and every other possible data structure.

You will also get at least one question where you will be require to code. Yes, over the phone. There first time I did it, I had to actually read my code out loud and the interviewer would type it on his end to test it. That's the interview that killed me. I wasn't ready for it and took a lot of time writing everything down before verbalizing the code. I wanted to be sure of giving a correct answer the first time around. That was a mistake. You only get 45 minutes per interviews, so if you spend 30 minutes on a single question, you won't have enough time to finish the interview.

Don't be afraid to discuss your solutions with the interviewer, they are interested to see how you think and how well you can communicate. They'll ofter lead you toward the solution. Also, don't over-think the problem. If there's a simple solution to the problem, give this one first. Sometime it will be enough, sometime the recruiter will ask "How would you optimize that?".

The second time I had to produce code was much better. The engineer shared a Google Doc with me so I could write the code in it. I don't know if it's standard practice now, but it's much easier this way.

I can't really go into details about the interviews because they asked me to keep the content confidential. Anyhow, I don't think knowing the exact questions I was asked would help you, just be ready for anything.

More interviews

After the first two interviews, I did not get any feedback for a couple of weeks. After this period, my recruiter contacted me via emails and scheduled me a third interview. Her email basically said to be ready to answer technical questions and questions regarding my past experience.

Now, you need to understand that interviewing at Google is a very stressful thing. I spent a lot of time reviewing algorithms and data structure for this third interview thinking that if I had made it that far, I really did not want to blow it. It turns out that wasn't really needed.

The interviewer was my future boss. He basically started the interview saying "Somebody probably told you already, but you have pretty much a guaranteed job at Google". Nobody had. I wish they had, it would have save me from a lot of unnecessary stress.

The third and subsequent interviews are, from what I understand, basically just a way of finding a team you'll fit in. You'll be asked questions about you interests and evaluated on things more specific to the team. My interview was mostly Java, JavaScript and compiler questions. The interviewer described the team and left me plenty of time for questions.

I said I was interested by the team and got a job offer within a week.

Getting ready

This is the boring and tedious part of the process. I needed a J-1 visa to work in the United State. This mean plenty of unclear government form to fill in, a background check and various fees to pay to different authorities (Google will reimburse me for those).

Google don't pay for a plane ticket or moving expenses directly, but they give you a very generous relocation package (I mean REALLY generous). The most difficult thing was finding a place to live, but I managed to find something that seems really good on Craigslist.


Last words

This is how it happened for me. I hope this prove useful for future interns and interesting for the rest of you. I'll be starting my internship on May 4 and will keep you posted on what it's like working for the big G.

Auto-completion for IRB

As it turns out, it's really easy to add auto-completion to IRB. Just add the following lines to your ~/.irbrc file.

require 'irb/completion'
ARGV.concat [ "--readline", "--prompt-mode", "simple" ]

I wonder why this is not on by default.

JavaScript: The Good Parts

I recently watch a very interesting Google Tech Talk by Douglas Crockford, an influential JavaScript evangelist and writer. For all of you JavaScript devs out there, I strongly suggest you spare an hour to listen to this really amazing talk.



The talk, JavaScript the good parts is basically an excerpt of the speaker's book.

Although Crockford admits there are problems with JavaScript, even very annoying ones, JavaScript is still a very powerful programming language.

Some of the bad

One of the several shocking example of what 's wrong with JavaScript if the following snippet of code:

return
{
  ok: false
};

Now, consider the very similar code:

return {
  ok: false
};

One could expect that the two snippets would do the same thing. In most traditional language, the position of the curly brackets is simply a mater of personal preference. In JavaScript, it is not.

The fist snippets simply returns without doing anything. This is because JavaScript has the annoying habit of automatically adding semicolons under some circumstances. This is one of them. The second snippet returns a block of code. A simple new line changes completely the execution of the code. Thanks JavaScript...

Some the good

Despite all its faults, JavaScript is just another dynamic languages. So it comes with all the standard dynamic languages goodies like:

• Lambda
• Dynamic Object
• Loose Typing
• Object Literal
• Prototypal Inheritance

Those are the same constructs used by the dynamics languages we all love. Prototypal Inheritance is pretty unique to JavaScript, but Crockford argues that it is as powerful as classical inheritance.

The jist of the talk is that your should go with the grain when working with JavaScript. This mean actually learning the language and take full advantage of it while avoiding the bad parts. JavaScript is a very powerful language to write nice dynamic web applications. It has its faults sure, be there are way to navigate around those.

There's a lot more in the talk, I hope you enjoy it as much as I did!

Test Driven Development: The Benefits

This is the first part of a series of post regarding TDD (Test Driven Development), how it works, why YOU should use it, how to do it and how not to do it.

How I got started

As part of my final year of University, I've started working on a Ruby port an executable specification framework called GreenPepper.

My team and I decided to develop the entire thing while sticking religiously to the TDD methodology. Two months into the project we have over 98% code coverage.

TDD Simply Put

Very simply put, here are the 3 easy steps of TDD.

1. Write a test that fails
   
2. Write code to make it pass
3. Refactor

Those three steps are essential, they must all be done and in that precise order. In a future post, I'll give a more concrete example of how to apply these three steps. But for now, understand that if you're doing TDD, you cannot write code unless a test is failing.

The Benefits

The benefits of TDD are all tied to those three easy steps. The obvious benefits is that by following all those steps, the near entirety of your code is covered by your tests.

Also, by writing the tests first, you're forcing yourself to write code with easy and simple APIs. Lets face it, you're gonna be the one calling your code, might as well make it easy to use.

Another key benefits of writing test is that you are in fact writting an example of how to use your code. In a project where everything is properly tested, if you wish to learn how to use a class, you simply need to locate the tests for this class and you'll have a very complete example.

Now, the biggest advantage of unit testing is easy refactoring. When working of code that is not automatically tested, developpers are understandably frighten of huge refactorings. I myself worked in projects where features were abandon because it was too likely implementing it would break something. If everything is tested, you can change whatever you want without worrying about regressions.

A Real World Example

A testimony to easy refacoring with TDD is my last change to GreenPepper Ruby. We were using the standard Ruby XML library REXML for all our DOM parsing. This turned out to be a bad decision for several reason. REXML is sloooow, poorly documented and the API is simply awful. A much better choice was libxml. We didn't originally go with libxml because the OS X version was broken at the time. Recently the libxml team released the 1.0 version that fixed OS X. I decided it would be a good time to jump ship before the cost of changing library was even greater.

So I went in and change every class that used REXML. GreenPepper uses DOM extensively, so it was a huge change, several class had to be heavilly modified. It took me less than 5 hours to completly replace the parser.

I am 100% confident I did not break anything in the code. Why? Because EVERYTHING is tested and every test still passes!

There is no way in hell I would have dare change that parser if it wasn't for TDD.

The Bottom Line

TDD makes you more confident your software works at any given time. You can refactor without fear, thus creating much better code. If you plan on writing software that will be maintainable, you absolutely need unit testing and the best way to achieve that is thought TDD.

You should do TDD.

The benefits of stateless objects

For my first technical post, I'm gonna talk about a too common bad practice in programming: stateful objects. This is not a simple error only novice programmers do, it's a very common error even amongst professional programmers.

Consider the following example:

class Stateful
   def calculate(x)
       @result = x * 2
   end

   def display
       puts "The value is: " + @result.to_s
   end
end

s = Stateful.new
s.calculate(10)
s.display

In this case, the user of the class needs to call the calculate method before the display method. This implies a knowledge of the inner working of the class by its client. This is bad. If you make the API of your class impossible to misuse, then nobody is going to misuse it. This includes you!

This is a simple example and one might think that the usage of the class is pretty obvious. But in medium size software, there are often hundreds or thousands of these nasty stateful classes. Most of them have no need for a state. This increases the complexity of the code and makes collaboration between developers harder.

A better implementation would be:

class Stateless
   def calculate(x)
       x * 2
   end

   def display(x)
       puts "The value is: " + x.to_s
   end
end

s = Stateless.new
x = s.calculate 10
s.display x

There is now no possibility of misusing this class.

Of course, stateful object have their use too! But you should only add a state to your application when you have to.

It's not rocket science!

Last weekend, I was attending some family function. Somehow (ie. my mom), everybody knew about my very likely internship with Google. Of course, I was flooded by questions about what I'll be working on next summer by my non tech savvy relatives. As always, I failed at the task of explaining what the heck is computer/software engineering all about.

There is a popular saying "It's not rocket science". Because of this saying, probably from the 60's, rocket science is still considered by the proletariat to be the pinnacle of complexity. Yet, I still haven't met a single person who is not aware of the basic working of a rocket. On the other hand, I have met plenty of people who do not understand in the slightest the inner working of a computer. Most of those people use a computer every day.

At the moment, it is not very clear to me why that is. But the question that interest me at the moment is: Is computer science/engineering more complex than rocket science or other professions. I would argue that it is, or at least, that it's way up there.

Computers are design to handle large and complex calculations. They do that by doing simple arithmetic very very fast. The software that solves a particular problem has to be written by engineers. The problems solved by computer software are often too large to be solved otherwise. These problems are often very abstract. During the design and implementation of the software, the engineer has to understand the problem, one that was to difficult to solve manually in the first place. He then needs come up with a solution to solve the problem. Of course, various techniques are used to reduce the complexity of the problem. Those techniques usually consist of splitting the problem in smaller, more understandable, parts. The engineer can then juggle those smaller parts in his mind to find a solution.

So, by this definition, engineers are people who solve problems to complex to be solved by traditional means. The abstract nature of software is, I think, what makes computer more complex to understand than a physical system like a rocket. We can explain or demonstrate some features of a software, we can display the large data center filled with computers used by our software, but we will never be able to explain the inner workings of the software. It is the curse of the computer engineers.

How do you answer those questions during family parties?

Pay twice for the same book

I was recently browsing the O'Reilly online store for ruby books and I came across this great deal.

That's right, the price of the pdf version of the book is only 10$ or 20% cheaper than the printed version. Maybe it's just me, but I don't think the cost of printing a book and shipping it is only 10$.

But before blaming O'Reilly (and several other book publishers) for ripping off their customers, lets consider the actual cost of selling pdfs. First, you need to make the pdf. That's easy. Having worked in the print industry before, I know that all publications are made into pdf before printing. It's the de facto standard of the industry. So O'Reilly already have the pdf of the book because they need it for printing it. Then, you need an online store. Nowadays, all book publishers have one for selling books online. So they already have all the technology in place to bill customers for a product. So all they needed to add was a download pdf feature. I'm pretty sure, most web developers would consider the task trivial. I would and I don't have much experience with web development.

As far as I can see, there's is very little cost in selling books online. This leads me to conclude that the profit margin on pdf is much higher than on the paper version.

But what really ticks me off, is the "Print+PDF" option. For a 30% markup, you get to have the pdf version of the book. Having the pdf of a book if great, because you can search the book and have your entire library on your laptop of iPhone for when you need them. I want pdfs of all my books, period. But 15$! For a book I already paid for! Are you telling me I've got to pay extra for the same thing, just reformatted and all this to no expense to the seller?

So why not give it away freely? A publisher giving away a free pdf with all the books it sells would have a significant competitive advantage over its competitors. I sure would be more incline to buy from him.

Now, lets talk about the elephant in the room: piracy. O'Reilly's pdf are DRM free for now. I haven't been able to find any reference to this on O'Reilly's web site, but most book publishers will add your name and email at the bottom of each page of the ebook. This is no where near as bad as DRMs, but this is still very restrictive. Mostly, it removes your freedom to transfer ownership of the book or to lend the book. In my opinion, this is unacceptable. You bought the book, you own it, you have to do whatever you want with it, including selling it.

I'm fairly certain that any court would grant you that right. But your name is embedded in the book! So if you sell it to someone who distributes it illegally, you're the one the publisher will blame.

The only reason this is considered acceptable, is because most people don't understand the implications of copyright laws. Think about it this way, what if a car dealership was to write your name on every piece of your car and made you sign a contract preventing you from selling your car. Would this be consider acceptable? Of course not! The only difference is you can't make a copy of your car. Well, you could, but not in any practical manner. Copying a file is so trivial, you do it without even thinking about it.

So would removing ALL forms of copy protection to ebooks make them more easy to pirate? Yes. But pirating ebooks is already ridiculously easy, the meager attempts made by the publishers does nothing to prevent the spread of piracy and only ends up restricting their paying customers.

I would argue that the publishing companies would be better of giving away the pdf with the paper version of the book or selling it at a reasonable price. In the long run, better customer service will improve the publisher's reputation. Making me pay extra for something I know is free does nothing to improve my opinion of O'Reilly.

First Post!

Hi folks!

I guess the first thing I should say is welcome to my blog! As the very unimaginative title says, this is the first post of my blog (actually, my first post ever). So basically, my plan is to explain a bit about who I am, where I am from and where I think am going. Read on!

About Me

My name is Simon Mathieu, I was born in Quebec, Canada and still reside there for the moment. French is my native language, but I decided to blog in English for various reasons that I might explain in a future post.

I currently attend University of Sherbrooke as a computer engineering student and loving every moment of it (almost :p). I should graduate next December.

I'll save you the long enumeration of stuff I like and don't like, if you read this blog for long enough, you'll find out about them.

Why start a blog?

I've been thinking of starting my own blog for quite some time and I finally decided to do it. As a programmer, I admire several bloggers who have technical blogs. But in some kind of conspiracy to start me blogging, they all decided to blog about why I should start a blog.

Here's a snippet from Steve Yegge's blog:

This is certainly the most important thing I'll ever say in my blogs: YOU should write blogs.

Also Jeff Attwood said something similar during the talk he gave at CUSEC 2008 and when I attended CUSEC 2009, every speaker there agreed that I should start a blog!

As you can see, with this conspiracy of bloggers directed at me, I was forced to join their ranks in the blogosphere.

Another more serious reason why I started blogging, is to improve my writing skills. If you haven't notice yet, they suck, they always have. Since I consider this a major flaw in my professional training, I would need to come up with another lame excuse not remedy this right away. Now, with the Internet watching, I hope to get some extra pressure to practice.

Another important reason why I want to blog is because I'm starting an open source project. The project is called GreenPepper Ruby and will be discussed thoroughly in future posts. Since I'm learning Ruby for this project, I'll also share my discoveries of cool Ruby hacks and other implementation details with you guys.

What's next?

I spent two days thinking of a good blog name that wasn't taken and failed miserably. So I'm hoping for stoke of creative genius in the next few weeks so I can rename this blog to something better than "Simon's Blog". I'm open to suggestions!

I'll keep try to post often enough about various things like GreenPepper, books I'm reading, editorial comments on news or other blogs and whatever else I feel like writing about.

So thanks for reading et à la prochaine fois!