| > It just doesn't feel like this is right. I know the feeling. The author says this is one of their favourite interview questions. I stop to wonder what the others are. When I'm interviewing a candidate, I'm trying to assess really a few things: 1) the capability of the person I'm interviewing to have a technical conversation with another human being; 2) how this person thinks when they are presented with a problem they have to solve; and 3) can this person be trusted with important work? For 1) and 2), coding interviews and the types of artificially constructed and unrealistic scenarios really aren't helpful, in my experience. I care a lot less about the person being able to solve one specific problem I hand them and I care a lot more about the person being able to handle a much more realistic scenario of being hand handed an ill-defined thing and picking it apart. Those conversations are typically much more open-ended; the goal is to hear how the person approaches the problem, what assumptions they make about the problem, and what follow-ups are needed once they realise at least one of their assumptions is wrong. This is a really hard thing to do. For example, I imagine (but do not know) that when a medical practice hires a doctor for a certain role, there is an expectation that they already know how the human body works. For an ER doctor, you might care more about how well that person can prioritise and triage patients based on their initial symptoms. And you might also care about how that person handles an escalation when a patient presents not too awfully but is in fact seriously ill. For a GP, it's probably more important for a practice to care more about healthcare philosophy and patient care approaches rather than the prioritisation thing I mentioned above. I'm spit-balling here, but the point is these two situations are both hiring doctors. You care less about what the person knows because there is a tacit assumption that they know what they need to know; you're not giving the candidate a trial surgery or differential diagnosis (maybe... again I'm not a doctor so I don't actually know what I'm talking about here). If I'm hiring a software engineer or performance engineer, I am trying to figure out how you approach a software design problem or a performance problem. I am not trying to figure out if you can design an async queue in a single-threaded client. This problem doesn't even generalise well to a real situation. It would be like asking a doctor to assume that a patient has no allergies. Item number 3) is "Can this person be trusted with important work?" and this is basically impossible to determine from an interview. It's also impossible to determine from a CV. The only way to find out is to hire them and give them important work. CVs will say that a candidate was responsible for X, Y and Z. They never say what their contribution was, or whether or not that contribution was a group effort or solo. The only way to find out, is to hire. And I've hired candidates that I thought could be trusted and I was wrong. It sucks. You course-correct them and figure out how to get them to a place where they can be trusted. Hiring is hard. It's a massive risk. Interviews only give you a partial picture. When you get a good hire it's such a blessing and reduces my anxiety. When you hire a candidate you thought would be good and turns out to be an absolute pain to manage it causes me many sleepless nights. |
* Give us a presentation about a meaningful amount of work you did at a company (no NDA violations of course) and spend at least an hour talking about what you did, how you did it, what went well and what did not, and then be prepared for questions.
* Actual software development issues that the team sees every day (not hard mode, just normal) submitted as a PR - review it thoroughly.
* Given a running code environment, fix a bug (you have a debugger, full ide, and an hour to look at it) - not so much about the end result as seeing how you work and your process.