9 ms·

By standardizing the hiring process aren’t you then just optimizing for a very specific perception and/or perceptional ability? Isn’t that at the core of princi

By standardizing the hiring process aren’t you then just optimizing for a very specific perception and/or perceptional ability? Isn’t that at the core of principles relating to diversity in the first place? I personally find some of the current (if I can call them) standards of tech hiring to be very narrow in which skills and capabilities they test. It presumes a lot—particularly that one has time and resources to commit to spending time studying enough of the spectrum of CS subjects in order to pass a given question from the rather large field. (By this I’m referring to the classic “white board a <somekindof>sort algorithm purely from memory” process that has become the de-facto standard)

PragmaticPulp 7y ago
> I personally find some of the current (if I can call them) standards of tech hiring to be very narrow in which skills and capabilities they test. What would you propose as an alternative? I’ve been involved in training new engineering managers how to hire and interview. Everyone starts with the best intentions, but reality quickly forces some compromises. The bottom line is that you only have a number of hours in which to evaluate the candidate. The longer and more comprehensive you make your interview processes, the stronger signal you get. However, the longer your interview process, the more you’ll find people dropping out of the hiring pipeline due to lack of time or willingness. I’ve worked with companies that tried to implement week-long paid interviews where candidates pair with employees to solve real problems. It’s great! But only when it works for the candidate. You can’t realistically expect busy professionals to take an entire week off of their current job to spend time with a company that may or may not hire them. Monetary compensation only goes so far when you’re forcing someone to choose between spending a week of their vacation interviewing with your company or spending a week taking their family on vacation.
- lubujackson 7y ago
  Honestly, the "coding" is rarely the issue. For most software engineering roles you generally want someone who can: understand problems, figure out possible solutions, decide on which is best, communicate why it is best and (importantly) be flexible when the company wants you to do some other solution. Meet all those requirements and you are a useful member at most companies. I think a general chat about a broad problem and the interviewee's thought process of how they would approach it can tell you much more than whiteboarding some memorized algorithm.
  - milchek 7y ago
    I completely agree. We had this exact discussion at work the other day. I mentioned to a colleague that what I value most is someone who is creative. There are many candidates out there who know all the buzzwords or can discuss features of a programming language purely from memory, etc. This can make for some impressive interviewing, but it tells nothing of their ability to use that knowledge to solve real problems, or their creativity in how they use their skill and expertise when faced with new dilemmas. Sure, you could contest that the creative side isn’t necessary for certain levels of engineering, or that only tech leads require this as a mandatory trait, but I would argue that it is far more important than what most interviews test - rote memorization.
    - adt2bt 7y ago
      I'm right there with you. I am always looking for people who attack problems with new perspectives and, most importantly, can describe to me coherently their thought process and pros/cons of their approach.
      - leghifla 7y ago
        "can describe ... pros/cons of their approach" I've always tried to do that... until recently. With a new recruit, this is the fastest way to nightmare discussions. He always emphasizes the cons of my proposals, and never admit that his proposals also have cons. To be honest, I really think he believes what he says, he seems to not see ahead of time where the blocking points will be. I am now forced to only submit the pros, and prepare an argument for the cons, which is rarely needed. This is not a way to have good technical decisions.
  - kaetemi 7y ago
    Reading code is the biggest problem. Good tests, I find, are to give them a simple piece of code with minimal comments. For example, some non-standard special purpose container implementation. Then ask them to explain what the purpose of the code could be as simply and short as possible. Either - They'll start literally explaining each line of code without understanding the whole. - They completely miss the point. - They at least figure out it's a container of some sorts. - They'll explain technically what it literally does. - They'll give you the academic term for the concept it implements. - They'll actually explain the purpose briefly in simple words. Those last three are good, in different ways. The better ones will also spot the bugs or performance issues in the code.
