[danaris]

Well, first of all, most likely dozens of them, at least, are good programmers.

In fact, most likely dozens of them will be perfectly good hires for the position.

The idea that you must hire only the single best possible candidate can lead to some pretty dehumanizing treatment of applicants, when the truth is that a) there almost certainly is no "single best possible candidate", there are many people who would do a roughly equally good job there, and b) your processes are almost certainly not optimized to actually find the true single best candidate for the job, but rather the person who is best at applying and interviewing for jobs among the candidates.

All that said, for "how do you actually design a better process"...I sure as hell don't know. I'm a programmer, not an HR person or hiring manager; that's outside my skillset. But that doesn't mean I can't accurately identify glaring flaws in the current system based on my understanding of human nature.

[jimbokun]

> I'm a programmer, not an HR person or hiring manager; that's outside my skillset. But that doesn't mean I can't accurately identify glaring flaws in the current system based on my understanding of human nature.

No, it pretty much does mean that.

Until you can come up with concrete improvements and understand the potential flaws in those proposals as well, you can't usefully critique the existing system.

[danaris]

Can only a master chef tell you that your chicken is undercooked?

Can only a trained programmer tell you that it's a bug when you press the "OK" button, but your program does the "cancel" action?

Can only someone who knows exactly how to build and fix a system tell you that a specific aspect of the system is flawed?

[komali2]

Better example: you press the ok button, and sometimes, only sometimes, it triggers twice.

You tell your lead, they say "I know." You ask why they haven't fixed it, and they lead you down a deep rabbit hole of fundamental, unsolved issues with event bubbling, and show you the 20 different workarounds they've tried over the years. "In the end," they say, "nobody's figured out how to not get it to sometimes fire twice."

Thus hiring. Sure it looks not right to you, but, come join us in hiring and you'll see, a better way has yet to be found. At least when I run interviews it's an actual real problem rather than a leetcode thing - I always just grab something reasonably difficult I recently did for the company and convert it to an interview problem.

Your guess that ~24/200 will be "good enough" is unfortunately wrong in my experience. In my last go, only 10/200 were able to demonstrate sufficient knowledge of the required skills to be hireable, and by that I mean fulfill the needs of the role in a way that justifies their salary, rather than be so inexperienced as to be a drain on resources rather than net gain. Of that 10, 2 were the best. Criticizing not wanting to work with the best doesn't make sense to me. Lemme put my capitalism hat on, there: we have competitors, we need to code faster than them to get clients before them. If we don't, we lose revenue and don't get another funding round, and the company dies. Also all hiring is reported back to the investors who have an expectation we get good people. Also we give equity - why wouldn't I want the best possible people on my team so that I have the highest chance of my equity paying out big?

Capitalism hat off, yup, this system is dehumanizing and not configured to deliver the greatest societal good. Alienated labor detached from the true value of the goods produced, absolutely. What can I do about that at my job? On the side I run a co-op that operates under literally the opposite principles: anyone can join, we will train you to get the skills you need to get better jobs, and no margin of the rate is siphoned away for a capitalist class.

[Gormo]

The problem with your last paragraph, of course, is that there is no "system", no generalizable concept of "societal good", no such thing as "true value" independent of the subjective evaluations of an object by disparate parties, and no "capitalist class" that actually exists as such.

Everything is down to particular patterns of interaction among particular people, all acting on their own a priori motivations, with none of the reified abstractions you're referencing actually existing as causal agents.

I applaud your efforts with the co-op you're describing, and if you're able to make it work, scale up, and sustain itself in the long run, more power to you. But it's a bit strange to imply that in the more common scenario, it's somehow untoward for the people paying the upfront costs of your endeavors -- and indemnifying your risk exposure -- to expect a share of the proceeds in return.

[danaris]

> Your guess that ~24/200 will be "good enough" is unfortunately wrong in my experience. In my last go, only 10/200 were able to demonstrate sufficient knowledge of the required skills to be hireable, and by that I mean fulfill the needs of the role in a way that justifies their salary, rather than be so inexperienced as to be a drain on resources rather than net gain.

I mean, this is fundamentally dependent on the specific position being hired for.

[komali2]

I'm interested in this conversation however this comment doesn't really mean anything to me. What are you saying? And so, how would you hire? If you just wanted to say, "hiring sucks," I agree. Hiring sucks.

[danaris]

This comment is saying "the percentage of any given 200 programmers applying for a job that are, in the end, reasonably fit to do the job depends on the job being applied for".

If the job is a mid-level C++ programmer job at an insurance company, many more of them are likely to be good fits than if it's a senior embedded systems architect job at an aerospace firm.