Here's where I think I diverge from most people on this topic. My personal view is that I think by the time you bring someone in for an interview, you should al

Here's where I think I diverge from most people on this topic. My personal view is that I think by the time you bring someone in for an interview, you should already know that they can code, whether that's through code samples they provide or through Github accounts or whatever. TL;DR; Don't waste your applicants time or your own ## The Interview Interviewing should have two parts, imo: * Confirming that I actually wrote the code I sent you and know what it means * Confirming that you want to sit next to me for the next six months I can tell you right now that if I take time off my current job to go sit in your office for an interview and you ask me basic questions like "What is MVC?" or "What's the difference between a POST and a GET request?", I'm going to thank you for your time and walk right out. Why? Because my Github profile, which is featured prominently on my resume, contains examples of both. Half my projects are MVC projects, and many of them use 3rd party APIs (or are even APIs themselves!). The fact that you're asking me basic definitions means you didn't even pay attention to the stuff I sent you, so you're wasting my time and yours. You could have already figured this out ahead of time. Instead, you asked me to take time out of my day (probably during work hours) to ask questions whose answers I've already provided. (Please note that this only really goes for non-entry-level positions. For entry-level applicants, such as kids fresh out of college, you may not have very many code samples to work with. That's fine. In that case, send some problems for them to work on at home. Hopefully, these are dumbed-down but real-world problems your company has faced in the past.) ## Phone Screen (aka verifying authenticity) The first thing you should do is take a gander at my Github profile or my code samples. Then you call me up at a prearranged time and ask me questions about that code. Make me prove that I wrote what I said I wrote. * I noticed you made this combat simulator (www.bitfalls.com/2013/08/autofight-php-job-interview-task-part-1.html). Walk me through your thought process. * Your code appears to be a custom MVC. Why did you choose to go with a custom one versus say, CodeIgniter or Symfony? * This project is an API for Nerd Nite scheduling. First of all, what's Nerd Nite and why did you make an API for it? Second, explain how you scraped the data, organized it, and output the results. The above three questions will give you way more insight into my programming style and thought process than "What is an MVC?". Please. Don't waste my time. As a senior engineer with 7+ years in the field, I shouldn't need to prove the equivalent of my ABCs to you. It should be understood. I personally would also skip the whole "live coding" thing via Stypi or whatever. Waste of time, imo. You've already got code samples and you can ask me as many questions as you want about it. I shouldn't need to write code in front of you to establish my credentials. ## What about people who lie? There are people who lie about their resume and their qualifications, but that's exactly why you should tailor your questions to fit the code samples provided. If I don't get excited about that code and I can't eloquently explain why I did what I did or how it works, then maybe I didn't write it after all. It also gives you an insight as to my personality: I clearly took time out of my day to write this code. Why? What prompted me to write an API for Nerd Nite schedules? The answers to those questions should give you an idea of whether I can actually program or not. Questions like "What is MVC?" can be looked up in a dictionary. Explaining code samples is much more difficult. ## What next? Once you've established that I wrote the code I said I wrote, then Step 1 of The Interviewing process is mostly done. Now you bring me into the office to determine Step 2 -- am I someone you want sitting next to you for 8+ hours a day for the next six months? Do I fit in with company culture? You could give me a problem to solve on the spot, but hopefully it's more of a higher level thing rather than a "write code on a whiteboard" thing. The reason I say this is because at this point you should already have seen my code. You should know by now that I can build a class. The question you need to answer now is: given an arbitrary problem, can I solve it or at least come up with a reasonable thought process? Bonus points if it's relevant to the job. (i.e., if your job never requires you to write binary trees from scratch, don't ask the applicant to do so.) ## Finally Between the phone screen (technical) and in-person interview (personal), you should have a good idea of whether you want me on your team or not. Occasionally for small teams, you may decide that you need to know something about time, creativity, independence, and other similar qualities that you can't really get from code samples. If this is the case, then I suggest doing the contract thing, where you give them an assignment on contract. Once the assignment is finished, you hire them or pay them for the work completed (or hopefully both). I really, really, really despise whiteboard coding. I don't think it's indicative of anything, and I think you will find a lot of false negatives (i.e., rule out good candidates) using the whiteboard method. A few other thoughts: * I should meet my potential future boss at the in-person interview * I should meet at least one of my potential future coworkers * Be respectful of my time. Most interviews take place during work hours, so I've taken time off work -- and probably lied to my boss about where I'm going! -- to meet with you. The least you can do is not waste my time. * Be familiar with my resume and code samples. I took the time to write them, you should take the time to read them. It will answer way more questions about my abilities than a 20 minute quiz on technical terms will. The more informal the in-person interview is, the better. The technical qualifications should already be accepted by the time I walk in the door. At this point, it's a two way street as we figure out whether we want to work together. I'm interviewing you just as much as you are interviewing me. (Note: These are just my opinions about how I interview others. It hasn't failed me yet. On the other hand, almost every job I've ever interviewed for has completely wasted my time on that front.)