[jalk]

I was thinking about basic tool use. I expect a junior engineer candidate to wield a computer way better than my mom. They are applying for a junior engineer position not and apprenticeship starting with close to zero training. I have no problem with candidates who stumble and make awkward choices during the interview, as juniors by definition lack experience and the interview process is a stressed situation.

[danaris]

I think we need to stop seeing "can program" as being equivalent to "is an expert computer user", because those are genuinely two different, if related and overlapping, skillsets.

There is no particular reason that an expert C++ programmer also needs to know every keyboard shortcut or be an expert at the Linux command line, if those things are not actually relevant to the job you're trying to hire them for. Just because it's been common among millennial and older programmers (like most of us) to combine the two doesn't mean we should discriminate against programmers who don't fit that mold, as long as they're actually good programmers.

[kelnos]

You're presenting a false dichotomy, though. No one in this subthread is expecting an expert computer user. We're just expecting them to have their development environment already set up, and to be familiar and comfortable with their tools.

If they come in with a Linux laptop but aren't comfortable with the command line, that's weird. If they come in with a Mac or Windows laptop and do solid work only with GUI tools, that's fine. If the job requires being able to use specific tools (command-line or GUI or whatever), then the interview should evaluate that as well.

[komali2]

Then, among 200 resumes, how do you find the good programmer? If you have budget to hire one of them.

[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.