Web Development Interview Questions And Answers

This question can give you an idea of how in-tune they are with the latest industry trends and technologies, as well as how passionate they are about web development. It will help separate the people who do it as a career AS WELL as a hobby from those who might simply be in it for the big developer paychecks.

Although their resume may state that they are an HTML expert, often times many developers ca not actually write an HTML document from top to bottom. They rely on an external publisher or have to constantly flip back to a reference manual. Any developer worth a damn should at least be able to write a simple HTML document without relying on external resources. A possible exercise is to draw up a fake website and ask them to write the HTML for it. Keep it simple and just make sure they have the basics down - watch for mistakes like forgetting the tags or serious misuse of certain elements. If they write something like: , it might be a good hint to wrap things up and call the next interviewee.

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.

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.

This is an important question to ask depending on the work environment. If your project is going to require close interaction with other developers it's very handy to have someone who has had that kind of experience. On the other hand, many developers thrive while going solo. Try to find a developer that fits your needs.

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.

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.

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 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.

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 out what inspires them. While it doesn't necessarily "take one to know one," a great developer should always have a few impressive favorites.

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.

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.

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.

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.

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.

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).

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.

AJAX (Asynchronous JavaScript and XML) is a newly coined term for two powerful browser features that have been around for years, but were overlooked by many web developers until recently when applications such as Gmail, Google Suggest, and Google Maps hit the streets.

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

AJAX stands for Asynchronous JavaScript and XML.
Asynchronous JavaScript and XML, or Ajax (pronounced "Aye-Jacks"), is a web development technique for creating interactive web applications using a combination of: XHTML (or HTML) and CSS for marking up and styling information. (XML is commonly used, although any format will work, including preformatted HTML, plain text, JSON and even EBML).

The Document Object Model manipulated through JavaScript to dynamically display and interact with the information presented. The XMLHttpRequest object to exchange data asynchronously with the web server. In some Ajax frameworks and in some situations, an IFrame object is used instead of the XMLHttpRequest object to exchange data with the web server. Like DHTML, LAMP, or SPA, Ajax is not a technology in itself, but a term that refers to the use of a group of technologies together. In fact, derivative/composite technologies based substantially upon Ajax, such as AFLAX, are already appearing.
Ajax applications are mostly executed on the user's computer; they can perform a number of tasks without their performance being limited by the network.

HTML_AJAX hasn't had a stable release yet and the pear installer doesn't install non stable packages by default unless you specify a version.

Good question. They don't call it AJAX for nothing! A synchronous request would block in page event processing and I don't see many use cases where a synchronous request is preferable.

Once all the major features are complete and the API has been tested, the roadmap gives an idea of whats left to be done.