|
Not every approach is bad. As an interviewer myself I find that just talking to the person as a human being and asking them about their current work, previous work, and interests tends to expose nearly everything I need to know. I initially just want to see if the person is likely to be a good fit for the company. This can be triggered by attitude, arrogance, etc. Engineering-wise I can focus on any one thing they bring up and ask them to explain in more depth, this then becomes a dialogue, which is vital I think, because they're interviewing me and my company as much as I am interviewing them. I intentionally don't try to catch them out, in fact the opposite, a candidate at ease is the one that opens up more and will give you more insight into who they are and what they are about than any whiteboard exercise. I'll then talk about the requirements for the role they're applying for and try to see if their knowledge covers what we need. Again, just a dialogue. If that first interview goes well, then I will ask for examples of code they have written, or set them a test to do in their own time if they have nothing of their own to show. Granted that takes some of their time, but it only happens if they're being seriously considered, and importantly (I think) allows them to use their own tools, in their own time, in their own way, this gives them a chance to shine. This might not work at FAANG scale, I dunno, I find the idea of working at any organisation like that a pretty miserable one. But talking to someone in a respectful way, rather than putting them in an uncomfortable situation that bears no resemblance to what their day-to-day would be, shouldn't be hard to scale. Although, I suspect much of these issues come about because of the inadequacies of the interviewers rather than the candidates, they're hiding behind tricks, gotchas, and memory tests, because possibly they don't have the range themselves to extract something meaningful from the candidate in order to rank them. |