I want to be interviewed in a manner similar to how almost all other professional job types experience interviews.<p>- The vast majority should be technically probing conversation that digs into the specifics of my expertise and work project history. No whiteboards, no live coding, no take-home tests. Just technical conversation.<p>- The interview should weight my ability to speak clearly about my technical expertise and work history highest by far. This should be weighted drastically more highly than performance on coding tests.<p>- Code tests should offer the candidate whatever combination of tools they feel most comfortable with, in terms of editor, mouse/trackball, language of choice, access to basic documentation.<p>- Code tests should mostly be about talking with the interviewer. They should involve no “gotcha” trickery to see a shortcut. Getting the naive, slow time complexity, memory-hungry solution with a clean writeup should count as a fully complete solution, not scored any lower than a solution from someone who happened to memorize a dynamic programming trick, etc. The basic fact of being observed in an interview means that if you observe someone only able to complete the naive solution, it does not tell you anything at all. In a non-interview setting, they might easily work out an advanced solution. Or, if someone overfitted their knowledge to memorize these types of interview solutions, in a real work setting they might not generalize to ambiguous, unsolved problems. Observing anything other than the basic solution truly cannot tell you anything useful. It’s sheer hubris to believe otherwise.<p>- The entire interview process, expectations, and precise timeline should be explained to the candidate at the start. Each interviewer should clearly explain who they are and how to contact them later if needed. And each interviewer should have knowledge about the candidate, their work history, etc., and place a higher value on learning more about those items than hurrying up to ask their favorite trivia questions.<p>- Rejections should always be sent out in a very timely manner after the interview. It should include meaningful feedback about all relevant factors that went into the decision, and should offer the candidate a genuinely sincere option to provide feedback. Even if the candidate feels hurt, bitter or angry at the decision, you should thank them sincerely for taking time to help you by pointing out ways your process might have been unfair or suboptimal.<p>One way to sum all this up is to say interviews should be humane. Use common sense about being humane to this person. Additionally, if you believe detailed code trivia or tests gives you better quality info about a candidate than technically probing their experience and skills in conversation, you are wrong, and this mistake will totally corrupt your hiring process.