4 ms·

I got asked how to center a div in an interview and got dinged for some class naming issues Tech interview industry really misses the point sometimes

skrebbel 3y ago
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.
- lapcat 3y ago
  > Personally I’d be hard-pressed to move an applicant with a less-than-obsessive attitude to naming forward to the next round. Why would you assume that impromptu interview code would be the same as production code?
  - stanleydrew 3y ago
    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.
    - lapcat 3y ago
      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.
  - Kiro 3y ago
    I would assume it to be much better than production code.
  - lopkeny12ko 3y ago
    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.
    - lapcat 3y ago
      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.
- gl-prod 3y ago
  I mean if there is no format to follow I should use my own. Once inside the company I would follow their format or whatever.
- ZanyProgrammer 3y ago
  Nice, another comment showing the utter obnoxiousness of programming interviews.
  - skrebbel 3y ago
    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.
    - tremon 3y ago
      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.
      - skrebbel 3y ago
        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.
- Theodores 3y ago
  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. With CSS grid you don't need div elements, ever.

skrebbel 3y ago

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.

lapcat 3y ago
> Personally I’d be hard-pressed to move an applicant with a less-than-obsessive attitude to naming forward to the next round. Why would you assume that impromptu interview code would be the same as production code?
- stanleydrew 3y ago
  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.
  - lapcat 3y ago
    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.
- Kiro 3y ago
  I would assume it to be much better than production code.
- lopkeny12ko 3y ago
  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.
  - lapcat 3y ago
    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.
gl-prod 3y ago
I mean if there is no format to follow I should use my own. Once inside the company I would follow their format or whatever.
ZanyProgrammer 3y ago
Nice, another comment showing the utter obnoxiousness of programming interviews.
- skrebbel 3y ago
  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.
  - tremon 3y ago
    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.
    - skrebbel 3y ago
      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.
Theodores 3y ago
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. With CSS grid you don't need div elements, ever.