Search This Blog

Aloha Google!

I always said, the only way you're going to get me off of this island is if I got a job with Google. Time for me to put my life and career where my mouth is, because...

New Job with Google!

I'm stoked to announce that starting June 1st 2010 I will start a new adventure as a Developer Advocate for Google in Mountain View, California.

It's a very bittersweet moment, as this means I will have to leave my island paradise home. Hawaii has welcomed me with open arms and has grown to be my true home with all my friends and family. I have loved every minute of living here, and I believe that I shall return one day.

However, the real hot spot for emerging web systems, technologies, and companies is the San Francisco Bay Area. Silicon Valley has the momentum, the people, and the energy that can really fuel my passion for building web systems. It's extremely hard to replicate that environment, especially on Hawaii.

I made a very tough and personal decision to explore Bay Area options, as I felt it was time to kick my career up a few notches. I wanted to aim high, and the highest I felt like I could go was working for Google.

Luckily, through Aloha on Rails and my general involvement in the web engineering community, I was able to reach out to current Google employees. I was also fortunate that a friend and ex-coworker recently started at Google. This really helped, as they were able to steer me towards the right position.

My New Title is Developer Advocate

We decided that Developer Advocate would be the best match with my skill set and experience. I didn't even know this position existed, but I'm very glad I was recommended for it. A Developer Advocate is a mix between Teacher and Developer. My main goal is to ensure that other developers are successful with Google products and APIs. This means there is a lot of teaching and instruction, which I am trilled to get into. I've always felt that I would someday focus more on teaching. Well, that someday is now!

The title Developer Advocate itself is very deliberate. I want to make clear this is not an evangelist role. This position's main responsibility is to advocate for the external developer to the product and engineering teams. That is, I am to listen intently to what developers are doing with the products and what they need from the products. I am to take their concerns back to the engineering team, and then ensure the developers that their voice is heard.

Meanwhile, I will be leading classes, teaching workshops, writing demos and tutorials, and generally reaching out to current and potential developers.

Focusing on HTML5 and Chrome

I'm tentatively slated to join the HTML5/Chrome/ChromeOS team. I will be learning an entirely new set of technologies for some very cool, emerging, and strategically important products.

As you can imagine, Google wants everyone to be successful with the Web. And the lingua franca of the Web is HTML, and soon HTML5. HTML5 enables very rich user experiences, and with rich user experiences comes more interesting products and services. And with more interesting products and services comes more changes for Google to sell ad space. So Google is definitely invested in promoting and developing a more rich, and open, World Wide Web. Here I am, thrown right into the middle, and it couldn't be more exciting!

The Interviews Were Lots of Fun

Some quick notes on the interview process, because I've been asked about this a few times.

I had two phone interviews and one on-site interview. Each phone interview was 45 minutes long, and each was conducted by a peer (and engineer and a developer advocate). The first phone call was solidly technical, with questions about SQL and algorithm analysis. There was a bit of coding on paper. The second phone interview was half technical, mostly dealing with scaling web sites, and half mock-teaching. For example, my interviewer asked me to "teach object oriented programming to newbie developers".

My on-site interview consisted of, if I recall, meeting five people each for 45 minutes. The format was the same for all: half technical and half instructional. Everyone I met there was very friendly and helpful.

I loved every second of it! I thought the interviews were more fun than work, and I could have riffed on the questions all day.

Oh, and I was treated to a delicious lunch. Google takes its food very seriously, I'm looking forward to my Google 15.

Start on June 1st, Two Months Vacation in Hawaii

I am taking a few months off to enjoy Hawaii as a tourist and not as a 8-5 work-a-holic. I'll use this time to visit the places I've never been and to bond with the islands. Plus, my parents are coming out at the end of May so I'll be able to hang with them right before I leave.

I'll actually be back on Oahu on September 11, 2010 for a Ruby on Rails class for the Pacific New Media program, part of the University of Hawaii Outreach College. Maybe now I can also teach an HTML5 class for them as well! :)

Where to Live in Bay Area?

Finally, a call for help. I'm a total Bay Area newbie. If anyone can recommend places to live that are family friendly, pedestrian friendly, near good schools and are close to the Googleplex in Mountain View, we'd really appreciate it! Any nudges in the right direction are most welcome.

Mahalo!

So. Stoked.

I cannot wait to start with Google. I believe in their mission, I think they are a great company, and I am most certainly going to have my mind blown. This is a huge step for me and my family, and we are ready for the adventure.

Popular posts from this blog

Now, this has to have a built-in somewhere in Scala , because it just seems too common. So, how to convert an Array to a List in Scala? Why do I need this? I needed to drop to Java for some functionality, which in this case returns an Array. I wanted to get that Array into a List to practice my functional programming skillz. **Update**: I figured out how to convert Arrays to Lists the Scala way. Turns out it's a piece of cake. val myList = List.fromArray(Array("one", "two", "three")) or val myList = Array("one","two","three").elements.toList The call to elements returns an Iterator , and from there you can convert to a List via toList . Nice. Because my first version wasn't actually tail recursive, what follows is a true tail recursive solution, if I were to implement this by hand. The above, built in mechanism is much better, though. object ArrayUtil { def toList[a](array: Array[a]): List[a] = { d

In which I port a snazzy little JavaScript audio web app to Dart , discover a bug, and high-five type annotations. Here's what I learned. [As it says in the header of this blog, I'm a seasoned Dart developer. However, I certainly don't write Dart every day (I wish!). Don't interpret this post as "Hi, I'm new to Dart". Instead, interpret this post as "I'm applying what I've been documenting."] This post analyzes two versions of the same app, both the original (JavaScript) version and the Dart version. The original version is a proxy for any small JavaScript app, there's nothing particularly special about the original version, which is why it made for a good example. This post discusses the differences between the two implementations: file organization, dependencies and modules, shims, classes, type annotations, event handling, calling multiple methods, asynchronous programming, animation, and interop with JavaScript libraries. F

In which the virtues of automated mechanical arboreal pruning are extolled over quaint manual labor, as applied to web development build processes. The setup Ever notice how the primary bit of marketing for many traditional web programming libraries is their download size? Why is that? Check this out: Why does size matter so much for these libraries? Your first instinct is probably, "because the more bytes you shuttle across the wire, the slower the app starts up." Yes, this is true. I'd also say you're wrong. The primary reason that size matters for these libraries is because traditional web development has no intelligent or automated way to prune unused code so you can ship only the code that is used over the wire. The web is full of links, yet web dev has no linker The web development workflow is missing a linking step. A linker's job is to combine distinct project files into a single executable. A smart linker will only incl