Just curious, why do you not allow the interviewee to use jQuery? Do you expect the candidate to know JavaScript's DOM-level APIs without having to look them up?

Hang out on forums, #javascript, etc some time and see how many people have problems because their understanding of the DOM begins and ends with the jQuery API. I see it all the time. I've seen big-name sites bug out or slow to a crawl because some dev wasn't thinking about what was going on behind their $()'s.

The DOM API isn't very large/complicated, and it shouldn't be hard to MOSTLY memorize it. It isn't a "gotcha" question though, a good interviewer is not gonna ding the heck out of you if your forget bits of it (most web devs do spend most of their time with jQuery, YUI, etc after all) - it's about whether you understand what's going on behind the scenes.

I don't mind the need to research DOM-level APIs on the fly. In fact, I'd be just as impressed that they not only know what they need to look up to refresh their memory, but where to look. Where and how they look might say things about them as well.

After all, I often have to look up a rarely used method. Seems unfair to judge harshly if they do so.

Native API are probably easier to learn, just more cumbersome to use :)

That's not really fizzbuzz, that's more the equivalent of asking a C programmer to write fizzbuzz in assembly (perhaps that's a little too strong a comparison, but you get the idea).

Fizzbuzz for websites would be to have someone code two paragraphs side by side with a header and footer in CSS.

If their primary task was to build HTML emails then I could understand that train of thought.

I suppose there are people out there that are working as front-end developers for websites that only work in HTML and CSS, but I would think that's getting more rare as time goes on. Of course, that could just be bias based on my own career.

But, going with your suggestion as a thought exercise, I would go in a different direction. To make a pattern like fizzbuzz I suppose I would do something more like: build a page with a series of paragraphs so that these CSS properties apply to every third paragraph, these CSS properties apply to every fifth paragraph, and so on. Something possible with CSS but requires the ability to think things through.

The point of fizzbuzz is that it is a ridiculously easy test that any programmer that says they "understand" a language should be able to do, because they would touch things like loops and str manipulation in pretty much every program they ever write.

Nobody is going to color code repeating paragraphs in CSS on every project. You wouldn't use that javascript on every project either. (Perhaps these days you would I guess, but I'd argue its overkill for basic websites, to be honest) I can guarantee you're farting around with the box model though, and odds are you could be using a framework to do it for you. Which is precisely why I'd want to test it.

I believe I would say that knowing how to do fizzbuzz for the reasons you describe and knowing how to do what I described is much the same thing within their own area of expertise.

For what I would consider a basic website I'm doing a decent amount of CSS and JS work. But I suppose that could depend upon your definition of a basic website.

Hah. I once asked an intern some random JS question and he used JQuery for everything. So I then asked him what the $ meant. That was a very awkward 5 minutes of silence.

Follow-up question: "Should you?"

Why?

Because there are times that jQuery is not available to you for whatever reason. Most of time the tasks I stated are not really that hard to do in vanilla Javascript, it just can be more verbose as opposed to doing it with jQuery.