4 ms·

I think Hanlon's Razor applies. They have no impetus to change and think they have found an approach that works reasonable well when given absurd amounts of ca

by aanm1988 9y ago

I think Hanlon's Razor applies. They have no impetus to change and think they have found an approach that works reasonable well when given absurd amounts of candidates. The problem is the ridiculous false negative rate. I struggle to think of a better system. Using experience is unfair and misleading (I worked on awesome stuff... that I can tell you nothing about, I was totally the lead on this software, etc...). Take home stuff is fine with me but a lot of people have problems with it. Come in for a week type things are incredibly applicant hostile. Sit down with me and lets try and fix this bug seems like a more reasonable solution to me. Dev environment has the most popular ide with their devs, the source for whatever, internet access, and a bug report. Person is there to assist.

gaylemcd 9y ago
They have lots of impetus to change. It's just that they struggle to find a better system. Talking about prior experience? Flawed for the reasons you mentioned. Take home stuff? Flawed -- cheating and other issues (I discuss this in another comment). Work with us for a week? Doesn't scale. Unfair to candidates. Lots of issues here. Sit down and help me fix this bug? Flawed: 1. Huge bias based on whether they know this particular skill set -- the right tools, etc. 2. Pretty arbitrary as to whether they find that particular bug. 3. It can't be a real bug. It has to be a toy project in order to get a consistent evaluation.
- kaspiCZ 9y ago
  I'd say homeworks are good. In a mix. In fact the process should be a mix. It's hard to get it right. You can find out if they copied the homework. There should always be a follow up talk about it. They should be able to explain the details. Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach more than anything. Bug fixing is hard to prepare right. If you have a clear cut position, that would eliminate part of bullet one. I'd argue that they should not be asked to find the bug. Only to fix it. It does not have to be the same bug. I'd argue for a pool they can pick from. You should be testing how they approach the problem and how they go about solving it. Heck you can debug and outline a fix for something you can't really code yourself, I know I did. Pairing with someone from the team they'd work in could also provide some insight into the dynamic. I agree there is no cookie cutter way for homework and bugs. That's why they need to be in a mix, well prepared and supervised.
  - TulliusCicero 9y ago
    > You can find out if they copied the homework. There should always be a follow up talk about it. They should be able to explain the details. That doesn't prove anything. They could've hired a senior developer to help them and explain the concepts in detail. > Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach more than anything. The more 'real-world' this is, the more it's going to be biased towards those that have experience in a particular stack or with a particular type of development. Which isn't necessarily bad (it could even be good!), but it may be if you want a more agnostic interviewing process.
    - wayn3 9y ago
      - The more 'real-world' this is, the more it's going to be biased towards those that have experience in a particular stack or with a particular type of development. Which isn't necessarily bad (it could even be good!), but it may be if you want a more agnostic interviewing process. I fail to see how that particular point can ever be a negative for the hiring company. If you need specific skills, you dictate the environment. If you want the candidate to bring his own skills, just tell him to pick his favourite tools.
  - gaylemcd 9y ago
    I can explain the details of Dijkstra's algorithm. Does that mean I invented it? There is a world of difference between "created something" and "can explain it in detail."
  - mcv 9y ago
    What I always prefer is a take-home programming assignment, and then present the results to a group of developers. You need to be able to explain what you did and answer questions about it.

gaylemcd 9y ago

They have lots of impetus to change. It's just that they struggle to find a better system. Talking about prior experience? Flawed for the reasons you mentioned. Take home stuff? Flawed -- cheating and other issues (I discuss this in another comment). Work with us for a week? Doesn't scale. Unfair to candidates. Lots of issues here. Sit down and help me fix this bug? Flawed: 1. Huge bias based on whether they know this particular skill set -- the right tools, etc. 2. Pretty arbitrary as to whether they find that particular bug. 3. It can't be a real bug. It has to be a toy project in order to get a consistent evaluation.

kaspiCZ 9y ago
I'd say homeworks are good. In a mix. In fact the process should be a mix. It's hard to get it right. You can find out if they copied the homework. There should always be a follow up talk about it. They should be able to explain the details. Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach more than anything. Bug fixing is hard to prepare right. If you have a clear cut position, that would eliminate part of bullet one. I'd argue that they should not be asked to find the bug. Only to fix it. It does not have to be the same bug. I'd argue for a pool they can pick from. You should be testing how they approach the problem and how they go about solving it. Heck you can debug and outline a fix for something you can't really code yourself, I know I did. Pairing with someone from the team they'd work in could also provide some insight into the dynamic. I agree there is no cookie cutter way for homework and bugs. That's why they need to be in a mix, well prepared and supervised.
- TulliusCicero 9y ago
  > You can find out if they copied the homework. There should always be a follow up talk about it. They should be able to explain the details. That doesn't prove anything. They could've hired a senior developer to help them and explain the concepts in detail. > Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach more than anything. The more 'real-world' this is, the more it's going to be biased towards those that have experience in a particular stack or with a particular type of development. Which isn't necessarily bad (it could even be good!), but it may be if you want a more agnostic interviewing process.
  - wayn3 9y ago
    - The more 'real-world' this is, the more it's going to be biased towards those that have experience in a particular stack or with a particular type of development. Which isn't necessarily bad (it could even be good!), but it may be if you want a more agnostic interviewing process. I fail to see how that particular point can ever be a negative for the hiring company. If you need specific skills, you dictate the environment. If you want the candidate to bring his own skills, just tell him to pick his favourite tools.
- gaylemcd 9y ago
  I can explain the details of Dijkstra's algorithm. Does that mean I invented it? There is a world of difference between "created something" and "can explain it in detail."
- mcv 9y ago
  What I always prefer is a take-home programming assignment, and then present the results to a group of developers. You need to be able to explain what you did and answer questions about it.