Hacker News Reader

Comment by fractionalhare | Hacker News Reader

> 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.

View on HN

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