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.

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?

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.

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

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.

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.

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.

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.

Using SSH to get the project files is not a good example of a hard to learn skill they need for the job, they should just have provided a zip on a web page or so or sent it directly to the user.

So to me it seems most of the test was just "have you done these trivial things before" rather than test if they can program web apps.

It would be like the carpenter being forced to buy nails and docking them points for now knowing where the closest shop to buy nails in are and taking time to look that up. Of course it is better if some look it up quicker, but its not a core part of the job. Then when they drove there, you gave them a manual stick car, so the ones who were used to automatic fumbled around in the car, also bad look! So now you see carpenters who drove manual were much better, as your biases told you! That is not really the skill you should care about, it is very quick to tell him where it is.

I don't think your analogy is apt. Having your development environment set up and knowing how to use your tools reasonably efficiently seems like it should be a low bar to pass. We're not talking about giving someone unfamiliar tools or an unfamiliar vehicle and expecting them to perform higher level tasks. We're just watching people use their existing tools to see if they're actually familiar and comfortable with them.

OP's post was "having custom themes" "bias against people using windows".

These aren't tests if a user can si their job or knows their tools. This is a cultural purity test to see if they have the same quirks as OP. And is a terrible way to judge if someone will perform.

Yeah, seems I'd be doomed for doing interviews on my Windows laptop for the webcam and the compatibility with my bluetooth headset rather than my linux desktop. Tunnel vision and a lack of empathy are negative signals, so you could say I'd have dodged a bullet, but unfortunately in these situations I'd need the job more than the job would need me.

From my perspective, I think it shows poor judgment that you've chosen hardware where you can't get your webcam and bluetooth headset to work under Linux. Or you haven't bought a wired headset and a USB webcam that you've researched and know works properly under Linux. It sounds like the alternative you've chosen is to take interviews using an OS and development environment you're not comfortable in, which seems like a foolish choice to make.

These days it's not difficult to buy hardware with Linux in mind, even on a budget. (And if you have two computers, I feel like budget is probably not really a problem for you.)

Even if you bought with Linux in mind, there’s no guarantee what works today works tomorrow. I have a Linux box that had working HDMI audio. A recent set of updates to the audio subsystems now means that when the box boots, the HDMI devices are muted by default. It seems like something changed in the order that things are initialized and the HDMI devices aren’t present when the audio system is initialized so none of your saved settings are re-applied. Every boot now requires manually fiddling with the audio settings to reset where audio should be going and unmute the devices. If my choice when going into an interview is the box that you need to buy specific hardware for and hope that no one re-configured the audio subsystems in the last update or the box that runs an os by a company known to put explicit code paths to recreate a prior edition bug that other software relies on… I might choose the latter too, even if it is windows. Of course I’d also probably choose the latter because there’s a non zero chance the interviewer is going to want to use some conferencing software or website that doesn’t work in Linux regardless of how well matched my hardware is.

I simply don't use a headset or a webcam with my home Linux setup, because it's often been a hassle to deal with, and my work setup is separate. For screen-sharing type coding interviews, I have a perfectly functional remote SSH setup from my windows laptop, which took less time to setup than the last time I fiddled with a bad headset connection on Linux a long time ago. I find the "not using all of screen real estate" accusation to be strange as well, because usually screen-sharing is ergonomically limited to 1 screen, but people may usually work with two screens and not have developed habits to make 1 screen work.

> sometimes for many months before they land a job, and they probably haven't set up their computer specifically to impress you

I wouldn't expect them to. I would expect them to have their computer set up to program. If it's not set up for programming, then, that's ok, they just won't fit in in an environment of people who really, really enjoy programming, and most likely aren't able to program at the level we expect. This theory worked out - about 10% of candidates were the kind that program regularly, for fun, or at least to build their portfolio, and of that 10% the one we ended up hiring turned out to be phenomenal.

Like I said, the people who got furthest in the interview (solved the most problems) were the ones who had computers set up to program and were comfortable in their environment. Everyone got the same email, everyone knew they'd need to clone a repo and run node, and everyone who got the email had already passed the initial screening so I'd expect them to actually start reading our emails and taking this stage of the interview process seriously, considering it was the final stage (and the only stage involving actual programming).

> you're also leaving on the table the potential that comes from diversity (a loaded term these days, but substantively still a valid point).

Diversity comes in many forms. Someone not great at programming, or not that interested in it, I'm happy to select against. Do you have a reason I shouldn't filter these folks out? We're paying someone to code at the end of the day so I'm pretty confused at all this pushback to my bias towards "interest in computers."

