Comment by akdas | Hacker News Reader

Comment by akdas | Hacker News Reader

Parent Full thread

> Everyone loves to read and write about how developer interviewing is flawed, but no one wants to go out on a limb and make suggestions about how to improve it.

I've spend this year writing about hiring[0], both to talk about the problems and provide suggestions on how to improve the process. My suggestions are sometimes high-level, and sometimes very detailed. Some examples:

- Be specific about the requirements [1]

- Tailor the requirements to the role you're hiring for [2]

- The types of non-technical issues that can cause a candidate to perform poorly, and how interviewers should correct for them [3]

- Let people work independently [4]

But above all, my primary thesis is that it comes down to looking for strengths, not trying to discover weaknesses [5]. Having been on the hiring side, this is the specific suggestion that I believe will have the most impact, especially to those who want to land a job that would have been out of reach otherwise.

[0] https://hiringfor.tech

[1] https://hiringfor.tech/2020/03/02/are-you-asking-candidates-...

[2] https://hiringfor.tech/2020/06/22/hiring-for-the-role.html

[3] https://hiringfor.tech/2020/05/25/letting-the-little-things-...

[4] https://hiringfor.tech/2020/08/03/reducing-interview-stress-...

[5] https://hiringfor.tech/2020/02/10/false-positives-and-false-...

> But above all, my primary thesis is that it comes down to looking for strengths, not trying to discover weaknesses [5].

I strongly agree. I think a generation of software engineers has been trained to calibrate their interviews by looking for reasons not to hire someone, instead of looking for reasons they should.

This perpetuates all sorts of biases in the hiring process, and it insidiously serves as a form of self validation as well.

The problem is that you can find a reason to hire almost anyone. Now most companies just need someone to write boring line-of-business applications so maybe that's okay, but if you're working on anything novel hiring the wrong person can be very expensive. I don't think there's any intrinsic negative in keeping a high bar for hiring.

I think most people vastly overestimate the novelty of what they're working on. Most people writing software at Google actually aren't doing more than gluing APIs together on a day to day basis. In that sense it's much more important for them to have a solid understanding of reliable infrastructure and system design than algorithms and data structures. Indeed, this shows in the way they interview for people who aren't new grads.

Looking for strengths isn't the same as lowering the bar. If you have specific requirements, you will maintain those requirements. But, the goal is to push aside weaknesses that don't matter (such as nerves during an interview, or lack of truly unrelated knowledge).

Instead, the goal should be to ensure _qualified_ candidates can demonstrate the strengths they have in meeting your requirements.

So basically, there are two pieces to looking for strengths:

1. Determine which requirements truly matter. Even for highly technical jobs, interview skills are not what makes a successful employee.

2. Find ways for those who meet the bar to demonstrate that fact.

Reply on news.ycombinator.com