I somewhat disagree with the premise of this post. I don't think someone walking in and being able to code at whatever level I'm expecting them to do is impressive. That's exactly what you should expect them to do before they even walk through the door! If they can't do these things, you shouldn't even be talking to them at all!<p>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.<p>Once you bring them into your office, your goal should be threefold: quickly validating the results of your technical challenges, determining company fit, and <i>letting them learn about you</i>. 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.<p>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!<p>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.<p>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.<p>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.)<p>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.<p>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.