The other diversity markers I don't think were selected against - I have no idea what "high openness to experience" means but we had people with all sorts of different personalities and interests that we interviewed, all sorts of backgrounds, and sure all sorts of different gender expressions, national backgrounds, refugee status, race, so on.

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

Sure, and every hiring manager that puts people through a coding interview is implicitly engaging in ableism - someone with severe mental disabilities won't be able to pass the interview. Capitalism is ableist. I agree. They also had to have right to work - something I personally don't give a shit about but the State does. What am I supposed to do about it?

Anyway interest in computing and "having a life" or hobbies or a family aren't mutually exclusive. At all the companies I've worked in, I've been surrounded by super nerds with families and other hobbies, alongside interest in computing. I've known a mom that went sailing every weekend and programmed circles around me, a married individual running a pokemon selling business and a lasercutting etsy store on the side all while having the healthiest marriage I've ever seen and personally aspire to, folks that brew beer or garden or make cheese, a hella greybeard that runs DND (and ran a campaign for the office alongside two others he was running)... all of these people I mentioned far better programmers than me, far more advanced knowledge of computers than me, and I don't do even close to that much outside of computer stuff.

So, I don't know what to say other than I guess the last few companies where I worked and ran interviews at at just had really energetic people and wanted to hire more energetic people? That's something to criticize?

You mention IDEs besides VS Code, Linux, and ricing as “green flags”. Those are not proxies for “being a good programmer” and they are not proxies for “being enthusiastic about programming”. They're just selecting for programmers who share your subjective preferences on matters that are the equivalent of “vi vs. emacs”.

The only workplaces that realistically allow people to use Linux desktops are academia and top-5%-sexiness-factor startups. The other 95% of us have to use what our boss tells us to use (and he got told by the insurance company that scammed him into cybersecurity insurance). Those of us who have families, don't spend our leisure time staring into yet another desktop computer that isn't our work machine, so how, on earth, would we be using Linux desktops?

Conversely: Imagine someone has spent an 8-hour-workday setting up their tiling window manager, so they can “improve their productivity” because now they don't need to spend 2 minutes painting all their windows into the right positions in the morning. That's an investment of time that takes (8*60)/2 = 240 days, so roughly one work-year, to amortize. What does that tell you about the time management skills of that person?

I don't say that to knock tiling window managers: If you're into it, be my guest. It's perfectly fine for reasonable people to reasonably disagree on those kinds of subjective preferences. That's what subjectivity is all about. And that's why it's valuable to hire a diverse range of people who have different viewpoints on these kinds of things.

EDIT: ...and that's what I mean by "diversity": To include both family-people and people without families. Young and old. People with an academic background and people without one. Vi-people and emacs-people. Please don't strawman me by bringing up disabled people and work permits and whatnot.

> To include both family-people and people without families. Young and old. People with an academic background and people without one. Vi-people and emacs-people.

Well, I don't know what to tell you, you've just described my entire team, same as my previous company that had a bunch of linux/unix dweebs, so the fact that we're all really into computers hasn't hindered us from this diversity.

All my jobs have let me choose my OS, all my jobs were full of people exactly as you describe, they just all happened to be really into computers. How the family folks found time for it is a question I still ask myself to this day when I compare my knowledge to theirs, but regardless, it wasn't a hindrance.

So I maintain my confusion around selecting for this. It's just not my experience that it prevents me working with family folks, or old folks, bootcamp kids and phD ML people.

So, ok, we've come this far: How do you run interviews? What's the alternative to the way I've seen?

> The only workplaces that realistically allow people to use Linux desktops are academia and top-5%-sexiness-factor startups. The other 95% of us have to use what our boss tells us to use (and he got told by the insurance company that scammed him into cybersecurity insurance).

This is super ironic and shows your "us" in "the rest of us" is a tiny, marginal group, maybe "Silicon Valley programmers" or something. In most small software companies they couldn't care less what you use, the only thing they look at is perceived "speed". You could install Red Star OS and get a few pats on the back if you're closing the highest number of Jira tickets.

Hell, nowadays more and more are full remote and the devs do their work on their personal device. Or they do BYOD. Work devices are a cost center.

It's the opposite, the only places that force a particular OS are the top companies for whom compliance, fleet management and such are priorities.

Kind of funny, these mutually escalating accusations of being a member of an out-of-touch elite.

All it takes for BYOD to become difficult is having to handle personally identifiable information under the rules of the GDPR, or having some kind of professional indemnity insurance with cybersecurity provisions, perhaps having quality management certification, being in certain highly-regulated professions like law or medicine, being in the public sector, working government contracts, etc. etc. (the list goes on and on) -- I'm just finding it hard to believe that this list doesn't capture most companies.

But then again, maybe, I am a member of an out-of-touch elite.

