Comment by akdas | Hacker News Reader

Comment by akdas | Hacker News Reader

> After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better.

This has been my gut feeling for a long time, and in the last year, I finally took the time to write down my thoughts on the topic. Every week since February 2020, I wrote about some aspect of interviewing that could be improved [0], and I now feel confident there are actionable improvements to be made.

Individually, we as interviewers can shift our mindset towards looking for strengths instead of weaknesses, accommodate different backgrounds, acknowledge the best developers are not the best interviewers (both as candidates and interviewers), and put in the extra effort to hone our interview skills. At an organizational level, I'm working on training material that I hope to promote within companies that are interested in improving their hiring process.

Interviewing is thoroughly broken. But I have some ideas to make it better.

[0] https://hiringfor.tech/archive.html

> Individually, we as interviewers can shift our mindset towards looking for strengths instead of weaknesses, accommodate different backgrounds

Virtually each time I've been interviewed myself the attitude was not to find out what my strengths are, but to discover gaps in my knoledge and skills. I think that's the standard in our industry. Sadly, this is exactly the oposite of what companies should be looking for. They need people who can do the job, and knowing some obscure (or even popular) algorithm by hreat or some rarely used programming language feature has nothing to do with it.

> but to discover gaps in my knoledge

I think I've already found one :)

I'm pretty sure an overarching focus on task realism fixes most interviewing woes, including this one.

There's a cultural obsession in this industry with testing things that supposedly correlate (usually poorly) with ability to do the tasks we actually want people to do and not the actual task itself.

I think it's probably rooted in goocargle culting.

> I'm pretty sure an overarching focus on task realism fixes most interviewing woes, including this one.

This can turn out pretty badly too. I was rejected by a company, apparently because I couldn't figure out the solutions to some problems they've been struggling with for years. I tried to guess, but either I didn't have enough context, or simply they didn't like my suggestions. The whole thing was very odd.

That sounds less like a focus on realism and more like a desire for free consulting.

The blog you mentioned has interesting articles. Do you have by chance also something similar but for the person on the other side of the desk? I’d like to sharpen my skills to be interviewed. I’m the developer who never has questions at the end.

Always have questions - interviewing is a two-way street. You want to find out what they value, (what's their quality vs speed tradeoff? etc.), and what sort of things they have problems with (possibly something you could solve to really stand out?)

Those are just the most basic and obvious ones. Maybe hard to think of on the spot, but you can think of others in advance and have them ready.

Thanks! That newsletter does have articles geared toward candidates as well, though a lot fewer.

The topic of what to ask at the end is one I floated around, but I didn't find it to be a priority. In an ideal world, the questions at the end wouldn't be part of the evaluation anyway, so it should be a time for you to ask whatever you want. Unfortunately, I'm sure interviewers do judge based on those questions, so if anyone has insight into what "good" questions are, I'd love to know.

Reply on news.ycombinator.com