There are some good questions, on there, but as you say, a lot of them read like "Front End Developer Trivial Pursuit".
For example, bad questions:
* How is responsive design different from adaptive design? - there's no formal definition of either. While it might prompt a discussion, it will probably just make the interviewee feel nervous, when you should be trying to get them to relax.
* Why is it called a Ternary expression, what does the word "Ternary" indicate? That's an etymology question. It might be interesting, but it gives no indication as to whether the person is a good developer or not.
* Explain how this works in JavaScript If you can do that effectively, you should probably be presenting and writing books on JavaScript.
Good questions are about opening up a conversation with the person. Why do they want to be a front end developer in your company? What would they be like to work with? Are they looking to specialise in a particular area of front end development, do design + coding, or front end with back end?
* If you could master one technology this year, what would it be? - I read that question last time I saw this link, and have used it a couple of times. It's nice because it tells you where someone wants to be. Think about how you'd react to answers like PHP, NodeCopter or SVG.
* What excites or interests you about coding? - it's open ended. If the interview can only say "I dunno", that tells you they're either not very communicative or not very interested in front end development.
* What tools do you use to test your code's performance? - I have worked with fantastic front end developers who were able to twist CSS and JS into doing anything, but the performance of their code was awful. They opened it in a browser, if it worked, they signed it off and left it for somebody else to speed it up. Depending on the role, that might be perfect, or you might be looking for the exact opposite. Either way, it's a good way of having that conversation with a prospective developer about what their opinion is.
"If you can do that effectively, you should probably be presenting and writing books on JavaScript."
If I hire someone as an experienced frontend dev, I want them to be able to explain how stuff works to other people - especially to non-frontend developers, and junior developers. I want them to be able to train others up. So yes, I want them to be able to present on JavaScript. If their answer to the question tells me they're good enough at explaining things that they could write a book on the subject? Fantastic! Put that in plus column.
>Depending on the role, that might be perfect, or you might be looking for the exact opposite.
I'd be really interested in learning if the amount of technical debt that we don't ever have to pay off is rising (because product lifetimes are shorter, performance is going up, and libraries reduce the total code you write).
For example, bad questions:
* How is responsive design different from adaptive design? - there's no formal definition of either. While it might prompt a discussion, it will probably just make the interviewee feel nervous, when you should be trying to get them to relax.
* Why is it called a Ternary expression, what does the word "Ternary" indicate? That's an etymology question. It might be interesting, but it gives no indication as to whether the person is a good developer or not.
* Explain how this works in JavaScript If you can do that effectively, you should probably be presenting and writing books on JavaScript.
Good questions are about opening up a conversation with the person. Why do they want to be a front end developer in your company? What would they be like to work with? Are they looking to specialise in a particular area of front end development, do design + coding, or front end with back end?
* If you could master one technology this year, what would it be? - I read that question last time I saw this link, and have used it a couple of times. It's nice because it tells you where someone wants to be. Think about how you'd react to answers like PHP, NodeCopter or SVG.
* What excites or interests you about coding? - it's open ended. If the interview can only say "I dunno", that tells you they're either not very communicative or not very interested in front end development.
* What tools do you use to test your code's performance? - I have worked with fantastic front end developers who were able to twist CSS and JS into doing anything, but the performance of their code was awful. They opened it in a browser, if it worked, they signed it off and left it for somebody else to speed it up. Depending on the role, that might be perfect, or you might be looking for the exact opposite. Either way, it's a good way of having that conversation with a prospective developer about what their opinion is.