I'm a little bit infamous for playing devil's advocate on this topic around here, but I think it's worth pointing out: a developer whose work touches seven topics had better know enough about those seven topics to not be a liability. Most of the worst blunders in computer history were because some developer didn't understand their client.
That is not to say that we should be experts, but there is a balance. Software that works over the network needs a developer with a working knowledge of networking. Air Traffic Control software must be written by someone who knows how ATC works. Software for scientific-calibre light microscopy requires the developer to be comfortable with the concepts and terms in light microscopy. Accounting software should be written by developers who have a working understanding of accounting. And the list goes on.
One might say, "Baloney! That's the client's job!" But if we're honest, because we're the programming experts, it's our job to know what the client needs in the software when they don't. We need to inform their choices, and they ours. If that's missing, terrible software results.
Now, stepping back from that, is there a problem with HR departments expecting developers to know everything about everything? Yup. Can that improve? Yup.
Yet, between the two standpoints, we also have to consider: how certain are we that those questions were the deciding factor in our not getting particular jobs? HR rarely tells us candidates anything. It could well be that we were the second or third choice on the list, but some other guy had valuable related experience that we didn't.
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'm a little bit infamous for playing devil's advocate on this topic around here, but I think it's worth pointing out: a developer whose work touches seven topics had better know enough about those seven topics to not be a liability. Most of the worst blunders in computer history were because some developer didn't understand their client.
That is not to say that we should be experts, but there is a balance. Software that works over the network needs a developer with a working knowledge of networking. Air Traffic Control software must be written by someone who knows how ATC works. Software for scientific-calibre light microscopy requires the developer to be comfortable with the concepts and terms in light microscopy. Accounting software should be written by developers who have a working understanding of accounting. And the list goes on.
One might say, "Baloney! That's the client's job!" But if we're honest, because we're the programming experts, it's our job to know what the client needs in the software when they don't. We need to inform their choices, and they ours. If that's missing, terrible software results.
Now, stepping back from that, is there a problem with HR departments expecting developers to know everything about everything? Yup. Can that improve? Yup.
Yet, between the two standpoints, we also have to consider: how certain are we that those questions were the deciding factor in our not getting particular jobs? HR rarely tells us candidates anything. It could well be that we were the second or third choice on the list, but some other guy had valuable related experience that we didn't.