3 ms·
Nice counterpoint, but you are making a some assertions here that don't seem to follow - So you say there are developers who are good at putting lego bricks to
by shubb 13y ago
Nice counterpoint, but you are making a some assertions here that don't seem to follow -
So you say there are developers who are good at putting lego bricks together to solve business problems, but introduce bad, unmaintainable code because they are bad as engineers.
You say algorithms questions are a good way to identify them.
To me, algorithms questions show that you studied CS in an academic setting, and listened in class.
People who introduce bad code do so because:
* They 'don't have time to do it right', the root of this being that they lack the confidence or judgment to say a task will take longer.
* They lack experience maintaining code, or haven't learned the skills to write maintainable code. This happens wen people have mostly worked alone, and can be rectified by working closely and under someone good who reviews their output for a while. CS school does not teach this.
* They 'have not heard of' things that 'should be' common knowledge, e.g. unit testing. Fresh graduates often lack 'common knowledge', as do people who worked a long time in a role that just used some specific, older stack.
With all these problems, the way to fix them is to properly monitor and understand people on a team, but also they must have the humility to take advice. I'm guilty of identifying too much with my code sometimes, but we've all seen people who get very very defensive.
Look, I'm all for discriminating against people who didn't study CS. It keeps my wages up right. But if you are trying to solve this problem you describe, surely identifying the actual cause of what is bad about these candidates is a better idea?
- timr 13y ago"People who introduce bad code do so because....they 'don't have time to do it right'....they lack experience maintaining code, or haven't learned the skills to write maintainable code....they 'have not heard of' things that 'should be' common knowledge" Those are all things that happen. But you're missing the most dangerous one of all: programmers who just don't understand how computers work. It's a surprisingly common problem, and it's a problem that algorithmic questions are especially good at identifying quickly. Hire these people at your peril, because while they are fine for simple tasks, they generally have no idea why their code is fast or slow, have no idea why their programs eat memory like a hog, and no idea how to begin to break down a difficult problem in a way that a computer might be able to handle efficiently. Give them a hard problem, and you might get something good....or you might get total garbage. It's programmer roulette. Programmers who don't understand computers are terrifyingly bad hires, because they can do the most damage before you catch them.