This works both ways right? Would it be fair to say that interview processes don't differentiate good hires from bullshit artists? Feels like framing the problem differently might make it tractable.
I had to take company training in interviewing. The trainer started out by acting out a fake interview. Then he asked us how we felt about him as a candidate. Pretty much everyone agreed that he nailed the interview. Then he began to list all the things he said and how he answered questions, and it slowly became clear that it was all bullshit, and he never said anything that was a direct answer to any of the interview questions. By using deflection and redirection he was able to completely control the interview and give a glowing impression of himself.
I wish I could remember what company was hired to do that because it was one of the best corporate training experiences of my life.
Anyone involved in interviewing really needs to ask themselves "what are we testing for?" In my world, we require anyone who makes it to the full in-person interview to give a technical talk on any topic they want, followed by Q&A from an audience that has a broad collective knowledge base. This has the benefits of:
- Letting the candidate start the interview on strong ground of their choosing
- Giving both the candidate and the team a chance to talk shop in a way that simulates the day-to-day work context
- Offering an opportunity for the candidate to gauge how curious and cordial their potential future colleagues are
- Making it very obvious if the candidate is BSing if they can't answer live questions about something they chose to present
Is your company hiring?
My definition of “senior” is what you will see in the leveling guidelines of most well known tech companies - not “I codez real gud”.
While I agree completely, I also know plenty of people who fit this description, but would probably aren't the folks you ask to give a power point on a technical topic.
TBH I've done my time in management and done my fair share of presentations, but I would HATE this to the point that I might well opt out.
There's a reason I'm not in management anymore, and a presentation like described is a far cry from working with stakeholders and engineers to define and document technical requirements. Or even presenting those to a group with shared context.
I might well take the fact that you've made it a part of the interview process to be an indication that this is a regular job requirement as opposed to something I have to do here and there.
A very common concern, but overblown in my experience. If you notice, I never actually said "judge the candidate's presentation skills" (or anything of the sort) in why I think this process is great. The presenation is really just level-setting; the candidate gets to set the topic and give sufficient context for a conversation to occur. The presentation is at most the first 15 minutes out of a ~3 hour in-person interview process. That's how little it matters.
It's the Q&A and subsequent discussions that matter.
If someone thinks Cmake is super cool and knows all sorts of great use cases for it, then they should present that. They should also be prepared to answer open-ended follow-up questions like "broadly speaking, how could a project transition from something like Automake to Cmake?" or "what are some footguns in Cmake and how can we avoid them?"
One of the things I like to do on the hiring side is hold interviews in the smallest room people won't complain about. The way we think about public speaking has a lot to do with how close we are to each other.
Added: I should acknowledge though that talking about technical topics of interest may get more complicated at some proprietary firms than open source ones.
So I'm not sure that this method works if candidates can give talks on subjects the interviewers are unfamiliar with.