There is a huge pool of exceptional junior engineers

When I hire juniors, I try to give them problems that I know they likely won't be able to solve in the interview because I want to see how they think about things. The problem has become that a lot of kids coming out of college have done little more than memorize Leetcode problems and outsourced classwork to AI. I've also seen less and less passion for the career as the years go by (ie. less computer nerds).

Unless the company is doing something that requires almost no special domain knowledge, it's almost inevitable that it's going to take a good while for them to on-board. For us, it usually takes about year to get them to the point that they can contribute without some form of handholding. However, that also mostly holds true for seniors coming to us from other industries.

I noticed I had an immediate bias against candidates that showed up to interviews using Windows (except for one person who was in WSL and seemed very comfortable in bash), or, not having their SSH key set up for cloning the github repo we used for our interview, or fumbling back and forth with their mouse between vscode and the browser, not using all their screen real estate, or not knowing even the most basic of keyboard shortcuts (I nearly cut an interview short once when I saw someone right click copy right click paste in vscode but I wanted to give them a fair shake so gritted my teeth and went through with the rest of the interview. They did poorly.). I never used it as a for/against factor but for me lack of interest in computers, and a lack of familiarity with the tools of our trade, is a red flag.

On the flip side, immediate green flags for me were: using linux, using keyboard shortcuts to manipulate windows / within the IDE, using an IDE other than vscode (vim/nvim or emacs are huge green flags), having custom scripts, having custom themes, or, the biggest one, self-hosting some applications. And Lo, these candidates also seem to perform the best in my experience.

That seems pretty opinionated, and by building a monoculture, persons with high openness to experience likely won't be drawn to your workplace, and you're also leaving on the table the potential that comes from diversity (a loaded term these days, but substantively still a valid point).

Depending on the kind of work you do and your customers, this may not matter to you, but in a lot of industries, you need the diversity to be able to properly represent and empathise with your customer base, who might be from a very different social cohort than your developers. And Linux desktops, which your customers almost certainly won't be using, may also make that difficult.

People who spend a ton of time ricing their Linux desktops may be bad at setting priorities. If you expect them to continue their ricing, but not do it "on the clock", you're implicitly age-discriminating and discriminating against people with families and/or hobbies and/or "a life".

Also keep in mind that your company is likely only one of a dozen or so workplaces that these people apply to in a given month, sometimes for many months before they land a job, and they probably haven't set up their computer specifically to impress you, but rather to fit the lowest common denominator among the requirements they face from all their application processes and educational activities, and some of that will require Windows.

Some points in parent comment are absolutely valid IMO. Would you hire a carpenter who walks back and forth to his toolbox to pickup at single nail at a time and then use the hammer with both hands near the head. And when cutting a 4x4 beam will use 1-inch strokes with the handsaw (again with two hands).

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

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.

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.

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

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.

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