| > I've never worked at a company that hasn't wanted to improve their interview process. My point isn't that fixing the process is easy. It's clearly not. And I absolutely sympathize with the issues of hiring. My point is that improving peoples' interview skills doesn't make them better employees, or make qualified candidates easier to find, since it's not a skill that is unique to only people who are actually qualified for the position. Just as qualified people will seem better, so will unqualified people learn how to seem qualified. It's applying a fix that does nothing but: (1) reduce signal to noise, and/or (2) satisfy the "gut feelings" of interviewers on what a good candidate look like. If companies are goading applicants to improve interview skills, all else being equal, assuming this actually leads to increased job offers for the candidates, it means companies are filtering too hard for unimportant "interview skills". -----
EDIT > EDIT: my personal favorite is when the candidate has a system they've worked on in the past that they can explain in detail and describe challenges and solutions for... but... the pool of people who can do that has been even smaller than the pool of people who can at-least-pseudocode their way through some mild live problem solving and design questions. This lightly touches on part of what I mean. Companies frequently test for things outside of what they intend to. Its not possible to completely avoid, but, based on my own interviewing experience, it's doesn't seem like much work goes into adjusting for it. Just breaking down this example, I'll explain what I think you are looking for, and what you end up asking for. Intentionally testing for: - experience working with a complex system - able to identify issues in a complex system - able to figure out solutions to said problem - able to identify tradeoffs to said problem - able to communicate the problem, solution, and tradeoffs Unintentionally testing for: - ability to recall, on short notice, details of a complex system from (likely) months ago, including it's tradeoffs and outcomes, without resources on hand. - the ability to recall challenges and learnings from (likely) months after they've been experienced and absorbed. (This is a big one for me, personally) - knowing how complex is complex enough. An applicant may think bringing up a system they do not consider to be particularly complex may hinder their chances by not meeting expectations. Every point from the unintentional section is something that could completely prevent someone from coming across as a good candidate, but have no bearing on how well they can actually do their work. |
Systems often work well for months and don't need touching, then have an incident, or need a new change, etc. You can remember that stuff fairly quickly? Perfect. You can't? I think that's a potential flag, directly related to "able to identify issues in a complex system" and "able to figure out solutions to said problem."
But the other reason why not many candidates do well on that is because there's also just a lot of companies where the day to day work is not-complex problems on not-complex systems (even (especially?) at FAANG where the typical dev is a very tiny piece of the machine). So in that case we have to fall back to made-up approximations for "complex" problems that don't require a ton of extra context.