3 ms·

> The main reason is that difficult tests has positive signal They provide a signal, but I don't think the evidence suggests that it's necessarily a positive o

> The main reason is that difficult tests has positive signal They provide a signal, but I don't think the evidence suggests that it's necessarily a positive one. "Can you play Czardas on the tuba" is a difficult task that would provide a strong hire/no hire signal, but that doesn't mean it would be a good signal to use when looking for developers. The big tech companies themselves admit that a bunch of their employees are not sufficiently competent [1]; clearly, current hiring practices are suboptimal. Just because a test exists doesn't mean it's valid. > You mean all those jobs requiring college degrees There are many jobs where high performance doesn't require a college degree, and for those jobs, requiring a degree is again an exercise in box-ticking that should be replaced with a more meaningful measure. There are also jobs were significant education in the topic is important, and a degree provides better evidence of that that many other things, so can be a useful signal. We know that tech hiring is broken, but whenever it's criticised, the people invested in this system get outraged. "What do you want us to do, just hire everyone?" etc. No one is saying - or has ever said - that assessing applicant competence is a bad idea, just that assessing the ability to rote learn is not the best use of time when hiring developers. The current system is not the only way, and for an industry that prides itself on being filled with problem solvers and hackers, it's bizarre to me how much people rest on the idea that the existing system is imperfect but present, and so should be left alone. [1] https://www.reuters.com/technology/exclusive-meta-girds-fierce-headwinds-slower-growth-second-half-memo-2022-06-30/ https://www.reuters.com/technology/exclusive-meta-girds-fier...

hardware2win 4y ago
Maybe it is not the best system, but isnt it at least relatively fair and transparent in compare to "having luck on interviewer's stack/xp"?
- Planktonne 4y ago
  Why would that be the only other option? That's exactly the same kind of hoop-jumping, perhaps even a little more honest. This is exactly what I was talking about above. The solution for a known-to-be-broken system isn't another known-to-be-broken one, and it isn't keeping the broken system because it's already in place. Development isn't about rote memorisation or slavishly repeating past mistakes. Knowing the Voight-Kampff algorithm doesn't make you a good developer, nor does claiming 20 years of experience with a decade-old technology, nor does being the CEO's nephew. All of those things provide (at best) a totally irrelevant signal. What if we used better methods? Ones that actually assessed and evaluated the skills/traits necessary to do the job well? Ones that couldn't be gamed as easily by "grinding". I'm not saying there's globally-applicable silver bullet just waiting to go, but there are definitely avenues to explore. One process I went through quite recently asked me to bring along a single line of code I'd written - any language, any project. Then we had a conversation about it: what it actually did, how it fitted into its context, why I'd written it like that. It provided me with an opportunity to show my understanding, and for the interviewer to probe particular areas they were focused on. I enjoyed the process, and I could see how it was providing relevant information to them. Again, it's an imperfect process, but I think there's potentially a lot of mileage in 'talking to developers' when hiring them, with any number of different twists. At the very least, we should be experimenting and trying to find a fit-for-purpose process.
  - shxdow 4y ago
    The question I have in regards to your suggestion is, how scalable is it ? Can/could it be applied to a FAANG-sized company ? I'm not rejecting any of your points, its just that every time someone critiques the current hiring practices they fail to provide an alternative system that does not introduce other problems (the first and most notable one is scalability, but there are many others)
    - Planktonne 4y ago
      I think a conversation is eminently scalable. If an organisation cannot devote 30 minutes to checking if someone they're about to hire is at all competent, then that organisation has much, much bigger problems than hiring. The current process also requires dedicated employee time to administer, after all - this takes no more time, involves less employee prep, and (crucially) might be valuable.

hardware2win 4y ago

Maybe it is not the best system, but isnt it at least relatively fair and transparent in compare to "having luck on interviewer's stack/xp"?

Planktonne 4y ago
Why would that be the only other option? That's exactly the same kind of hoop-jumping, perhaps even a little more honest. This is exactly what I was talking about above. The solution for a known-to-be-broken system isn't another known-to-be-broken one, and it isn't keeping the broken system because it's already in place. Development isn't about rote memorisation or slavishly repeating past mistakes. Knowing the Voight-Kampff algorithm doesn't make you a good developer, nor does claiming 20 years of experience with a decade-old technology, nor does being the CEO's nephew. All of those things provide (at best) a totally irrelevant signal. What if we used better methods? Ones that actually assessed and evaluated the skills/traits necessary to do the job well? Ones that couldn't be gamed as easily by "grinding". I'm not saying there's globally-applicable silver bullet just waiting to go, but there are definitely avenues to explore. One process I went through quite recently asked me to bring along a single line of code I'd written - any language, any project. Then we had a conversation about it: what it actually did, how it fitted into its context, why I'd written it like that. It provided me with an opportunity to show my understanding, and for the interviewer to probe particular areas they were focused on. I enjoyed the process, and I could see how it was providing relevant information to them. Again, it's an imperfect process, but I think there's potentially a lot of mileage in 'talking to developers' when hiring them, with any number of different twists. At the very least, we should be experimenting and trying to find a fit-for-purpose process.
- shxdow 4y ago
  The question I have in regards to your suggestion is, how scalable is it ? Can/could it be applied to a FAANG-sized company ? I'm not rejecting any of your points, its just that every time someone critiques the current hiring practices they fail to provide an alternative system that does not introduce other problems (the first and most notable one is scalability, but there are many others)
  - Planktonne 4y ago
    I think a conversation is eminently scalable. If an organisation cannot devote 30 minutes to checking if someone they're about to hire is at all competent, then that organisation has much, much bigger problems than hiring. The current process also requires dedicated employee time to administer, after all - this takes no more time, involves less employee prep, and (crucially) might be valuable.