15 ms·

I want to be interviewed in a manner similar to how almost all other professional job types experience interviews. - The vast majority should be technically pr

by mlthoughts2018 8y ago

I want to be interviewed in a manner similar to how almost all other professional job types experience interviews. - 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. - 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. - 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. - 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. - 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. - 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. 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.

inertiatic 8y ago
This is spot on actually.
framebit 8y ago
The last two points are particularly key. If your company fails to outline the hiring process to the candidate (or maybe your process doesn't even have an outline) and if people regularly get "lost in the shuffle," not only is your hiring practice broken but that's probably an indicator that there are deeper organization problems. A manager that I adored that I had silently chosen not to accept the offer because I didn't show up on my first day. Turns out the recruiter had told me a different start date. And this happened twice more with new people that started, just HR bungling the process and seeming to reinvent it with each new hire.
duxup 8y ago
I really wish those last two were common. Even just a generic rejection email sent out at all... sometimes seems like the most you can expect.
aalhour 8y ago
Thanks you! This is a really good outline. What is your take on system design questions that follow the "How would you design a Twitter-clone" vein? Do you think an open-ended question like that would show the interviewer your communication skills and good software design skills?
- mlthoughts2018 8y ago
  As long as these questions are focused on projects the candidate already worked on before, then yes, they can be good. When they are canned questions, there is at least one small issue and one big issue. The small issue is that people will research and memorize solutions for common questions like “how to make Twitter” or “how to rank a newsfeed” or “how to ensure fault-tolerance in a distributed file system” (yes, the memorization even covers how to respond to questions in a ~45 minute open-ended conversation). If someone looks good on a design question about e.g. a Twitter clone, it doesn’t tell you much. If someone does bad on it, it probably also doesn’t tell you much unless they totally can’t parse the basic concepts (which should have been weeded out way earlier). The bigger problem is “Guessing the Teacher’s Password”[0] and applies even when you ask non-standard questions that someone couldn’t have memorized ahead of time. As the interviewer, especially if you were prepped in some interview training or team meeting, you will have preconceived expectations about what the “right” answers are and what the right progression of concepts, features, and details would be like. As a result, you’ll favor candidates who happen to “guess” your preferred way of looking at the discussion, even though there could be many perfectly valid alternative ways to think about or discuss the problem that approach it differently, with a different sequence of questions or iterative enhancements. At best this introduces some unnecessary arbitrariness into the pool of qualified candidates. At worst, you are unwittingly self-selecting for people who approach problem solving the same way you do, and are therefore reducing diversity of thought. If the big design question is also unrelated to the day to day job, then this arbitrariness is even worse: rejecting or self-selecting entirely based on your preferences about a toy exercise. [0]: < https://www.lesswrong.com/posts/NMoLJuDJEms7Ku9XS/guessing-the-teacher-s-password https://www.lesswrong.com/posts/NMoLJuDJEms7Ku9XS/guessing-t... >

inertiatic 8y ago

This is spot on actually.

framebit 8y ago

The last two points are particularly key. If your company fails to outline the hiring process to the candidate (or maybe your process doesn't even have an outline) and if people regularly get "lost in the shuffle," not only is your hiring practice broken but that's probably an indicator that there are deeper organization problems. A manager that I adored that I had silently chosen not to accept the offer because I didn't show up on my first day. Turns out the recruiter had told me a different start date. And this happened twice more with new people that started, just HR bungling the process and seeming to reinvent it with each new hire.

duxup 8y ago

I really wish those last two were common. Even just a generic rejection email sent out at all... sometimes seems like the most you can expect.

aalhour 8y ago

Thanks you! This is a really good outline. What is your take on system design questions that follow the "How would you design a Twitter-clone" vein? Do you think an open-ended question like that would show the interviewer your communication skills and good software design skills?

mlthoughts2018 8y ago
As long as these questions are focused on projects the candidate already worked on before, then yes, they can be good. When they are canned questions, there is at least one small issue and one big issue. The small issue is that people will research and memorize solutions for common questions like “how to make Twitter” or “how to rank a newsfeed” or “how to ensure fault-tolerance in a distributed file system” (yes, the memorization even covers how to respond to questions in a ~45 minute open-ended conversation). If someone looks good on a design question about e.g. a Twitter clone, it doesn’t tell you much. If someone does bad on it, it probably also doesn’t tell you much unless they totally can’t parse the basic concepts (which should have been weeded out way earlier). The bigger problem is “Guessing the Teacher’s Password”[0] and applies even when you ask non-standard questions that someone couldn’t have memorized ahead of time. As the interviewer, especially if you were prepped in some interview training or team meeting, you will have preconceived expectations about what the “right” answers are and what the right progression of concepts, features, and details would be like. As a result, you’ll favor candidates who happen to “guess” your preferred way of looking at the discussion, even though there could be many perfectly valid alternative ways to think about or discuss the problem that approach it differently, with a different sequence of questions or iterative enhancements. At best this introduces some unnecessary arbitrariness into the pool of qualified candidates. At worst, you are unwittingly self-selecting for people who approach problem solving the same way you do, and are therefore reducing diversity of thought. If the big design question is also unrelated to the day to day job, then this arbitrariness is even worse: rejecting or self-selecting entirely based on your preferences about a toy exercise. [0]: < https://www.lesswrong.com/posts/NMoLJuDJEms7Ku9XS/guessing-the-teacher-s-password https://www.lesswrong.com/posts/NMoLJuDJEms7Ku9XS/guessing-t... >