I've been on a lot of interviews and the predominant tactic is to ask a pre-determined set of questions that the company/interviewers think you should be able t

I've been on a lot of interviews and the predominant tactic is to ask a pre-determined set of questions that the company/interviewers think you should be able to answer even if the questions aren't in a domain you listed as a skill or something you have knowledge in on your resume/CV. I, on the other hand, try to tailor the interview and questions to what the candidate has stated they know or what they are proficient in to determine if they truly are knowledgable in areas they say they are. I'll also ask questions tailored to the publicly available job description since, by applying to the job, you implicitly said "Yeah, I can do that", but put less weight on these questions if it doesn't match up with their stated skills and knowledge (so I'm kinda just probing; you'd be surprised at what some candidates know, but don't put on their resume/CV). The prescreen should basically mean, if you pass this prescreen you are eligible for this job, but we still have to validate that what you said about yourself in the prescreen and resume/CV are true. So for example I'll usually ask questions about object oriented design patterns. When I ask someone how many design patterns they know and to list them and they give me three (and Singleton and Factory are 2 of them) that's totally fine. I would've only been able to give around 3 a couple years ago before I studied hard for interviews. But if their resume says something like "Strong object oriented design skills" and they can only give me 3 design patterns, then that's a mark against them because if you claim to be strong in object oriented design I would expect you to know more than the standard rube (like me) that can only rattle off 3 or 4. If their resume talks about doing distributed systems I'll ask questions about distributed systems: what's good design, what are common pitfalls, ways to avoid or mitigate those pitfalls, etc. C# is your number one language, then how are parameters passed to methods in C#? What does it mean that C# is a managed language? What sorts of things aren't managed for you in C#? As much as possible I try to include a question about how they used a skill or knowledge in a real-world application disregarding whether the end result was good or bad. Then discuss why effort ended up good or why it was bad and how they would've done it differently given hindsight. If the pre-screen didn't cover it then give them a programming problem to make sure you weed out the candidates that can't FizzBuzz their way out of a wet paper bag. But don't make the programming problem the entire focus of the interview. I'm currently scheduled for a Google interview which is going to be 5 hours of non-stop programming puzzles that you have to solve while the interviewer is looking over your shoulder critiquing everything you do and expects you to figure out the "trick", code it perfectly, and do this while simultaneously explaining everything that you are doing. Plus the problems they come up are purposely designed to be tricky and sometimes even confusing. The funny thing is I bet any of those engineers would crumble under the pressure and ambiguity I have to work with right now every day and yet they'll be judging me on how I deal with tricky problems under pressure. You can see I'm not a fan of the traditional coding interview. TLDR: Tailor the interview to the candidate's purported strengths. Ask for real world experiences and discuss the positives and negatives of the experiences. Probe for knowledge and skills stated as required on the job description, but don't put as much weight in them if the candidate doesn't list them as a strength. Check for basic coding capability, but don't make that the focus.