Making any kind of loose assumption like that just shows that the interviewer is trying to cut intellectual corners. I've worked on enterprise applications where we simply wrote our own JS that eventually turned into our own framework. Likewise, I've used frameworks for dinky one-off one-page sites.

The reason there's a toolbox is because the hammer won't work for everything. Same goes for JS and the frameworks available.

I think it's important to show that you've worked with particular frameworks because it might be deeply embedded to their project or application. I don't think it should be an interview killer that I've worked with Mootools and jQuery but not Prototype. It can't possibly be that hard to learn another.

Besides, do you really want to work for a boss and/or company who has such a closed off mentality like that? It's very likely that's not the only assumption you'll run into.

My experience has been that it is definitely a good thing from the perspective of talking with potential clients to have some experience in a popular JS framework, but not necessarily the one they are looking for. On larger scale projects, someone has probably already made the decision to go with one framework over another and if someone already has experience in that framework, that could be an advantage. I do think also if you have experience in one, picking up another one should not be a big deal.

We typically ask about frame works for various reasons, one of those is that is shows knowledge of the industry. However it also allows the developer to say why they don't use frameworks, which means it's a bit of a, "there is no correct answer" question.

As for the large vs small project, I would say that a frame work was more use for a small to mid sized project. Once you get very big you really need to write your own, or at least customise something heavily.

I think this can be a valid question if the answer involves a wide variety of mainstream framework. Not just prototype or mootools, I mean some of the more complex UI frameworks like Ext, JQuery-UI, ZK, etc.

For instance, I use prototype.js for nearly every project regardless if it's an enterprise app or a single-file test case. I do this because it's familiar, and dead simple to figure out (I remember picking it up in a matter of hours). But I've since come to realize that something like prototype isn't so much a "framework" as it is just a really good set of coding practices to apply to any JS project.

And on the other hand, it took me weeks to get Ext 2.0 up and going. And I think we can all agree that it's capabilities justify it's complex nature. And there in lies the true nature of the interviewer's question. Having experience with these UI-oriented frameworks can show that the interviewee's experience includes more than just animating DOM elements.

To sum it up in one phrase:
Going through the brain damage of learning Ext showed me the real difference between a "website" and an "RIA."

But I do agree that in most case it's the smaller projects that benefit from a packaged framework, whereas the bigger endeavors more than often utilize a proprietary framework or heavily modified framework.

The framework debate is pretty controversial.

In my opinion fameworks allow developers to communicate ideas becuase you have a defined set of prinicpals that you are both familiar with. I can ping you and ask do you remember how that thinga majiga in JQuery worked?

So in my opinion you certainly need to know how the most commonly used frameworks are used and implemented. I'm not saying you have to go through every single framework with a fine tooth comb but at least understand which part fits where even if you have never implemented it on a project...

On the other hand depending on a framework to work on a large application really paints you into a corner sometimes. Even if you do use the framework. Eventually you are going to start re-writing parts of it or all of it for that matter.

I have this debate with flash and flex developers too... We're all in the same boat here...

I think this is definitely a valid question, one that I have asked myself. The goal is ultimately to judge an applicant's knowledge of the current state of the industry. If you tell me your JS knowledge is 10 out of 10, then give me a blank stare when I ask about frameworks, then chances are you aren't keeping current. If you're not using a framework, you should at least be aware of them and be able to give a coherent reason why you choose not too.

As for suitability to a project size, I think frameworks are valid for any sized project. Obviously, if you've already written your own there's no need to try and force something in. However, even if a framework isn't going to suit every need you'll have, they give you a great jumping off point (as an example, I have used the Yahoo!UI framework, and found that while the UI components didn't fully satisfy my needs, the classes were very easy to extend).

As a someone who manages a 12 person team I ask that question all the time. The question is intended to see how aware a developer is of the state of his/her industry. Frameworks have come a long way anyone who hasn't at least invested the time to learn one or two isn't investing in their own future.

I want to thank everyone for their comments. It has been a good discussion.

It seems knowledge of and some experience with a framework is good for the interview. It shows awareness of current coding practices. And, while it is alright not to use frameworks, you should be able to explain why.

There is greater difference in opinion on where Javascript frameworks fit into projects and how much benefit they provide.