- giovannibonetti 7y ago
  > What would you propose as an alternative? In my company (totally remote) we decided to automate hiring (also remote) as most as possible and we are happy with the results. We also value the candidate's time very much so we made the hiring process very straightforward. It works like this: - First the candidates must do some online tests, which are mostly multiple choice questions. The subjects are logic, english and a specific test for the coding language. All of these tests were hand made to us and customized to our needs. The candidates spend about 2 hours in total doing theses tests, and they know immediately their score in the parts of the tests that can be accessed automatically (which are the most part) - The candidates approved in the theoretical tests - about 10% of the candidates that applied for the job - do a practical coding challenge that was also made from scratch by us. We have looked at the available solutions in the market and thought they are too focused on textbook algorithms that are rarely used in the job market. So we made our own tests that contemplate practical problems a programmer has to solve daily in our company. The questions are NOT too complex. The objective of this step is to weed out the candidates that can't code in the language, not to get the best. We design this challenge to take about 2 hours. The implementation was a lot of fun: we use the Docker API to run the candidate's code against the automated tests we made and the score is calculated as the number of tests that passed. Using Docker means we can work with any language that runs on Linux. So far we have made tests in Javascript, Typescript, Ruby, Postgres and Elm. - The candidates that are approved in the previous step - about 2-4% of the candidates that applied for the job - are called for an interview. Now is the time when we take a look at the candidate's resume and look at the human side of things. Given that we have very few candidates to look at and we know they all meet some minimum skills we are very confident when conducting the interviews. By now we usually have a very clear signal to tell who the best candidate is even before we conduct the interviews. So in practice the interviews are NOT used to select the best candidate. They are there just to see if a red flag doesn't show up. We are very proud of our coding challenges app. If someone wants to collaborate on it just drop me a message. It's a Rails app on GitHub, but it probably not good enough for an open source project yet - one needs to know a lot about Docker and Rails to make it work.
  - bambataa 7y ago
    If you’re so confident about your challenge app why do you first make everyone do a 2hr online test? How many hours do you spend assessing each candidate and how does that compare to how many hours you make them spend jumping through your hoops?
