Furthermore, I believe that by the time you bring someone into your office for an onsite interview, you should have already concluded technical tests. You should have had an initial phone screen, a tech call, and/or a code challenge. The candidate should have passed all of those with flying colors. If not, then you don't bring them into the office.
Once you bring them into your office, your goal should be threefold: quickly validating the results of your technical challenges, determining company fit, and letting them learn about you. If you cannot quickly validate the results of your technical challenges, then you should re-evaluate your tech screens and/or code challenges that you send the candidates before they show up. Maybe you need to do something a la TripleByte's quiz. Maybe you need to ask more rigorous questions during the tech call. Maybe you need to impose constraints on the code challenge.
If you're getting people that don't know the difference between .call() and .apply() or how to use prototypal inheritance, then your top-of-the-funnel filtering techniques aren't doing their job. Re-evaluate the code challenges and tech screens!
The second part of the interview is "do I want to work with this person? Do I want to sit next to them for the next year? How much hand-holding will I have to do and is that amount acceptable? Do they seem trustworthy or particularly experienced in something we need?" This is partly personality, but mostly communication skills, attitude, and professionalism.
The third part is that interviews are a two way street. The candidate is there to interview you just as much as you are there to interview them! Part of your job as the interviewer is not only to assess their qualifications, but to convince them that accepting your potential offer is the best thing they could do. Always, always, always open up with an explanation of who you are and why you're the one interviewing them, as well as how the interview process will work and what you expect from them. Always, always, always leave 10 minutes (or more!) at the end of the session to let them ask questions.
If I walk into your onsite interview, and all you want to do is discover whether I know how to curry or pass functions as arguments or the difference between .apply() and .call(), then you're wasting both of our time. (Not that you don't need to know those things -- but there are easier ways to determine those, and you could do that before I even walk in the door.)
Your time is valuable. Consider how much code you could write in an hour. That's how much code didn't get written because you wanted to ask me, in person, whether I know what "this" means or what closures are. You could have verified that before I even walked in the door.
Instead, you should use your time as an interviewer wisely by asking only questions you cannot verify before they show up. As a candidate, I don't want to waste your time and I don't want my time to be wasted. As an interviewer, I don't want to interview candidates that are unqualified and therefore waste my time and the candidate's time.
Thanks for the feedback. I completely agree that culture fit and giving candidates a chance to learn about the company/position are hugely important to any interview. I could write entire posts about each of those.
I guess I should have been clearer in my description that I was writing strictly about the technical portion of an interview.
That said, my experience has been that it's much more difficult to effectively evaluate a candidate's technical ability based on take-home tests or the like. A phone screen would probably work well too, but since that requires a fair amount of my time, I usually prefer to just meet in person.
Hiring is such an important part of any company, and even more so at a super early-stage startup like the one I work at. So I always try to err on the side of false positives instead of false negatives. I'd rather invite more candidates to interview and maybe have some of them end up being under-qualified than to miss out on a great candidate because I'm making too many assumptions before meeting them.
That said, this stuff isn't an exact science, and I'm certainly not claiming to have discovered the One True Way™. I just wrote about my experience, and the things I tend to look for.
EDIT
It's also worth mentioning that here in Boston, there's a huge shortage of intermediate/senior JS devs. So most of the time, I'm really looking for a junior level person who seems likely to progress quickly. In a market where I was able to get more senior level people in the door, I think my strategy would probably shift pretty significantly.
For me as an interviewee, to have to devote hours of my time doing work for free just to prove that I know how to code, all based on a short phone call, is just as crazy. How do I know your company is one I want to work for? How do I know you're offering the salary and benefits I need? We haven't gotten to that part of the conversation yet and I'm already putting in real hours of work - especially if I have multiple interviewers that ask me to complete code challenges.
It's a catch-22 really. If you have no hurdles, you hire people who don't know what they're doing. If you put too many hurdles, you scare off the folks who don't want to waste hours of their time proving they know the basics. For an interviewer, it's best to get this stuff right up front so you can more effectively screen, but for the interviewee it'd be best that this comes at the end of the process when they know they actually want the job.
All in all, I think this works better for junior level positions because that's where you want to know where folks are at, but hiring senior level people with years of experience, it just gets insulting to have to jump through hoops at every single interview. Of course, I'm a bit burnt out on interviews at the moment, so take that for what it's worth ;)
