I personally think really a lot of abilities that help you perform well in job also help perform well in coding tests. But it of course also depends how coding interview is done from interviewer side.
I see coding interview more like a pair programming session. While problem is synthetic the methods used to problem solve and the skills that are exposed during this session are all relevant to day to day job.
I had chance to run a number of code interviews over last couple months, and most common problems were:
Poor communication - inability to express ideas in words, for example I have seen candidates who would explain their ideas literally by citing a pseudo code - this in turn leads to very inefficient communication and candidates lose a lot of time
No communication at all - candidate just writes code without explaining and after running out of time code just doesn't work. If candidate would had communicated his idea I would had helped and rejected it and saved a lot of time. It's faster to solve problem on conceptual whilst brainstorming and testing number of different ideas with interviewer before delving into coding.
Not listening to feedback, for example I would see a bug, I would ask candidate to explain how this line works, they would explain one thing, I'd say I'm not convinced it works this way, but they would stuck their head in sand and would insist on their own belief and come back to that line later after wasting 10-20 minutes debugging
Not being able to simplify code, for example candidate has idea how to solve it, but writes code that's too complicated and runs out of time debugging it
Being lazy and skipping on decent naming and keeping code simple and readable: sometimes candidates make subtle bugs in conditional statements while putting numeric constants straight in code or by writing conditions that are just too long. These types of bugs are easy to see with good naming but very hard to notice when naming is poor or when naming is not there and numeric values are put right into long if statements. Before coding interview begins I always remind to keep code clean, use good naming, as this would help the candidate and also will help me spot bugs - if I see easy to spot bug - I always help - unfortunately I'm not a robot and can't spot bugs in a messy code.
I think neither of this is in any way some esoteric situation. It's just daily work stuff. On top of that if problem is really more on esoteric side and has some things that candidate needs a "click" in brain to happen, I try to do my best to help guide them so that this click would happen.
When I think of daily work stuff I think of doing a feature and PR review.
A common alternative I hear to a whiteboard interview, or a coding challenge is a take home project.
A take home project can not only test more relevant skills, it also provides a more real-world experience for everyone. With PR-like feedback the experience would also provide a similar setup to a work environment, and allow you to uncover all those problems you described above.
This is all without all the stress you'd get from needing to code/solve a problem immediately while someone else watches.
I'm not saying all companies should do this, or that all companies could do this, but it does seem more reasonable and relevant than dropping someone into some "test environment" and pointing out the similarities, rather than just putting them into a real world "work environment" and having a guardrails setup (fake inputs, fake data, relevant but fake project).
exactly the same will happen when they are part of your team, no matter if they work from home or sit in an office. Doesn't matter much when they deliver good quality.
Getting paid by time spent is not much better than getting paid by lines of code, but it seems to be the most common measurement in our business somehow.
I think it's the other way around. Company is much more intetested in someone who can do a task in an hour, than in one that can do same stuff in 8 hours.
The last bullet point:
have you run across companies that seem to not care about or even think programmers should be able to read and comprehend and manage bad naming and obscure code such as literal numeric constants in conditions?
It sometimes feels like I get the short end of the stick either way:
if i try to push for better naming, both when it's already written and preventively as a matter of following best practices, I'll get resistance, but it ends up taking me longer to do a task and this will occur whenever i try to read various coworkers' obscure code
it also feels like companies and managers want me to be able to deal with such code anyway, or i won't get the job / project contract
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I personally think really a lot of abilities that help you perform well in job also help perform well in coding tests. But it of course also depends how coding interview is done from interviewer side.
I see coding interview more like a pair programming session. While problem is synthetic the methods used to problem solve and the skills that are exposed during this session are all relevant to day to day job.
I had chance to run a number of code interviews over last couple months, and most common problems were:
I think neither of this is in any way some esoteric situation. It's just daily work stuff. On top of that if problem is really more on esoteric side and has some things that candidate needs a "click" in brain to happen, I try to do my best to help guide them so that this click would happen.
When I think of daily work stuff I think of doing a feature and PR review.
A common alternative I hear to a whiteboard interview, or a coding challenge is a take home project.
A take home project can not only test more relevant skills, it also provides a more real-world experience for everyone. With PR-like feedback the experience would also provide a similar setup to a work environment, and allow you to uncover all those problems you described above.
This is all without all the stress you'd get from needing to code/solve a problem immediately while someone else watches.
I'm not saying all companies should do this, or that all companies could do this, but it does seem more reasonable and relevant than dropping someone into some "test environment" and pointing out the similarities, rather than just putting them into a real world "work environment" and having a guardrails setup (fake inputs, fake data, relevant but fake project).
With take home tasks problem is that some candidates would spend 1 hr others might spend whole day.
exactly the same will happen when they are part of your team, no matter if they work from home or sit in an office. Doesn't matter much when they deliver good quality.
Getting paid by time spent is not much better than getting paid by lines of code, but it seems to be the most common measurement in our business somehow.
I think it's the other way around. Company is much more intetested in someone who can do a task in an hour, than in one that can do same stuff in 8 hours.
The last bullet point:
have you run across companies that seem to not care about or even think programmers should be able to read and comprehend and manage bad naming and obscure code such as literal numeric constants in conditions?
It sometimes feels like I get the short end of the stick either way: