I wasn’t there so I can’t judge, but if you got dinged about naming then maybe they interpreted that as you caring about “it works” but not about “team member reading the code understands why it works”.
Personally I’d be hard-pressed to move an applicant with a less-than-obsessive attitude to naming forward to the next round.
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?
It's of course not the same. But technical interviews aren't always just about "does this solution you wrote actually work." A good interviewer will be paying attention to how you solve the problem and how you communicate the choices you make along the way. Good naming is part of good communication.
Except every interviewer has their own idiosyncratic criteria in their own mind, and they rarely practice good communication themselves by telling the job application ahead of time what those idiosyncratic criteria are exactly.
If you're not putting forward an honest effort for writing code that resembles code you'd be comfortable putting into production during an interview, then I'd pass on hiring you too.
And yet so many interviewers say, "We don't care whether the code is perfect, we just want to see how you think."
The insanity for job applicants is that you never know which kind of interviewer you're going to get until it's too late. Every interviewer has their own nitpicks, yet they somehow believe that their specific nitpicks should be assumed to be universal requirements.
And then hiring managers complain that good programmers are difficult to find, lacking the self-awareness to see how many candidates they arbitrarily exclude for dumb reasons. I've seen people say "I'd pass on a candidate for X" for more or less all X.
I would have failed too, however, the reason would be because of my insistence that there is always a better element to use. It even says so in the specification.
Personally I’d be hard-pressed to move an applicant with a less-than-obsessive attitude to naming forward to the next round.