Google.GetAJob() 2013

Recently, I had the great fortune of attending Google.GetAJob() at the Google office in Washington, DC during the Tapia Conference (more on that in another blog!). This is a program Google puts on for students that have a minority status in the computing field. I know they hold this events for certain universities, but since my university is so tiny, it’s great they decided to put this on for Tapia Conference attendees.

I did have to fill out a survey and be selected for this workshop. I think checking the box “have done multiple technical interviews and never had an offer” might have tipped the scale. No way to know. Doesn’t matter, I’m just happy to have had the experience.

To sum up in one word: empowering.

I feel like the Googlers there took the power of the technical interview situation and put it back in my hands. All of the sudden, these engineers weren’t these amazing, untouchable computer gods (don’t get me wrong, they are still amazing at what they do), but instead they are just people. In fact, they are women and minorities- many of them who have recently graduated and were in the same exact position I am in now (except I want to go to grad school and put off that amazing Google job for a few more years, but I digress).

Since I got all this great info on the in’s and out’s of the ominous technical interview, I thought I would pass it along to the magical internet land. So, here are some of my notes and thoughts. I realize some of them may seem obvious, but I want to have this all together in one location (for my own future reference!).

How the application process works at Google is as follows:

1. Apply to the job you want.
2. Your resume is reviewed by real human beings, not machines, and then passed along if it is found qualifying.
3. 1^st round of interviews on the phone. There will be probably 2 of these and they will be technical. The coding is usually done in a google doc or something of that ilk.
4. If applying for a Full Time position, 3-5 technical interviews are then done on site. If applying for an internship, there is a host matching process to see if there is a good place for you.
5. A hiring committee then decides whether or not to extend the offer.

The entire process will take ~1-2 months, unless there is a specific time crunch (other offers, etc).

Obviously, this is very Google specific, but I know most of the big tech companies are going to do something at least similar. Facebook, for instance, (I know since I just did a first round of interviews with them) does a phone screen (or conference/campus screen) which is a technical interview. If they like you, they will fly you out to Menlo Park for ~3 interviews onsite.

Another important thing to point out: no matter what position you are applying for, whether it is software engineer or ux researcher, you will have to do technical interviews.

An interesting Google tidbit is they highly encourage their employees to publish their work. This doesn’t apply to all work, but if the research isn’t something they want to hold on to for a while for obvious reasons, they will encourage it to be published.

Resumes. These are what get you the first interview, so they are very important. Since this was a workshop for students, I’m going to be describing what a typical student resume should strive for.

The most important things should be top, front, center. Education (when you are graduating, gpa, name of school), what position type you are looking for (internship versus full time), and languages. For languages, list them including proficiency. The Googler reviewing my resume recommended using the phrases “Proficient in: language list” and “Familiar with: language list”. This keeps is clean and easy to figure out what exactly you know. Also, never include the word “expert” unless you wrote the language yourself because it’s just asking for trouble in your interviews.

Next on the resume should be relevant experience. I originally had projects/experience listed separately from my work experience and my reviewer recommended lumping them all together in one clean section. Sort this list by relevance, not chronology. Remember, anything closer to the top will get noticed first (and possibly be the only thing that gets noticed during the skim). So, if you did something amazing on a project, put that first. Sell yourself.

Another big thing that I heard several times was that Google was sad to see so little in terms of Open Source projects on student resumes. List any projects and especially highlight any open source work. If you have time, maybe go DO an open source project because it will a) make you a more awesome programmer and b) help you get a job. The reason open source is coveted is because employers can easily just go look at any code you have written and see your abilities. They can get a really good feel for how you program without the pressure of an interview.

Do include towards the end of the resume your other great stuff: awards, honors, publications, patents, conferences, presentations, and interests. Google wants to hire interesting people, so if you are doing something interesting in your spare time (do you actually have spare time as a cs student???) then add it.

Key Resume Ideas:

• Sell Yourself
• It’s okay if your resume is more than a single page, as long as your most valuable info is on the front at the top
• Be interesting!

The Technical Interview. I am going to be honest. So far, I have really been terrible at these. I am the sort of person, who when their intelligence is questioned freeze up and look way dumber than one can possibly imagine. I know that this part of the getting hired process is always going to be the hardest thing for me. I have accepted that and can live with it. I just need to get good enough to get through.

Biggest take home message for the technical interview. Know your programming language of choice inside and out. Be good at it. How do you do this outside of your course work? Do your own projects! Make an app, code up a game, or do something you think is fun and interesting. It doesn’t have to ever leave your computer if you don’t want it to, but it’s important to just practice, practice, practice. Remember how I was talking about the whole open source project. Join one of those cool open source communities and start working on their code. It’s a great way to get coding and meet a whole new support group.

Data structures, algorithms, and generally being able to problem solve will also be must haves for the interview process. Big companies will expect you to know the general structure (and be able to code) things like stacks, queues, graphs, hashmaps, trees, etc.

At the end of the day this is what they are really looking at during a technical interview:

• Do you know the language you picked? Can you code?
• Can you analyze a problem and then algorithmically optimize that solution?
  • You don’t have to be optimal at the first go, just get a solution out and then start talking optimization.
  • Does the code you wrote on the board work? Would it compile?
• Before saying you’re done, test your code! Be sure to keep edge cases in mind (it might be a good idea to write these down before you even start coding).

One big thing that I saw today in the mock interviews and have been guilty of myself in the past, is jumping right into coding before mapping out your idea, writing out test cases, and generally clarifying the problem. If the interviewer asks you to define a function, it’s totally okay to ask all the questions you need in order to write the most productively. Today some of the students in my group didn’t know how a stack worked, so they just froze up and freaked out. Ask questions! Is the string you are working with in ASCII or UTF-8? How is the data being stored in that tree? What kind of data are we sorting? And so on… Then draw pictures, write out ideas, outline the solution, write snippets of pseudocode. These things will help when it comes to finally coding up your solution. First, it will help you not get lost in the code. “What was this loop supposed to iterate on, again…?” And it may help when it comes to testing and optimizing too!

One final tech interview tip: listen to the hints your interviewer is giving you. They really do want you to do well! Think of the interview as more of a coding amongst friends situation (yeah, I find that advice a little hard to follow as well).

Doing mock interviews was an excellent experience for me, not because I practiced writing code up on a whiteboard or solving these problems on the fly, but because I got a chance to see just how NOT behind I am in terms of my abilities. I am in a constant state of not believing in myself when it comes to my coding abilities. I dread telling people I’m a senior because then they expect me to be able to code things. But honestly, the students I coded with today were all over the place in terms of their abilities. So maybe I can do this afterall…

That about sums up my notes from today. It was an AMAZING experience. Everything I have heard about Google’s work place seems to be fairly accurate: nice space, cool toys, and great food. Everyone there was extremely nice to me. I definitely recommend if anyone has the opportunity to attend one of these workshops in your neighborhood. If you don’t get the chance, I hope these notes will help you along the way to your own CS career.

Just remember to seek out new opportunities and seize them! Good luck on your endeavors.