Studying like it's finals week

It has been a few days since my initial kickoff post. Since then I have spent time researching everything I can on the position. Often at this stage I would also be researching the company, but Google hardly needs any introduction and plus I am a big fan and user of many of the products. I learned the developer advocate falls under the larger umbrella of developer relations @ Google. Checkout how Google describes it here: https://developers.google.com/jobs/. The Developer Advocate is a special role because it is so mulch-dimensional. Sometimes the advocate is coding, other times writing, and yet even other times speaking publicly about their technology.

I think the main people who are a part of software development can be broken into three categories:

1) There are people out there who are pure engineers: creating algorithms, maximizing efficiency, eking the most performance possible. 

2) The second group are the software developers, these guys (& gals) are using the frameworks and building the applications on top of the engineers as well as other higher application interfaces. The devs do think about the things the software engineers think about, but they are also concerned with usability, business logic, and overall design. 

3) I think the developer advocates fall into a third category and must be melded from the other two categories, but their role is to foster communications and be the glue to help tie the community together.

The interesting part of how Google sees the developer advocate is they still want them to be very strong in an engineering sense. So to give myself the best possible shot at the technical interview I have been brushing up on my computer science notes from college.

First Major Area: Data Structures

I first focused on common data structures and their uses since this is such a big part of the large web applications that Google develops. The main ones I focused in on are linked lists, Trees, Heaps, Hash Tables, Stacks, Trie, and Graphs. Each data structure has a unique behavior and set of traits. These are the goto tools in the tool belt that software creators can use to build their creations. I found a great website http://bigocheatsheet.com/ for a well presented list of each of these tools and some of the complexity tradeoffs between them.

Next up: Algorithms

Extra Resources:

Scanning the internet I found some related articles referencing their experience in what I am presently going through:

http://www.globalnerdy.com/2013/10/19/i-has-the-dumb-or-how-i-embarrassed-myself-in-my-interview-with-google/

http://alexbowe.com/failing-at-google-interviews/

http://randommarkers.blogspot.com/

First Post -- Woo !

First Contact

It all began when an email popped up in my inbox titled "Google Engineering". As I read on it was from Derrick, a Google Recruiter who happened to run across my profile and was interested if I'd like to try-out for one of the Google engineering teams. First thought... hell yea.

The Screening

After hearing of my technical experience and interest in the position he quickly set a first stage phone interview for a few days later. Perfectly punctual, as if engineered, the phone rang exactly at our scheduled time. We did some minor small chat which then was lead into a multiple choice questionnaire. He asked me a series of topics within computer science and software engineering and had me rate myself from beginner to guru. That then led to multiple choice questions testing if those self-ratings were indeed accurate. One question had be sort timings of various computer I/O devices, whereas another question had me state which data structures guaranteed logarithmic O(log N) performance. Some questions I answered correctly and others not so much.

New Possibilities

One of the great things about Google is that they don't use third party recruiters. Therefore the recruiter has no motive to just stuff you into a position and collect a commission. On the contrary, their job is to find where you can best fit into the company based on their needs. As Derrick and I continued to speak he heard of my interest to help foster developer communities, meet lots of different types of people, and to make software engineer's lives easier. He suggested that I may be a good fit for Google's developer relations group where it bridges the gap between the pure software engineers who are creating new products and services and the other engineers and groups who consume and further develop that software. This is exactly for something that I was looking for! I can code 70% of the day on bunch of different topics and tool sets, and then spend the rest of my time sharing and discussing those technologies. I ended the conversation with Derrick on a positive note and was waiting to hear back from him soon.

Excitement Builds

A few anxious days later I received an email and phone call from another Google Recruiter named Jackie who mentioned based on my teaching experience there were some managers interested in having me try out for the developer advocate role. Side note: I appreciate that Google goes with the label advocate instead of a more religious overtone such as a technology evangelist. First real step in the process is a 45 minute phone interview where they test one's technical chops [remember as in most things in Google it is focused around the Eng.ineering] hopefully if all goes well they either do another phone interview or bring you on-site to do a further hands on interview.

Ready, Set, ...

I have one week (slightly less now!) to prepare for the famous rigors of a Google interview and will document the processes I navigate through, my preparations, and finally the outcomes as I go through this journey.