Hacker News Reader

Comment by the_snooze | Hacker News Reader

>Would it be fair to say that interview processes don't differentiate good hires from bullshit artists?

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

View on HN

This sounds terrifying and like something I'd never, ever put in the tons of time to properly prep for for a single company's process just for a chance at a job, but add it to the list of things I'd much prefer to the current system if it were widespread enough I could prep only for that.

If it’s a topic of your choosing, a lot of engineers who aren’t super junior probably have a lot of the fixins for a short technical talk on something of interest even if they haven’t presented at a conference. And even juniors probably have something from school.

Added: I should acknowledge though that talking about technical topics of interest may get more complicated at some proprietary firms than open source ones.

The first company I worked for out of college did that, as it was a technical position that hired people out of university who studied science and engineering. They had two of us and an interviewer. The other guy gave his presentation on Ruby lasers, but his explanation was a more complex version of "the ruby filters the input light", which is completely incorrect. I tried to hint at that in a question or two, but the interviewer did not have any physics background, and seemed to think it was an informative explanation.

So I'm not sure that this method works if candidates can give talks on subjects the interviewers are unfamiliar with.

It may take me a week (or more) to prepare half hour talk. It takes even more time if I have to compress it into less than 20 minutes (think ted talk).

Actually, that sounds brilliant. The only problem is taking into account those that are not good at public speaking.

Is your company hiring?

If I’m hiring “senior” developers, being comfortable communicating technical topics and answering questions is a requirement.

My definition of “senior” is what you will see in the leveling guidelines of most well known tech companies - not “I codez real gud”.

> If I’m hiring “senior” developers, being comfortable communicating technical topics and answering questions is a requirement.

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.

>The only problem is taking into account those that are not good at public speaking.

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.

Those sound like very good adjustments.

The problem is that interviewers have a strong tendency to judge candidates based on whether they come across as self-confident, even when instructed not to. It's possible to get people to not do this, but it requires fairly rigorous training. tptacek wrote about this a decade ago: https://sockpuppet.org/blog/2015/03/06/the-hiring-post/

I'd argue the "presentation and Q&A" format addresses that directly. The candidate gets to pick exactly what the interview is going to be about, at least at the beginning, so they have full control over first impressions. No gotchas at all. Who wouldn't pick something they're confident about?

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?"

The idea is to pick a topic you're so jazzed about that your enthusiasm overrides The Fear.

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.

Reply on news.ycombinator.com