Comment Re:I guess you either live somewhere that's warm (Score 1) 557
I'm in Canada, so it gets cold. But I don't think I let my bedroom get down to 5C though - high single digits before the thermostat kicks in at night.
it's still a lot of mercury in the landfills.
I don't have a source here, but i thought i read somewhere that the average can of tuna has more mercury than what's in a modern CFL. Hmm. or was it here: http://green.yahoo.com/blog/the_conscious_consumer/70/three-cfl-myths-busted.html
Age brings experience, but there's plenty of energetic younger folks out there who are great at PRETENDING to have experience. Sure, they have no clue what they're talking about half the time, but they always impress the management.
*sigh*
Haha. yep. I completely agree. There's a big difference between knowing the semantics of a language/paradigm/system and being able to know/understand the nuances of it. It's the nuances that will get you every time...
The difference between the computing industry and the other industries you mentioned is that computing is hundreds of years younger, and thus changing orders of magnitude faster. Medicine comes the closest because of continuous research, so doctors are required to stay current with continuing education (they have to do this to maintain certification).
I have a huge problem with this. The computing industry is younger, but I don't think it's changing that much faster - a lot of "new" concepts are just recycled old concepts! Albeit wrapped slightly differently. E.g. are dumb terminals and thin clients that much different? What about, as someone else noted, worker threads and local storage? Is the concept of local storage much different than caching? And I distinctly recall being taught about threaded programming in the 1990s. The big difference now is that there is a lot more resources than before. So the current crop of applications don't really have to be developed with as much care as older code. More resources -> more resources to waste. I would consider myself an early career developer, but i've seen a lot of good and bad code from old and new developers. And I find that it's more often the newer ones that tend to rush code and leave things incomplete.
The whole idea of LAMP is that it's an easy-to-learn, easy-to-deploy stack. Any competent developer should be able to learn this, quickly. Even if you could assign a "LAMP Competence Metric" (say a 0-10 scale) to a person, a competent developer who is a 2 in LAMP will be a 9 much more quickly than an incompetent developer who is currently a 6.
When I hire coders, I like to see how quickly they can understand a system via standard UML architecture diagrams. I like to see if they can implement a basic logic task using their choice of language, and I want that implementation to be straightforward, and I want it to use the coder's chosen language's foundation libraries instead of reinventing the wheel.
I also like to get a feel for how experienced they are in working with any of the various system development processes. (Hint: "What's that?" is a bad answer. Cowboy Coders are unwelcome at my company.)
Regarding testing basic computer science concepts, I like to ask candidates to differentiate one thing from another. For example, given your list of concepts ("BNF, data normalization, OOP, MVC"), I'd ask:
I like this approach a lot. We've hired people who scored off-the-chart in standardized tests, but were completely unable to work within our relatively regimented development environment. I think the key things are work ethic (it'll be great if they could demonstrate their work ethic in multiple situations professionally or not), and the ability to learn abstract concepts and then apply them. Whatever they don't know when they start the job, they will be able to pick up. That is, of course, you require someone to be productive right away. I try not to ask "what is this?" or "define this" type of questions, but I try to ask problem solving questions to see their problem solving skills.
"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight
