Vital Web Developers Interview Preparation Guide

Download PDF

Don't be too quick to dump your plugin or applet based portions of your application. While AJAX and DHTML can do drag and drop and other advanced user interfaces there still limitations especially when it comes to browser support. Plugins and applets have been around for a while and have been able to make AJAX like requests for years. Applets provide a great set of UI components and APIs that provide developers literally anything.
Many people disregard applets or plugins because there is a startup time to initialize the plugin and there is no guarantee that the needed version of a plugin of JVM is installed. Plugins and applets may not be as capable of manipulating the page DOM. If you are in a uniform environment or can depend on a specific JVM or plugin version being available (such as in a corporate environment) a plugin or applet solution is great.
One thing to consider is a mix of AJAX and applets or plugins. Flickr uses a combination of AJAX interactions/DHTML for labeling pictures and user interaction and a plugin for manipulating photos and photo sets to provide a great user experience. If you design your server-side components well they can talk to both types of clients.

Prototype focuses on AJAX interactions including a JavaScript AJAX object that contains a few objects to do basic tasks such as make a request, update a portion of a document, insert content into a document, and update a portion of a document periodically. Prototype JavaScript library contains a set of JavaScript objects for representing AJAX requests and contains utility functions for accessing in page components and DOM manipulations. Script.aculo.us and Rico are built on top of Prototype and provide UI effects, support for drag and drop, and include common JavaScript centric widgets. If you are just looking to support AJAX interactions and a few basic tasks Prototype is great. If you are looking for UI effects Rico and Script.aculo.us are good options.
* Yahoo UI Library is a utility library and set of widgets using the APIs to support rich clients. The utility library includes support for cross-browser AJAX interactions, animation, DOM scripting support, drag and drop, and cross browser event support. The Yahoo UI Library is well documnented and contains many examples.

We don't have a list right now, but most of the API is stable as of 0.3.0. There should be no major changes at this point, though there will be lots of new additions.

We don't know yet. Because this is a relatively new approach, our understanding of where Ajax can best be applied is still in its infancy. Sometimes the traditional web application model is the most appropriate solution to a problem.

Proxied calls are made through stub objects that mimic your PHP classes on the JavaScript side in AJAX. E.g., the helloworld class from the Hello World example.
Proxyless calls are made using utility JavaScript functions like HTML_AJAX.replace() and HTML_AJAX.append() in AJAX.

The oldest PHP version we've fully tested HTML_AJAX is 4.3.11, but it should run on 4.2.0 without any problems. (Testing reports from PHP versions older then 4.3.11 would be appreciated.)

It offers a non-blocking way for JavaScript to communicate back to the web server to update only part of the web page.

The W3C Document Object Model (DOM) is defined by the W3C as the following: The Document Object Model is a platform- and language-neutral interface.

An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary - an Ajax engine - between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.

Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine - written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user's behalf. The Ajax engine allows the user's interaction with the application to happen asynchronously - independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something.

Almost all developers have personal web projects they like to plug away at in their spare time. This is another question that can help differentiate the passionate developers from the clock-punchers. It's also a good question to end an interview with, as it's usually easy (and fun) for them to answer.

There is a right answer to this question: all of them. A competent developer should be familiar with testing cross-browser compatibility by using all the major web browsers. Obviously they'll have a primary browser they use for surfing, but their answer to this question might be a good way for you to segue to asking how extensively they test cross-browser issues. Also, if it's some kind of css/html position seeing what toolbars they have installed can be a good metric of their skillset (I personally find the web developer toolbar for firefox to be invaluable)

Some might argue that knowing what acronyms actually stand for is trivial, but there are certain acronyms that a developer should have hard-wired into their head ( HTML or CSS, for example). This is the kind of question that might be better reserved for the phone interview to weed out those who are very unqualified.

I've often felt that the more I learn, the less I feel like I know. Solving one mystery opens up ten others. Having the interviewee tell you their faults can reveal a lot about what they know.

Asking about feature additions is a particularly valuable question - it can reveal if they're skilled in programming in general or if their skillset is pigeonholed into their language of choice.

This is a great question to determine how well rounded their abilities are. It tests everything from basic support skills all the way up to troubleshooting the web server itself.

Give them some broken code written in the development language they are expected to know for the position. Have them go through it line by line and point out all the mistakes.

Find out what inspires them. While it doesn't necessarily "take one to know one," a great developer should always have a few impressive favorites.

Whether it's plain old HTML or freakishly advanced ruby on rails, ask for code samples. Source code can say more about a persons work habits than you think. Clean, elegant code can often be indicative of a methodical, capable developer. A resume may say 7+ years of perl experience, but that could mean 7 years of bad, unreadable perl. Also, make sure you ask for a lot of source code, not just a few isolated functions or pieces of HTML. Anyone can clean up 20-30 lines of code for an interview, you want to see the whole shebang. Don't ask for a full, functional app, but make sure it's enough that you can tell it's really what their code is like.

Find a developer that has experience similar in size to the project you're putting together. Developers with high traffic, large scale site expertise may offer skills that smaller-sized developers don't, such as fine tuning apache or optimizing heavily hit SQL queries. On the other hand, developers who typically build smaller sites may have an eye for things that large scale developers don't, such as offering a greater level of visual creativity.

A portfolio can say a lot about a developer. Do they have an eye for aesthetics? Are they more creatively or logically oriented? The most important thing is to look for is solid, extensive, COMPLETED projects. A half dozen mockups and/or hacked-out scripts is a sign of inexperience or incompetence.

Find out if their future interests match the direction of the position (or the company in general).

See how well they work without their precious GUI. Ask some basic questions like how they would recursively copy a directory from one place to another, or how you'd make a file only readable by the owner. Find out what OSs they have experience with.

If they say notepad you've obviously got the wrong person for the job. Not only can this help you gauge their level of competence, but it'll also see if they match the tools everyone else uses in-house.

Weed out the old-school table-driven design junkies! Find a developer who uses HTML elements for what they were actually intended. Also, many developers will say they can go table-less, but when actually building sites they still use tables out of habit and/or convenience. Possibly draw up a quick navigation menu or article and have them write the markup for it. To be tricky, you could draw up tabular data - give them bonus points if they point out that a table should be used in that scenario :)

Standards compliance in web development is where everything is (hopefully?) going. Don't ask them to recite the w3c's mission statement or anything, but they should at least have a general idea of who they are.