On the one hand, I understand that -- I'm well aware of the flood of slush-pile resumes one can easily get. (My boss at Convoq listed a position on Monster exactly once, and regretted it horribly.) OTOH, my observation is that it's most often the wrong criteria.
I seriously mean that I (speaking as our UI Architect) don't *care* whether a UI programmer has Flex experience; I don't even care all that much whether they have UI programming experience, although that's mildly helpful. I care enormously whether they have a proven track record of developing good software; can work independently; have a curious mind and a passion for improving themselves in programming; understand the common underpinnings (ranging from design patterns to refactoring to threading to unit testing); *enjoy* programming as an artform; and so on. It's easy to teach such a person what they need to know for a particular problem; it's hard to teach a weak specialist how to program well.
*If* the initial weeding produces enough candidates that some will have the above criteria, then that may make sense. But I've observed that a disturbingly large fraction of people who self-identity as "QA programmers" or "UI programmers" or "Web programmers" or such are basically lousy programmers who happen to know a library. So this style of weeding may wind up throwing out most of the *best* candidates, due to incorrect focus. You can wind up with a more tractable pile, but all of them bad.
And just to underscore this: that slush pile is typically made up *heavily* of these people. The really talented generalists are the ones you have to search hard for, because everybody wants them. Crappy specialists are a dime a dozen, and often the first to get laid off when times get rough...
no subject
I seriously mean that I (speaking as our UI Architect) don't *care* whether a UI programmer has Flex experience; I don't even care all that much whether they have UI programming experience, although that's mildly helpful. I care enormously whether they have a proven track record of developing good software; can work independently; have a curious mind and a passion for improving themselves in programming; understand the common underpinnings (ranging from design patterns to refactoring to threading to unit testing); *enjoy* programming as an artform; and so on. It's easy to teach such a person what they need to know for a particular problem; it's hard to teach a weak specialist how to program well.
*If* the initial weeding produces enough candidates that some will have the above criteria, then that may make sense. But I've observed that a disturbingly large fraction of people who self-identity as "QA programmers" or "UI programmers" or "Web programmers" or such are basically lousy programmers who happen to know a library. So this style of weeding may wind up throwing out most of the *best* candidates, due to incorrect focus. You can wind up with a more tractable pile, but all of them bad.
And just to underscore this: that slush pile is typically made up *heavily* of these people. The really talented generalists are the ones you have to search hard for, because everybody wants them. Crappy specialists are a dime a dozen, and often the first to get laid off when times get rough...