RSS 2.0
Journal / Blog
Saturday, May 24, 2008
Getting a Job at Google: A Web Developer Fizzbuzz
Back when the web turned 2.0, AJAX was all the rage, and gas was cheap, a Google recruiter contacted me. We worked through a couple screening interviews - I explained how I was a .NET / ASP.NET / C# developer with some experience with Java and PHP, I described how C# was somewhat similar to Java. Things went great, I moved on to the next step of the process - writing code (a JavaScript widget for Gmail) with a 2 day (weekend) hard deadline. At the time I was wearing JavaScript diapers, but tried the exercise anyways - I'm still convinced the recruiter confused my Java / C# experience with JavaScript. Anyhow...

The Google Web Developer Exercise:

Web Developer Exercise

Attached are three states of a new contacts widget. This widget will be used across Google and may be anywhere on the page. Designers will also use this in mocks for usability tests. Create the HTML, CSS, and JavaScript for the widget as described in the image. Your solution must work in Firefox v1.5+ and IE v6+. Bonus points for a solution that degrades nicely on older browsers.




After my first attempt, I concluded that:
  1. My JavaScript knowledge was embarrassing
  2. Dynamic programming languages like JavaScript using prototypical inheritance were awesome - as a monocultured .NET developer I had sorely been missing out
  3. Framework Web Developers (ASP.NET, Ruby on Rails, and so on) aren't really Web Developers - we depend on a framework (an API) as a crutch, where the law of Leaky Abstractions is very real, and often when it rears it's head we use our golden hammer (our multipurpose language of choice), but there are better tools at hand
  4. Web Developers claiming n years of experience need to at least know JavaScript, CSS, HTML / XHTML, a server-side language, and some XML / XSL - NOT just a single multipurpose language or framework
  5. Innovation can only happen when you become one with the technologies surrounding your realm - for example: Jesse James Garrett probably would not have publicized AJAX had he been an exclusive ASP.NET developer. Diversity is essential for innovation
In retrospect this exercise is brilliant, it's a more complex derivation of a Fizzbuzz exercise, which effectively weeds out the knowledgeable candidates from the n00bs. JavaScript is notorious for being one of the world's most misunderstood language, many developer (and the ASP.NET Framework) still use JavaScript techniques from the old days of Netscape. For example: <a onclick="return false;" ..., or <a href="Javascript: do something;" ... are common DOM Level 0 inline techniques that should be avoided. These techniques have been replaced, but finding developer that use these JavaScript techniques can be hard.

By having a developer complete this exercise you effectively determine that the they understands these concepts:
  • Cross browser compatibilities and work arounds for both JavaScript and CSS - with a preference given to feature detection (object detection) vs browser detection, an understanding of the different event handling models between browsers
  • An understanding of the separation of concerns - JavaScript, markup, and CSS should be separate files, or at least separated within the document
  • Event registration and listening - DOM events, the different browser event models, no inline level 0 event declarations, no pseudo JavaScript protocol inline declarations within markup
  • An understanding of functional languages - closures, namespaces, lambdas, recursion where necessary
  • Node manipulation - creating, swapping, removing elements
  • Knowledge of non-obtrusive JavaScript techniques
  • Importance of modular / compartmentalization of CSS and JavaScript - defensive programming techniques that minimize the risk of interfering with other scripts and elements within the page, part of the non-obtrusive techniques, how to avoid global variables
  • An understanding on how to debug JavaScript from both IE (link) and Firefox (link)
  • JavaScript code conventions - naming conventions, statement conventions
  • CSS naming conventions
  • General DHTML / AJAX techniques - showing and hiding elements
  • A gauge on their attention to details and UI design intuition - what their gut tells them to do when things aren't spelled out
My latest crack at the Google Web Developer Exercise:

You'll have to visit my site (view this blog post outside a RSS reader) to view the code in action.

The code: GoogleExercise.js, GoogleExercise.html, GoogleExercise.css

Today I'm wearing JavaScript training wheels - feel free to comment on the code, I'm always looking for improvements and suggestions. I did take a couple shortcuts on the CSS / UI side of things as I was focusing more on the functionality.

Using one of the AJAX Libraries (like jQuery) we could certainly do this exercise in significantly fewer lines of code.

Today I still think about Getting that job at Google, Yahoo!, Amazon, or Microsoft. How well do you know JavaScript?

Wednesday, May 28, 2008 2:49:33 PM (GMT Standard Time, UTC+00:00)
Pretty good job. Here are some suggestions...

-Use setAttribute instead of this: lineItem.id = ''
-Use removeChild instead of this: innerHTML = ''
-Your loops are slow.
-Using a try/catch in loadDisplayBy() to control logic is not good

I'd love to work for Google. I guess they're opening a new one in Council Bluffs, Iowa, which is an hour away from me. But I just love .NET!
Wednesday, May 28, 2008 4:08:30 PM (GMT Standard Time, UTC+00:00)
@Josh,

You can't leave me on a wild goose chase, I need to some "whys" answered.
Why should / shouldn't I:

> -Use setAttribute instead of this: lineItem.id = ''
I'm giving a preference to DOM Level 0 Traditional techniques, from what I understand setAttribute is from Level 1 of the DOM and less cross browser compatible.

> -Use removeChild instead of this: innerHTML = ''

I need some JavaScript love'n here. :)

I can see why:

> -Using a try/catch in loadDisplayBy() to control logic is not good
I should replace this with object detection.

And yes-yes, my loops are slow. :) Thanks.
Wednesday, May 28, 2008 10:39:59 PM (GMT Standard Time, UTC+00:00)
@Josh

Try visiting the JavaScript loop speed test in Firefox 3, it has surprising results. I guess premature optimization could really be the root of all evil. :)
Thursday, May 29, 2008 7:46:09 PM (GMT Standard Time, UTC+00:00)
You might be right about the setAttribute. However, I wouldnt be surprised if new browsers decide to disregard the Level 0 techniques. It's the same old question: Do you want to support the new age or the archaic age. I think the answer is obvious.

Here's the requested Javascript love'n (given that I interpreted that metaphor correctly)

while(elem.childNodes.length > 0)
elem.removeChild(elem.childNodes[0]);

I could be wrong, but for some reason innerHTML = '' just doesn't seem right to me.
Monday, June 02, 2008 3:15:58 AM (GMT Standard Time, UTC+00:00)
@Josh, thanks for the JavaScript lov'n... Just what I needed. :)

I just finished reading Douglas Crockford's latest book, and have a new laundry list of things to change.

Crockford suggests:
avoid ++ and --, instead use += and -=
use an array of properties to get at the object properties through a for in loop

Name
E-mail
Home page

Comment (Some html is allowed: a@href@title, b, blockquote@cite, i, img@src, strike, u) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Enter the code shown (prevents robots):

Live Comment Preview
Page rendered at Friday, December 05, 2008 1:00:44 PM (GMT Standard Time, UTC+00:00)