5 ms·

Your coding challenge is costing you good developers

4 points by ijidak 6y ago

pmontra 6y ago
They're doing it because it's easy to do and automate. If they want developers out of school, it's also better than tossing a die. However if they want good developers, do they really think that the young myself with a fresh degree is better than me after 10 years of work or 20+ now? I bet I was better at solving quizzes when I was young. I'm sure I can understand and solve real world problems now. If they don't care, quizzes are OK.
- ijidak 6y ago
  > However if they want good developers, do they really think that the young myself with a fresh degree is better than me after 10 years of work or 20+ now? I bet I was better at solving quizzes when I was young. I'm sure I can understand and solve real world problems now. Agree. That's what these quizzes miss. After working in development for years, top performing developers aren't the ones who dwell on these trivial function-level optimizations. Yet, that's exactly what these tests are testing for. The 10x developers are the ones who can understand the big picture, synthesize information, and deliver solutions that are flexible given constantly changing requirements. Function-level optimizations are important, but it's not something we sit around and memorize like we did when we were still in school. As you said, if the company is looking for developers fresh out of college, then sure... These quizzes are a good way to determine raw computer science knowledge. But if the company wants code that's more likely to work the first time, and to require less maintenance over the long-run, these tests are actually filtering out those more-seasoned developers.
davismwfl 6y ago
IMO, this is a problem in tech hiring and it seems the industry is doomed to repeat mistakes we've made before. During the dotcom boom we did similar brain teasers and algorithm questions, but at least then we first phone screened people and made sure there was an initial match. Even then, those interviews led to one thing consistently. We had really smart (mostly well-meaning) people who were many times incapable of putting the product together because they were too busy arguing about non-existent technical problems. That was the primary reason we moved away from those types of interviews and started interviewing people around design, architecture and decision making instead of algorithms. Although in some instances algorithms are important to a position in which they would still be a part of the interview (but that is a tiny minority of the positions generally). I have done many thousands of interviews since the mid 90's and my process is very simple and I think fair to everyone. 1st, 20-30 minute phone screen for fit, both sides potential employee to us and us to the employee. ~2 hr Technical interview that focuses on decision making, design choices, architecture and pattern recognition. The technical interview focuses primarily on how you think and how you solve the problems, not if you write the most efficient loop or can create a tree from memory. Of course there will be questions to make sure you know what you say you do, but that easily comes out during these interviews. From there you talk to other team members, partial tech, partial culture and then a decision is made. No take home project, no wasting your time or ours, just a quick and fair process. I get awesome hires 90%+ of the time, but every so often a bad apple makes their way through which sucks but is just a part of hiring. You fix it and move on. I have open positions for web and mobile, happy to have smart, quality candidates. No need to study leetcode or algorithms for our open positions.

4 points by ijidak 6y ago

They're doing it because it's easy to do and automate. If they want developers out of school, it's also better than tossing a die. However if they want good developers, do they really think that the young myself with a fresh degree is better than me after 10 years of work or 20+ now? I bet I was better at solving quizzes when I was young. I'm sure I can understand and solve real world problems now. If they don't care, quizzes are OK.

ijidak 6y ago
> However if they want good developers, do they really think that the young myself with a fresh degree is better than me after 10 years of work or 20+ now? I bet I was better at solving quizzes when I was young. I'm sure I can understand and solve real world problems now. Agree. That's what these quizzes miss. After working in development for years, top performing developers aren't the ones who dwell on these trivial function-level optimizations. Yet, that's exactly what these tests are testing for. The 10x developers are the ones who can understand the big picture, synthesize information, and deliver solutions that are flexible given constantly changing requirements. Function-level optimizations are important, but it's not something we sit around and memorize like we did when we were still in school. As you said, if the company is looking for developers fresh out of college, then sure... These quizzes are a good way to determine raw computer science knowledge. But if the company wants code that's more likely to work the first time, and to require less maintenance over the long-run, these tests are actually filtering out those more-seasoned developers.

davismwfl 6y ago

IMO, this is a problem in tech hiring and it seems the industry is doomed to repeat mistakes we've made before. During the dotcom boom we did similar brain teasers and algorithm questions, but at least then we first phone screened people and made sure there was an initial match. Even then, those interviews led to one thing consistently. We had really smart (mostly well-meaning) people who were many times incapable of putting the product together because they were too busy arguing about non-existent technical problems. That was the primary reason we moved away from those types of interviews and started interviewing people around design, architecture and decision making instead of algorithms. Although in some instances algorithms are important to a position in which they would still be a part of the interview (but that is a tiny minority of the positions generally). I have done many thousands of interviews since the mid 90's and my process is very simple and I think fair to everyone. 1st, 20-30 minute phone screen for fit, both sides potential employee to us and us to the employee. ~2 hr Technical interview that focuses on decision making, design choices, architecture and pattern recognition. The technical interview focuses primarily on how you think and how you solve the problems, not if you write the most efficient loop or can create a tree from memory. Of course there will be questions to make sure you know what you say you do, but that easily comes out during these interviews. From there you talk to other team members, partial tech, partial culture and then a decision is made. No take home project, no wasting your time or ours, just a quick and fair process. I get awesome hires 90%+ of the time, but every so often a bad apple makes their way through which sucks but is just a part of hiring. You fix it and move on. I have open positions for web and mobile, happy to have smart, quality candidates. No need to study leetcode or algorithms for our open positions.