Feats of strength! Interview is not over until they pin you. :p

Ok, the best thing I have both implemented and done in interviews is code. Do two things: 1) give them some code from an example app and have them reason through it for you. Don't be afraid to probe or ask clarifying questions. 2) Have them talk through how they would build an example application. Focus on the big picture as well as some nitty details like what certain logic or markup might look like. Have them talk through this with a piece of paper or white board. Throw in some curve balls and see how they react to the changes.

There are other things you could do but honestly I've found this to be the best use of your and their time. You'll get an inside look at their creativity and logical reasoning and they'll be given a chance to show what they know and "geek out".

Last, have fun!!

If you have the time, just talk to them. Make sure they have some understanding of HTML and CSS. But HTML and CSS are the easiest to learn. Don't put down someone for not knowing the exact name for some semantic tag in HTML. If your project needs it, google will solve that problem in minutes. The problem is in Javascript. Make sure they understand OOP and make sure they understand prototypal inheritance. Also, if they can reason in a functional way and can deal with functional patterns, is a big plus.

You could make a test they should code on a white board to watch the reasoning, but do not focus on the details, but on the mindset. A task should be complex enough to test the understanding of the web stack, but simple enough to be doable. Finishing the task should not be the main concern, but the reasoning.

I would have them design an search input field with autocomplete. It looks easy, and if you know what you are doing, it is easy. But there are lots of interesting details one should know, in order to make it work. Things like interacting with the DOM, with an API, with the events... Lots of details in one should be careful about when designing such a thing.

This has value only if you do plan to have apps that use server side logic, but if you plan to build only flashy static websites, you could think of something else, like a drag and drop, a dynamic toolbar, or anything similar. Building any of those components in pure javascript is simple, but lots of people fail to do it.

Another thing you could do, is to have a requirement to have button with an ID that when clicked, will show another form, and there should be another button with the same ID, and have them reuse the ID's shown in the page. To use in real life, it is bad practice, but it shows if the person in front of you can deal with managing such a situation. The problem is not hard. Is just a bit strange. And make sure they understand the need to have private properties on objects and how to make objects with private properties.

I wouldn't put a code snippet in front of the developer and ask him/her to "find the bug" or something like that, it doesn't really tell you much more about the skills of the person than whether he/she knows how to keep cool during an interview.

What I like to do is to have a telephone call with the candidate and inform them of an assessment test on Github, if they agree to that then it's usually very fruitful. I don't know of any HTML/CSS tests, but you could create a repository of your own with some tasks, something like:

• A) Build a 3 column grid layout, where the first column takes half of the width.
• B) In example B, the animation of the button is glitchy, what it the problem?
• C) Refactor the markup of example C, use as semantic elements as possible.

The commits with solutions you get this way will tell you a lot about how they code and their ability to understand tasks etc. Not to mention, you will see how well they handle Git.

With Javascript it's much simpler, as there already are assessment repositories available that you can simply ask the candidate to complete. Here is my favorite:

https://github.com/rmurphey/js-assessment

Depending on the JS skills of the role you are hiring for, you may want to exclude some of these tests as they may be too hard for a junior developer.

On the phone call, ask them for a good time to work on these and mention that it should not take more than a couple of hours or so. Looking at their solutions you will have a good idea about their abilities and after that, having a face-to-face interview can be left with just getting to know each other and talk tech stuff.