[brenainn]

I had my own reply, but using your analogy if I may: if I asked an apprentice carpenter to measure up and build some sort of structure in front of me with the tools provided, and they stumbled and made some awkward choices but the result was otherwise sound and they had other good qualities, yeah I'd consider hiring them. I think the scenario you describe though would be more equivalent to someone who flat out doesn't know how to even use a computer, which is a different case (I wouldn't hire that person).

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