5 ms·

I call this distinction red flag versus green flag interviews. The typical hiring process is looking to quickly disqualify all but 1 person in the hundreds of r

by ipnon 6y ago

I call this distinction red flag versus green flag interviews. The typical hiring process is looking to quickly disqualify all but 1 person in the hundreds of resumes submitted to any open software engineering position. The hiring process you are proposing is looking to methodically search for all of the useful qualities in the candidate pool and determine how they can best be applied at the company. I think we can all agree someone can be a poor software engineer and not have any red flags.

tsumnia 6y ago
> I think we can all agree someone can be a poor software engineer and not have any red flags. This has been something I find myself musing over every now and then for a couple years now. As we begin to relax barriers of entry, how do we maintain that some people fail/lose?
- ipnon 6y ago
  In a business, you are either don't hire them in the beginning or fire them in the end. Not everyone should be a software engineer (where would the users come from?). A large labor market organizes people into better jobs when they are passed over for or fired from a position.
  - tchaffee 6y ago
    > (where would the users come from?) I'm an engineer and I use loads of software. I bet you do too.
- tchaffee 6y ago
  I'm curious what makes you think we are relaxing barriers to entry? The senior engineers I've hired are highly productive. And diverse. My process does not have a low barrier to entry. The goal is to use more accurate signals. Instead of hiring people who are good at talking about algorithms at a white board I want to hire good software engineers. > some people fail / lose This comes off as a condescending way of thinking about the hiring process. Even if the candidate is not qualified for the position I want to leave them feeling like I helped them a little in their career or at the very least in their interviewing skills and confidence. You can find a good fit for a role without leaving the other candidates feeling like they failed. And I think that starts to get to the crux of the problem at some companies : the process is meant to boost the ego of the interviewer. Almost every senior dev has a few stories about how the interviewer just wanted to feel superior. We can do far better than that.
tchaffee 6y ago
That's a useful mental model. It took me a while to reply because I was trying to get enough clarity on why my process works to put it into words. I use red flags in my hiring process. There are many when it comes to whether or not someone is a good engineer. Inability to do algorithms on a whiteboard is not one of them. I do try to prove my red flags wrong which is what sometimes reveals a diamond in the rough. > The hiring process you are proposing is looking to methodically search for all of the useful qualities in the candidate pool and determine how they can best be applied at the company. That's not necessarily what I'm proposing. I often need find the first qualified candidate who can start contributing. Don't let perfect be the enemy of good. One of the ways I accomplish cost effective hiring is to go through applications in the order they arrive and the first candidate who passes the interview gets the job. If I get 200 applications and I find a suitable candidate in the 1st interview, why would I waste my time and money doing the other 199 interviews? I sometimes even use recruiters when my time is at a premium. And that raises another interesting question: how is it that so many recruiters who can't code have been able to send me top quality candidates so consistently? Which leads me right back to my first point in this thread: this article is an excellent example of why most companies should never ask about algorithms in an interview.

by ipnon 6y ago

tsumnia 6y ago

> I think we can all agree someone can be a poor software engineer and not have any red flags. This has been something I find myself musing over every now and then for a couple years now. As we begin to relax barriers of entry, how do we maintain that some people fail/lose?

ipnon 6y ago
In a business, you are either don't hire them in the beginning or fire them in the end. Not everyone should be a software engineer (where would the users come from?). A large labor market organizes people into better jobs when they are passed over for or fired from a position.
- tchaffee 6y ago
  > (where would the users come from?) I'm an engineer and I use loads of software. I bet you do too.
tchaffee 6y ago
I'm curious what makes you think we are relaxing barriers to entry? The senior engineers I've hired are highly productive. And diverse. My process does not have a low barrier to entry. The goal is to use more accurate signals. Instead of hiring people who are good at talking about algorithms at a white board I want to hire good software engineers. > some people fail / lose This comes off as a condescending way of thinking about the hiring process. Even if the candidate is not qualified for the position I want to leave them feeling like I helped them a little in their career or at the very least in their interviewing skills and confidence. You can find a good fit for a role without leaving the other candidates feeling like they failed. And I think that starts to get to the crux of the problem at some companies : the process is meant to boost the ego of the interviewer. Almost every senior dev has a few stories about how the interviewer just wanted to feel superior. We can do far better than that.

tchaffee 6y ago

That's a useful mental model. It took me a while to reply because I was trying to get enough clarity on why my process works to put it into words. I use red flags in my hiring process. There are many when it comes to whether or not someone is a good engineer. Inability to do algorithms on a whiteboard is not one of them. I do try to prove my red flags wrong which is what sometimes reveals a diamond in the rough. > The hiring process you are proposing is looking to methodically search for all of the useful qualities in the candidate pool and determine how they can best be applied at the company. That's not necessarily what I'm proposing. I often need find the first qualified candidate who can start contributing. Don't let perfect be the enemy of good. One of the ways I accomplish cost effective hiring is to go through applications in the order they arrive and the first candidate who passes the interview gets the job. If I get 200 applications and I find a suitable candidate in the 1st interview, why would I waste my time and money doing the other 199 interviews? I sometimes even use recruiters when my time is at a premium. And that raises another interesting question: how is it that so many recruiters who can't code have been able to send me top quality candidates so consistently? Which leads me right back to my first point in this thread: this article is an excellent example of why most companies should never ask about algorithms in an interview.