Joined
·
11,665 Posts
You can't unless you give them work and you review that work. I don't mean code on stupid paper for 10min like most interviewers do, but give them work for a month, some project, etc. to do the job and then review.
This difference between people is very easy to see at University where everyone has to do the same thing but the results vary wildly in performance, readability, bugs, reusability. Most people just do the bare minimum to pass and this for sure translates into their work ethic too.
There are people who are good at memorizing rubbish and writing memorized crap on paper and then there are other who suck at this but excel at problem solving, designing and writing fast readable code on a computer.
In the end it seems most companies are looking for coding monkeys with a knowledge of some language to implement/code, not to be programmers, developers, to solve anything, to think, nope, just code.
Error handling, for sure, the lazy ones don't bother or even realize that something could go wrong.
I've had a test image to feed a program that many people implemented, this test image was larger and more random than what most people would bother to think of... as a result two of us could process the image in around 1 second, others would take days, weeks, months or outright crash because they ran out of RAM etc.
1) you can only know where you lie on the spectrum by comparing yourself to others in different areas
2) by comparing the other person's results
Most of the optimizations mentioned are pointless unless you test performance in specific language and implementation as often the compilers nowadays are not what they used to be in 80s, 90s and do a lot of optimizations on their own and your "clever" optimizations may actually work against it and make less readable/understandable code. Divide by 2 using bit shifting? Why? What compiler does not optimize this for you to the same fastest code?
This difference between people is very easy to see at University where everyone has to do the same thing but the results vary wildly in performance, readability, bugs, reusability. Most people just do the bare minimum to pass and this for sure translates into their work ethic too.
There are people who are good at memorizing rubbish and writing memorized crap on paper and then there are other who suck at this but excel at problem solving, designing and writing fast readable code on a computer.
In the end it seems most companies are looking for coding monkeys with a knowledge of some language to implement/code, not to be programmers, developers, to solve anything, to think, nope, just code.
Error handling, for sure, the lazy ones don't bother or even realize that something could go wrong.
I've had a test image to feed a program that many people implemented, this test image was larger and more random than what most people would bother to think of... as a result two of us could process the image in around 1 second, others would take days, weeks, months or outright crash because they ran out of RAM etc.
1) you can only know where you lie on the spectrum by comparing yourself to others in different areas
2) by comparing the other person's results
Most of the optimizations mentioned are pointless unless you test performance in specific language and implementation as often the compilers nowadays are not what they used to be in 80s, 90s and do a lot of optimizations on their own and your "clever" optimizations may actually work against it and make less readable/understandable code. Divide by 2 using bit shifting? Why? What compiler does not optimize this for you to the same fastest code?