- jjav 7y ago
  > What would you propose as an alternative? Easy. Just talk to people as would-be peers. They want to find a role they can succeed in. You want to find someone who can succeed in the role. I interview by just talking about their past projects (based on resume). You can't fake your way through a friendly technical dialogue if you haven't done it. (Pre-requisite: the interviewer must be technically competent. This is where many companies miss. Algorithm puzzles won't make up for it.) Also it is important to describe the role and expectations in detail. Nobody (really: nobody) wants to get hired in a role just to be let go in six months. There is no need for elaborate whiteboard algorithm dances which discriminate against everyone who doesn't have the time to memorize every possible question. Just be up front about the requirements and let the candidate decide if it's a match. They know themselves better than you ever will.
  - inertiatic 7y ago
    This would be my way of interviewing, at least for anyone who's not a junior. What troubles me is that people will say this allows all your biases to run wild, but my feeling most of the time is that these biases will find a way to express themselves unless you remove humans from the hiring process entirely.
    - SomewhatLikely 7y ago
      Especially when the company says they aren't necessarily looking for the most bit perfect compilable code or even that you output the optimal algo on first try. Rather they want to see how you think through problems. Well now you're back at a subjective assessment again which inherently can have hidden biases.
      - omar_a1 7y ago
        After failing several of these "let's see how you think" technical interviews, I've come to the conclusion that the way I think is deeply and fundamentally flawed.
  - 52-6F-62 7y ago

PragmaticPulp 7y ago

> I personally find some of the current (if I can call them) standards of tech hiring to be very narrow in which skills and capabilities they test. What would you propose as an alternative? I’ve been involved in training new engineering managers how to hire and interview. Everyone starts with the best intentions, but reality quickly forces some compromises. The bottom line is that you only have a number of hours in which to evaluate the candidate. The longer and more comprehensive you make your interview processes, the stronger signal you get. However, the longer your interview process, the more you’ll find people dropping out of the hiring pipeline due to lack of time or willingness. I’ve worked with companies that tried to implement week-long paid interviews where candidates pair with employees to solve real problems. It’s great! But only when it works for the candidate. You can’t realistically expect busy professionals to take an entire week off of their current job to spend time with a company that may or may not hire them. Monetary compensation only goes so far when you’re forcing someone to choose between spending a week of their vacation interviewing with your company or spending a week taking their family on vacation.

lubujackson 7y ago
Honestly, the "coding" is rarely the issue. For most software engineering roles you generally want someone who can: understand problems, figure out possible solutions, decide on which is best, communicate why it is best and (importantly) be flexible when the company wants you to do some other solution. Meet all those requirements and you are a useful member at most companies. I think a general chat about a broad problem and the interviewee's thought process of how they would approach it can tell you much more than whiteboarding some memorized algorithm.
- milchek 7y ago
  I completely agree. We had this exact discussion at work the other day. I mentioned to a colleague that what I value most is someone who is creative. There are many candidates out there who know all the buzzwords or can discuss features of a programming language purely from memory, etc. This can make for some impressive interviewing, but it tells nothing of their ability to use that knowledge to solve real problems, or their creativity in how they use their skill and expertise when faced with new dilemmas. Sure, you could contest that the creative side isn’t necessary for certain levels of engineering, or that only tech leads require this as a mandatory trait, but I would argue that it is far more important than what most interviews test - rote memorization.
  - adt2bt 7y ago
    I'm right there with you. I am always looking for people who attack problems with new perspectives and, most importantly, can describe to me coherently their thought process and pros/cons of their approach.
    - leghifla 7y ago
      "can describe ... pros/cons of their approach" I've always tried to do that... until recently. With a new recruit, this is the fastest way to nightmare discussions. He always emphasizes the cons of my proposals, and never admit that his proposals also have cons. To be honest, I really think he believes what he says, he seems to not see ahead of time where the blocking points will be. I am now forced to only submit the pros, and prepare an argument for the cons, which is rarely needed. This is not a way to have good technical decisions.
- kaetemi 7y ago
  Reading code is the biggest problem. Good tests, I find, are to give them a simple piece of code with minimal comments. For example, some non-standard special purpose container implementation. Then ask them to explain what the purpose of the code could be as simply and short as possible. Either - They'll start literally explaining each line of code without understanding the whole. - They completely miss the point. - They at least figure out it's a container of some sorts. - They'll explain technically what it literally does. - They'll give you the academic term for the concept it implements. - They'll actually explain the purpose briefly in simple words. Those last three are good, in different ways. The better ones will also spot the bugs or performance issues in the code.
giovannibonetti 7y ago
> What would you propose as an alternative? In my company (totally remote) we decided to automate hiring (also remote) as most as possible and we are happy with the results. We also value the candidate's time very much so we made the hiring process very straightforward. It works like this: - First the candidates must do some online tests, which are mostly multiple choice questions. The subjects are logic, english and a specific test for the coding language. All of these tests were hand made to us and customized to our needs. The candidates spend about 2 hours in total doing theses tests, and they know immediately their score in the parts of the tests that can be accessed automatically (which are the most part) - The candidates approved in the theoretical tests - about 10% of the candidates that applied for the job - do a practical coding challenge that was also made from scratch by us. We have looked at the available solutions in the market and thought they are too focused on textbook algorithms that are rarely used in the job market. So we made our own tests that contemplate practical problems a programmer has to solve daily in our company. The questions are NOT too complex. The objective of this step is to weed out the candidates that can't code in the language, not to get the best. We design this challenge to take about 2 hours. The implementation was a lot of fun: we use the Docker API to run the candidate's code against the automated tests we made and the score is calculated as the number of tests that passed. Using Docker means we can work with any language that runs on Linux. So far we have made tests in Javascript, Typescript, Ruby, Postgres and Elm. - The candidates that are approved in the previous step - about 2-4% of the candidates that applied for the job - are called for an interview. Now is the time when we take a look at the candidate's resume and look at the human side of things. Given that we have very few candidates to look at and we know they all meet some minimum skills we are very confident when conducting the interviews. By now we usually have a very clear signal to tell who the best candidate is even before we conduct the interviews. So in practice the interviews are NOT used to select the best candidate. They are there just to see if a red flag doesn't show up. We are very proud of our coding challenges app. If someone wants to collaborate on it just drop me a message. It's a Rails app on GitHub, but it probably not good enough for an open source project yet - one needs to know a lot about Docker and Rails to make it work.
- bambataa 7y ago
  If you’re so confident about your challenge app why do you first make everyone do a 2hr online test? How many hours do you spend assessing each candidate and how does that compare to how many hours you make them spend jumping through your hoops?
jjav 7y ago
> What would you propose as an alternative? Easy. Just talk to people as would-be peers. They want to find a role they can succeed in. You want to find someone who can succeed in the role. I interview by just talking about their past projects (based on resume). You can't fake your way through a friendly technical dialogue if you haven't done it. (Pre-requisite: the interviewer must be technically competent. This is where many companies miss. Algorithm puzzles won't make up for it.) Also it is important to describe the role and expectations in detail. Nobody (really: nobody) wants to get hired in a role just to be let go in six months. There is no need for elaborate whiteboard algorithm dances which discriminate against everyone who doesn't have the time to memorize every possible question. Just be up front about the requirements and let the candidate decide if it's a match. They know themselves better than you ever will.
- inertiatic 7y ago
  This would be my way of interviewing, at least for anyone who's not a junior. What troubles me is that people will say this allows all your biases to run wild, but my feeling most of the time is that these biases will find a way to express themselves unless you remove humans from the hiring process entirely.
  - SomewhatLikely 7y ago
    Especially when the company says they aren't necessarily looking for the most bit perfect compilable code or even that you output the optimal algo on first try. Rather they want to see how you think through problems. Well now you're back at a subjective assessment again which inherently can have hidden biases.
    - omar_a1 7y ago
      After failing several of these "let's see how you think" technical interviews, I've come to the conclusion that the way I think is deeply and fundamentally flawed.
- 52-6F-62 7y ago