> You mention IDEs besides VS Code, Linux, and ricing as “green flags”. Those are not proxies for “being a good programmer” and they are not proxies for “being enthusiastic about programming”. They're just selecting for programmers who share your subjective preferences on matters that are the equivalent of “vi vs. emacs”.

Are you sure about that? I have a strong suspicion that there may be a measurable correlation between using IDEs and other tools that aren't currently trendy/overhyped and having a stronger-than-average foundation of experience.

Given that VSCode is the big, trendy IDE at the moment, doesn't using a different one indicate that a developer has, at minimum, invested some thought and effort into considering alternatives and making a conscious choice?

> And Lo, these candidates also seem to perform the best in my experience.

You mean the people you're not prejudiced against for their choice of laptop OS tend to perform better in your eyes? Interesting.

The interview has various portions, given in sequence. The ones who got the furthest (or ran out our interview to where we had to invent "new fun bits" on the fly) were the ones who I mean when I say "performed best."

The interview was implementing in live coding a prepared frontend stack. The email sent out indicated explicitly the task, that they'd be expected to share their screen and clone a repo off github, run `npm` commands, and then pair program. So those that weren't prepared for this, fussing around with ssh keys not set up or node not installed, or not knowing how to use bash or git, yeah it counted against them.

> right click copy right click paste

Remembers me of a fellow student who refused to maximize his editor window. It turned out that he moved the text cursor to the next line with the right indentation by using just a lot of spaces.

> cloning the github repo we used for our interview

Unless it's a very well-known big tech, I'm not sure I'd feel comfortable running any externally provided code during the interview. For all I know, it's RCE with potential to steal cookies and/or crypto.

Cloning a repo and running things from it are two very different things.

It's a FOSS repo on github... you can just look at the code yourself. If we RCE you you can easily sue us lol.

So for you, how should a company determine from 200 applicants, which one will be able to do the job best? Or at least some approximation to get down to the 5 most likely to do the job best?

That seems unnecessarily paranoid. What's your threat model here?

I think going by that, for juniors anyway, isn't great. Remotely coding during an interview isn't a great environment to start with, and you're probably seeing a lot of people unable to achieve any sort of flow because their mental capacity is devoted to the interview. Some people also won't pick up more advanced tooling until they have to start coding day after day for a living, and until they have other people to learn from. That was my situation anyway.

Some of these yes, some of these no. In general being a clicker is a completely fine way to weed people out. If you don’t code like time is on the line without being asked to, I will not take the risk of needing to ask you.

I’m less passionate about windows and have met some absolute wizards who use it, but in general it’s a negative indicator.

Copying and pasting with the context menu, sure. But using vs code or Windows entirely? That seems a little extreme.

Using vscode wasn't a red flag, using a different IDE was just a green flag. Everyone uses vscode, I wouldn't hold it against anyone for doing so, especially not a junior. But picking a different tool exhibits a unique level of interest in the job and our tools, and a different mindset. Those are pluses for me.

Nobody was rejected because they used windows. It just so happens that none of the windows folks got past problem 1 of 3 (as in, they ran out of time without solving).

Edit: I'm remembering now, one of the windows folks did get to the end of the interview, and they were the first person I recommended actually, so it's not like it was a deciding factor, just something that I'd see and go "hm" about.

Understood, thanks for clarifying.

For 20-ish years I used vim with a custom configuration made of piles of plugins painstakingly tailored over many hours to my exact taste.

Now I use VSCode because it's there, and it works. (With vim bindings, though. I'm not going back on that.)

I don't see why using vi mode in vscode isn't a green flag.

That would be a green flag for me.

That just means you insist on people like you are reject those who are a little different. Probably in a lot more areas then you are even realizing.

If I handed you 200 resumes and said "hire from this set our next junior frontend engineer," how would you do it? Assume: generic b2b SASS, post-seed, 5 person engineering team making first junior hire.

> I nearly cut an interview short once when I saw someone right click copy right click paste

I like to live in the terminal, but I still sometimes do that. There are multiple clipboards, so using the mouse might sometimes do something different and sometimes I'm just tired and want to use my hands in a different position. And if I selected with the mouse its not much more effort than stopping the selection. You press down left for the selection, move for selection, at the end roll the finger over to the right mouse button without lifting, continue moving so the pointer goes over the rollover and lift the finger again once the pointer is over the copy action. This is the same amount of finger lift than just stopping the selection. Then pressing one or two keys on the keyboard are two finger movements more.

> right click paste

I am sometimes forced to do this because with markdown, Ctrl+Shift+V will render the markdown instead. I almost never use Ctrl+V because it will append paste instead of replace paste.