Ask Slashdot: Best Certifications To Get? 444
Hardhead_7 writes "Our recent discussion about how much your degree is worth got me thinking. I've been working in the IT field for several years now, but I don't have anything to my name other than an A+ certificate and vendor specific training (e.g., Dell certified). Now I'm looking to move up in the IT field, and I want some stuff on my resume to demonstrate to future employers that I know what I'm doing, enough that I can get in the door for an interview. So my question to Slashdot is this: What certifications are the most valuable and sought-after? What will impress potential employers and be most likely to help land a decent job for someone who doesn't have a degree, but knows how to troubleshoot and can do a bit of programming if needed?"
College (Score:0, Insightful)
A degree. Seriously. If you're not willing (or able) to get a degree, what certs are valuable are going to depend heavily on what exactly they're looking for. People hiring for a network admin position are going to value things like Cisco certs much more than A+, while someone hiring for a generalist IT position in a small company might be the other way around.
You really end up with two non-degree options: try to specialize and get as many (and as advanced) certs as possible in a narrow area and then try to find a related job, or generalize yourself and try to keep getting certs in areas you haven't yet covered, and look for a generalist job. The specialist job will likely pay better, but it may be easier to find work as a generalist.
Certifications don't impress... (Score:5, Insightful)
Re:Certifications don't impress... (Score:3, Insightful)
Certifications don't impress, however they do get you past the HR filter so you get to speak to someone to whom your experience is relevant. No Certs, no interview, no chance to shine.
Start your own cert organization. (Score:4, Insightful)
It's far more impressive to be the guy that certifies people than the guy who gets a cert.
And that way you can give yourself all the coolest sounding ones.
And if you can convince a few people to buy your cert, it'll not only make you money, but give your certification body even more prestige; because everyone who buys your cert will be hyping it as "really valuable" on /., etc.
Uh, first things first (Score:4, Insightful)
What kind of job do you want?
J. D. * (Score:0, Insightful)
Screw that. Pass the bar, and be assured of employment (real employment, as in a career instead of a job) for the rest of your life.
Even a CISSP means jack these days, all it means is that you get to duke it out among the other guys with the CISSP certs for the crumbs left over that the H-1Bs have not taken.
Other than a law degree, I do notice people with H-1B "certs" always get the plum positions in most companies.
Re:J. D. * (Score:5, Insightful)
H1-B, cos US grads no engineers, anymore.
Re:Depends on who is hiring (Score:5, Insightful)
A bit off topic, but you triggered something I've been thinking about for a couple of years. That "spark" is fluency.
I swtiched jobs from being a computer programmer to being an ESL teacher in Japan. Japan is somewhat famous for churning out students who know a lot *about* English, but can't order a drink at Mac Donald's. We used to have a name for those kinds of people with regard to programming languages: language laywers. They can answer any question you put to them *about* a programming language, but couldn't program to save their life. These people often make it past job interviews easily, but then turn out to be huge disappointments when they actually get down to work. I've read a lot about this problem, but the more I look at it, the more I realise that these disabled programmers are just like my students. They have a vocabulary of 5000 words, know every grammar rule in the book but just can't speak.
My current theory is that programming is quite literally writing. The vast majority of programming is not conceptually difficult (contrary to what a lot of people would have you believe). We only make it difficult because we suck at writing. The vast majority of programmers aren't fluent, and don't even have a desire to be fluent. They don't read other people's code. They don't recognise or use idioms. They don't think *in the programming language*. Most code sucks because we have the fluency equivalent of 3 year olds trying to write a novel. And so our programs are needlessly complex.
Those programmers with a "spark" are programmers who have an innate talent for the language. Or they are people who have read and read and read code. Or both. We teach programming wrong. We teach it the way Japanese teachers have been teaching English. We teach about programming and expect that students will spontaneously learn to write from this collection of facts.
In language acquisition there is a hypothesis called the "Input Hypothesis". It states that *all* language acquisition comes from "comprehensible input". That is, if you hear or read language that you can understand based on what you already know and from context, you will acquire it. Explanation does not help you acquire language. I believe the same is true of programming. We should be immersing students in good code. We should be burying them in idiom after idiom after idiom, allowing them to acquire the ability to program without explanation.
Re:Vodka! (Score:4, Insightful)
ISO9k, ISO20k, ISO27k... hell, anything with ISO in front of it will be a foot in the door to a career.
Realize, though, that you will not be productive anymore. You will spend your time designing processes, forcing it down the throat of the affected departments against the best resistance they can muster and spending the rest of the time finding out how they managed to circumvent and ignore them. Especially for the 27k flavor.
If you do not like meetings, if you do not like playing bullshit bingo, if you do not enjoy being "that asshole that makes everything complicated", do not apply.
Re:Hide them! Admit nothing! (Score:5, Insightful)
It's the same reason I refuse to hire anyone who graduated highschool; in fact I usually prefer people who misspell half their CV, it shows they haven't wasted their time on useless things like educating themselves and have instead focused on what's important: Experience!
Re:Vodka! (Score:4, Insightful)
There are good process managers and bad ones. The good ones will probably increase your overhead, much like the bad ones, but not unnecessarily so. For example, the much-dreaded pressure to write documentation and (the cheek!) even requiring its review as a major process point. Yes, that increases the time necessary to complete the job. But it keeps the product serviceable after 3 years when every programmer who wrote it left and nobody really knows anything about the inner workings anymore.
Likewise, requiring a strict distinction between production, test and live system increases overhead. But it also increases stability and manageability of the whole mess, especially in huge projects with different departments adding to them.
The examples are numerous and I am sure everyone who ever wrote code in an environment consisting of more than a handful developers and users will know a few more cases where suddenly some process dork butted in and you wondered who died and made the idiot king.
The key difference between a good and a bad process manager is that the good one will notice that "one size fits all" does not apply for processes. There is not one development process. There are several, depending on the size of the project, the departments involved, the security requirements, the external requirements, not to mention compliance and legal problems. Using one process for all of them necessitates to use the all-encompassing full blown pearly king process with all bells and whistles attached, which is absolute overkill for probably 90% of the projects a company might have. Good processes are modular and can be assembled from process building blocks that fit neatly into each other to ensure that every project has every base covered, and nothing else.
This does of course also require top notch project managers who know how to decide which project process to use for what project. Again, a good process manager will give him the tools to determine which one is to be used.
Sadly, usually the process manager is someone in the company who has actually other things to do than to design processes, it's usually something some poor idiot gets tossed into on top of his actual work (because the company doesn't really want to get working, reliable processes but just needs some certificate that depends on having such processes). This is a nightmare. Because the processes will have little, if any, semblance of reality, people will learn them by heart for the audit then forget them immediately, because they are simply not workable.
I am fairly convinced that you're subject to such processes.
It is quite possible to create good processes that do actually help you instead of hindering you, that ensure that you get good specs, that ensure that you get resources timely and sufficiently, that ensure that production doesn't suddenly grind to a halt because someone "forgot" to do something (and guess who gets to work crunch overtime to make it up). They can actually make life a lot easier, if done right.
Or a lot harder, if not.