Come on, naming is table stakes. It’s nothing like the usual “please sort this red-black tree” that comes up during stupid interviews but never on the job. Naming comes up on the job all the time and if you routinely get it wrong then over time you’re likely to create more problems for your colleagues than you solve yourself, because they can’t easily understand or refactor what you built. Ie you’ll have negative productivity.
When you’re an interviewer you have to make a decision based on way too little signal. This means you zoom in on the things you do see, and you accept the chance that you might reject a great candidate. I can completely imagine a company rejecting a candidate because they didn’t care about naming.
Now if you think “worried that candidate might have negative productivity due to careless attitude, soft reject” is obnoxious then fine but I think that makes you spoiled. You’re not entitled to a job, even a junior position, simply because you can write a loop or center a div. Real world engineering has more going on. Interviewers look for those signals, so better work on getting them right.
Naming is also something that the team needs to decide on. As an interviewee applying for a position in an existing team, I would not expect to get dinged on my naming of variables for a piece of demo code. I would expect to conform to the team's existing naming standards, so bringing and displaying my own preconceptions would be completely useless.
I’m not talking about capitalization, I’m talking descriptiveness, meaning, precision etc. You know, naming.
The idea that naming is about someMethod vs Some_Method is nuts to me. Just choose a thing and do it. Naming is about words and meaning. It’s hard, and it’s important.
So was I. Maybe next time respond to my actual words, not your slimmed-down interpretation of them? Some teams are perfectly ok with single-letter local variables, some are not. Some teams are perfectly ok with single-letter parameter names, some are not. Some APIs I've worked on even specified the units in quantity parameters (e.g. HeightInMeter, WeightInMilligram), others would only specify that in the documentation (if you're lucky).
Naming is about words and meaning. It’s hard, and it’s important.
When working on a piece of throwaway pseudo-code, no it's not important.
Every interviewer seems to have their own idiosyncratic version of what they consider "table stakes". So table stakes ends up being everything and nothing.
> I can completely imagine a company rejecting a candidate because they didn’t care about naming.
Didn't "care" about naming, or didn't focus on naming in some little throwaway sample code for a job interview?
When you’re an interviewer you have to make a decision based on way too little signal. This means you zoom in on the things you do see, and you accept the chance that you might reject a great candidate. I can completely imagine a company rejecting a candidate because they didn’t care about naming.
Now if you think “worried that candidate might have negative productivity due to careless attitude, soft reject” is obnoxious then fine but I think that makes you spoiled. You’re not entitled to a job, even a junior position, simply because you can write a loop or center a div. Real world engineering has more going on. Interviewers look for those signals, so better work on getting them right.