Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Certifications are dumb.

by dragonchild (Archbishop)
on Apr 08, 2008 at 17:15 UTC ( #679020=perlmeditation: print w/replies, xml ) Need Help??

I've been re-reading a number of old threads, notably the ones about Perl certification. There are (nominally) good reasons for creating a Perl certification process. These are similar reasons why most people want to see a 4-yr degree (or equivalent) and they boil down to "You can actually finish something." Now, personally, I think seeing someone manage a CPAN project (or be vouched by someone who has) is a stronger indication of usefulness, but that's beside the point. And, more importantly, that's not the reason everyone seems to be giving. Everyone seems to be talking about PHBs and what they do(n't) understand.

Recently, I started my own company and am working through how we're going to hire people in 6-12 months for our first development team. I'm also giving a lot of thought to what kind of company culture we're going to be creating, for both the IT staff and the (much larger) non-IT staff. And, given that most of the staff won't be in my competency (which is good!), how I plan on measuring their fitness to be part of my company.

What I've come up with (which has yet to be tested) looks to be a variant on the "What do you have on CPAN?" metric. I really don't care about what tests you've passed. I also don't care (much) about where you've worked (unless they also use this metric). What I really care about is what you can show me you've done. Because, at that point, I can now measure to see how you work will be helpful for what I need to have done. I want to see things like:

  • Are you creative (for jobs that require creativity)?
  • Are you steady (for jobs that require steadiness)?
  • What do your peers think about you?
  • How long you have worked at places and why you left prior employers.
  • Are you a team player or a loner?
  • Do you work days or nights?
  • And, most importantly, I need to know how well you communicate and how driven you are.

None of these things are deal-breakers. No-one is a perfect fit for a job. The key is for management to know where your weaknesses are so that they can adjust the job to you. If you don't let me know, I can't make your working experience better for you. Remember - I, the manager, am taking a risk by hiring you. You will be near-worthless for the first 8-12 weeks. You won't hit your stride and be fully integrated until the end of 6 months, period. At roughly $80/hr (the total of salary, benefits, your workspace cost, etc), that's a $25k-$40k investment up front with little, if any, return. I most likely don't recoup my investment until at least 8 months have passed. I don't make significant money until a year has gone by.

Given that, I have a huge incentive to make sure you're as productive as you can be by giving you tasks that play to your strengths and avoid your weaknesses. And, that also makes you happier, which means you'll stay longer. I can't do that unless I know what your weaknesses are. Certifications won't tell me that. Only your projects will. When I was in the market, I always used certification requirements as a measure of how much I didn't want the job. As an employer, I will likely use certifications as a discount on your employability by my companies.

(Of course, this doesn't count certifications required to practice the craft, such as CPA.)

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Replies are listed 'Best First'.
Re: Certifications are dumb.
by Your Mother (Archbishop) on Apr 08, 2008 at 20:17 UTC

    I also think you rule and would love to work in the type of environment for which you strive. I want to air out this one:

    • Are you a team player or a loner?

    This boils down to-

    • Are you a yes man or a trouble maker?
    • Are you a sheep or a free thinker?

    Team player != good collaborator. Little, if any, genius in history has come from teams, but almost all of the bad stuff in the world does. A friend of mine says, "The IQ of a meeting starts at 100 and drops 5 points for every person present."

    I'd rather have a workforce 10 friendly "loners" than 100 "team players." The idea of team encourages the idea of group responsibility. The idea of group responsibility discourages achievement, self-satisfaction, and the kind of person who believes in taking responsibility for one's own mistakes and successes instead of "that guy" which every "team" has and everyone but HR and the manager knows is dragging the place down. Star players tend to change teams so often for just this sort of reason.

    I'd also like to air out this from tinita above:

    you realize that everybody has weaknesses.

    I don't realize that and I can't believe everyone just swallows this pill without so much as a grain of sugar. People, like things, have right places and wrong places. What's a scalpel's weakness? That it can't cut a sandwich without making a mess? People are the same. Managers should try very hard to get people into the places they belong. The right person in the right job might have no "weakness" at all. The right person in the right job can create such a surplus of productivity that it covers for the 5 employees who stumbled through life into career paths for which they have no talent, no drive, and no affection.

    Oh, and I guess a comment on this one too-

    (Of course, this doesn't count certifications required to practice the craft, such as CPA.)

    Malpractice kills something like 100,000 people a year in the US. Some estimates go quite a bit higher too. What better "certificate" than a degree 6-12 years in the making with 1-3 years of on the job training afterwards? Since even that can't be reliable, all certs are suspect. (I know you know this, just bringing it up; the legal requirement for a cert changes nothing.)

    Whew! On the other points I especially appreciate this: "Do you work days or nights?"

    Some, me included, simply do better, more focused, work at night. Fewer distractions. Fewer things to do instead. Little to no chance of being interrupted when in the middle of a sticky problem.

    The fact that you're thinking this stuff through, without a top 10 list from Business 2.0 or some shite, puts you at the head of the management class already. If you weren't in OH I'd probably be private msg'ing you right after this. :)

      While the "lone ranger" archetype is very emotionally appealing, it must be remembered that a company is an engine that produces money. Nothing more, nothing less. As such, all decisions have to be made in terms of what will have the greatest ROI (Return On Investment). So, let's examine what is, in my experience, the most common "lone ranger" ROI.

      There are 3 people on the team. Each person brings a ROI of $50k (meaning that the company gets $50k of value above what the company pays). The network effects each brings an additional $100k per connection. So, that's a total of $150k + $300k for $450k. Let's add the fourth person.

      • If that person is a team player, then we get $50k for him plus $400k from the network effects.
      • If that person is a lone ranger, then we get $250k for him plus $0k from the network effects.

      That lone ranger just cost me $200k, even though he is personally 5x better. No, thank you.

      As for malpractice ... I have a different take on that. Personally, I think that the risk of dying due to malpractice in the US is about on par with the risk of dying in an airplane. Now, I have no proof for this, but consider the following points:

      1. Most people who die in a doctor's care either would die within a year or should have died already.
      2. That 100k is out of how many people who see a doctor each year?
      3. How likely are those people to have kept themselves healthy prior to seeing a doctor?
      4. What is the incidence of malpractice death in other countries, specifically Scandinavia, Japan, and China? </oll>

        Puts that number into perspective, doesn't it?

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

        I think that the risk of dying due to malpractice in the US is about on par with the risk of dying in an airplane. Now, I have no proof for this, but...

        A couple links:

        From the first, I infer that there are about 100 deaths per year in airplane accidents (I get this from a 50,000 number of deaths in auto accidents and a statement that there are 500 times more of those than airplane deaths).

        The second says medical errors kill 195,000 per year in the US.

        These are certainly not indisputable sources, but they'd have to be pretty far off for the inequality to go the other way.

        I know what you mean but there is a huge amount of HR-marketing-sprak stuck in all that stuff. I have learned to shut my mouth in certain circumstances because team players don't say, "that's a mistake, it's gonna cost us down the road." Not every job but in a few it has been less risky for me to let everyone make mistakes than it is to fight to do a good job. I'm not a lone ranger. I love supporting others and stuff like pair-coding. Love it. But that is not what people mean when they say "team player." They mean committee -- don't ask embarrassing questions, don't make waves, don't be different, don't stick your head out or it's for the chop. This is a huge productivity, talent, and enthusiasm killer. I always think of the scene in the "The Adventures of Baron Munchausen" remake where they execute Sting.

        Most people who die in a doctor's care either would die within a year or should have died already.

        You are insufficiently jaded. :) E.g., 80 people die every day in the US from bad prescriptions. I'm from a family of medical people. I could tell you toe-curling tales of incompetence like patients waking up in the middle of thoracic surgery because the anesthesiologist was too busy chatting up a cute nurse to do his job right. A *large* majority (was large 20 years ago anyway, one can hope it's not close to 90% anymore) of doctors fall into at least one of these: alcoholic, smoker, overweight; persons who are trained in taking care of people. Lots of surgeons are drunk or high at work. Lots of cops are bullies and racists. Et cetera and so forth. I wanted to pull a punch line out of that but it's not even darkly comedic right now. :( Part of what "team player" means to me is "look the other way for the team." Maybe I'm overly jaded but I find the term hopelessly corrupt.

Re: Certifications are dumb.
by amarquis (Curate) on Apr 08, 2008 at 20:28 UTC

    Most people making hiring decisions don't have the insight you do. To many, the presence of a certificate is a little check box they can mark off, something that makes their job easier. It doesn't help them do hiring better, it just makes it easier. Everybody talks about the PHB because the PHB is typically holding the keys to the kingdom.

    The qualities you are looking for are hard to get at and evaluate. They are better indicators of long term success than a certificate, but honestly most people aren't good enough at evaluating talent to use them.

    Most certifications are an oversimplification of a candidate's abilities. A candidate's skillset is a really complex space that doesn't fold down well into a simple "pass or fail" evaluation.

    Congratulations on your business, and for putting in the effort to find the best fit candidates. It sounds like you are about to make some solid hires :).

      Certificates don't make the IT hirer's job easier. If anything they make it harder by introducing a faulty indicator of quality.

      So why do fools ask for them? Because it gives them an excuse. If they employ someone who turns out to be useless (which they're going to do at some point regardless of certification, because no interview and filtering process is perfect) then if there's a certificate they can at least point at it and whine "but XYZ authority figure said he was OK" and then *their* boss will give them the benefit of the doubt.

      Certificates are, in IT, arse-covering material for the hirer, nothing more.

Re: Certifications are dumb.
by mr_mischief (Monsignor) on Apr 08, 2008 at 17:45 UTC
    It sounds like you'd be a great boss. Where do I apply?

    I mentioned my feelings on this topic just a couple of minutes ago over at Re: Certification In PERL.

    If someone is clueless about the work and also clueless about how to assess readiness for the work, then a bare minimum paper certificate from a reputable certifying body can make sense. Unfortunately, that's not where most tech certificates come from.

    Novell, Cisco, Sun, and perhaps even Microsoft and CompTIA certifications can mean something. What they mean is minimal, though, and their meaning is often blown out of proportion. Dell and HP's hardware technician certs require familiarity with their lines, but not having them doesn't mean one is not a great hardware technician. The Perl certifications available don't even come to these standards, and therefore mean even less.

Re: Certifications are dumb.
by zentara (Archbishop) on Apr 08, 2008 at 21:02 UTC
    Couldn't we extend that to "College Degrees are dumb"? Especially since most people crammed their way thru, or passed on outragoeus curved grading. Additionally, there is no mandatory 5 or 10 year test to see if you retained any knowledge, or even know what you are talking about.

    As is true with the Skill Certification, the only people making out on college degrees (or certifications) are the issuers, who have effectively created a monopoly on employment. I.E. Pay $100,000 for that 4-year piece of paper, or you don't work. Funny, most college grads don't get work in their fields anyhow...... there are alot of lawsuits out there, by parents who forked over huge amounts of dough, only to have their kids unemployable.

    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
      Most colleges at least make you pass a minimum of 100 to 130 semester hours. At all the schools I was interested in attending, a schedule was 12 to 20 semester hours each semester. An hour's credit meant an hour in class and typically two hours of outside work each week. That's 36 to 60 hours a week for 2.5 to 5 years.

      Where I went to school, every professor thought their classes were more important than the others, so a credit hour actually meant about 4-5 hours per week. That's 48 to 100 hours of work each week. Most people got a minor or a second major, and did about 15 credit hours a semester for 8 to 12 semesters.

      I, personally, left early due to illness and started my career with no degree once I was well. I don't think people who got their degrees are silly, though. I'd like to go back and finish a Bachelor's degree, but probably in a different field now.

      Most of the entry-level certificates require a bright person a month or less of study in their spare time. Yet people in the HR department don't know that. They see "A+, Network+, CNA, CCNA, BrainBench Perl, BrainBench PHP, BrainBench HTML", and they often think they're getting a well-rounded network and web development guru. Little do they know that some of those are drop-the-hot-rock easy and others can be done by any random friend of yours on your behalf with a reference open in another window.

      Some certifications do mean something. The CCIE is one. The bar exam for a state is another. A college degree means a lot in most cases, although the college and the student are both variables in just how much.

        I agree with most of what you say. Based upon my observations, it's natural intelligence, and a desire to be correct,that is more important than a degree. I would say that 90% of all jobs only need an 8th grade level of education( basic reading writing and arithmetic). Sh*t, in nearby Detroit where only 25% of students graduate high school, they can fill all the jobs they need because the kids have a natural intelligence, and can be trained in a few weeks to pickup things. For instance, on a tool setting control, they don't need to know what cm means, just put marks on the scale with a marker pen and tell them " put it on marker 1 for this task and marker 2 for that task".

        The other 10% of jobs go to the people who know how to make the marks, or design and develop the tools. But how many of those people do you really need? We are graduating so many useless college graduates( who all expect cushy high paid jobs), that the old saying is now true...."too many chiefs and not enough indians". This is creating a corporate welfare class, where they are hired into meaningless positions, and do not earn their high salaries.

        It reminds me of what happened in France about 20 years ago, IIRC. They said they were going to limit the number of Phd candidates admitted each year, because there were too many already.

        I'm not really a human, but I play one on earth. Cogito ergo sum a bum
Re: Certifications are dumb.
by tinita (Parson) on Apr 08, 2008 at 19:13 UTC

    like mr_mischief said, you sound like the perfect employer =)

    you realize that everybody has weaknesses. most employers don't realize that motivated people with weaknesses try to develop their strengths.

    but i would like to add that some people have to learn to develop their own modules for CPAN. before a friend of mine had told me about the YAPC::Europe in london i hadn't known much about the perl community. the only thing was compl.lang.perl.*, at least. then i attended a YAPC myself and slowly realized how much fun it can be to develop modules and publish them. so some people need to be pushed there. of course it's difficult to know before.

Re: Certifications are dumb.
by jepri (Parson) on Apr 09, 2008 at 09:43 UTC
    I can perhaps offer a few tips, but let me start with the juicy cynicism first. Don't do interviews. Interviews reward the biggest liar. So most candidates lie, and the ones who don't, rework their past to look better. What kind of idiot would write "Worked at XYZ database company, sucked hard, got fired"?

    The good candidates get left behind, because the kind of candidate who really does know practically everything about a system is the kind of guy who would never, ever, say that.

    So is there no hope? There's some. Go to conferences, presentations and any kind of programmer get together where you can meet programmers in their natural habitat. If you meet a good one, be ready to make an offer even if you don't have a role ready for them. They won't be available when you are ready.

    The best tip though, is to hire physicists. They're cheaper, sexier, smarter, and usually desperate to change careers after they find out how much a PhD scholarship pays, compared to the guy who changes the backup tapes at a computer company. And a degree in a hard science is a 'cert' that still has some credibility left.

    And while I'm busy cluttering up this little box on your screen, allow me to address all the interviewers reading this thread: Stop putting communications questions in the selection criteria. I just went for a sysadmin/dev role where four of the five questions were asking about my communications skills. Here's a tip: if you want to know about my communications skills, pick up the phone and CALL ME. Or leave it till the interview, where I can lie to you in person like a civilised chap.

      I think instead of not doing interviews, if you were encountering the problems you mention, would be to get better at interviewing. Interviewing is not about asking "How good are you at X? How good are you at Y?" You are trying to gather a lot of different information:

      • Is this person's long term goals consistent with my goals for the position?
      • How well does the candidate communicate?
      • Personally, I like to ask what the person has been doing to improve their skills, on their own. Reading books? Working on an open source or their own project?
      • Will this person fit in with my team, and the company at large?

      Amongst other things unrelated to "How well you know X."

      The best tip though, is to hire physicists. They're cheaper, sexier, smarter,...

      Sexier and smarter, certainly, but I don't know about cheaper. Maybe better to say "a better value"? :)

      Go to conferences, presentations and any kind of programmer get together where you can meet programmers in their natural habitat. If you meet a good one, be ready to make an offer even if you don't have a role ready for them. They won't be available when you are ready.

      And that is our plan. The point I was attempting to get across was how one goes about finding those kinds of people in the non-programming world. I can find good programmers pretty easily. Finding good sales staff is a little harder.

      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
        Let me preface this rather authoritative sounding advice with the fact that I've only owned my own business for about a year, but I've seen the success and failure of many small businesses in technical and nontechnical fields. I keep records of my thoughts on every business I have worked for, worked with, applied to, tried to sell to, or bought significant products or services from to evaluate what I want to do for my business. Since it's been my dream to be a business owner for about 20 years (since the 5th or 6th grade), I've been studying business by example and from books for quite some time. Yet I'm nobody's MBA, so take my advice with a grain (or spoonful) of salt.

        If you're doing custom work instead of selling a packaged software product, don't hire salespeople at all. Hire customer service people or technical liaisons. Maybe even consider them "internal customer advocates".

        Salespeople are great at moving something a customer wants but can't decide he wants. They need to know the product line in order to sell it effectively. They're not so good at figuring out what a customer wants outside the specs of given products and when the customer actually wants something else other than what they are asking about. You can't enumerate to your salespeople all the features of your services in a way a nontechnical person is going to understand.

        The tech support guy who's really good on the phone and who does some programming will be much less likely to promise the impossible to close a sale. The usability tester that everyone likes and who clearly describes her likes and dislikes about the UI of a project will be a very good customer contact. A general IT consultant who's not quite up to your programming standards but who explains concepts really well will be good at getting information back and forth between your technical staff and less technical customers.

        Don't confuse getting leads with closing sales. A good marketing person can get people to contact you. People often look for sales staff and hire someone who can close a high proportion of leads only to find they get too few leads. Then the sales people start relying on poor marketing strategies, like cold calling, to generate more leads. A good path to repeat business is to have someone who understands specifications gathering close the actual sale, though. If you're getting lots of customer-initiated contact and close even a low proportion of initial sales but generate repeat business with those customers, you'll be doing well. Customers are more likely to buy, obviously, when they initiate contact anyway.

        Marketing is always a priority before sales. In a very flexible technical field like custom software development or IT consulting, putting a friendly face and voice out from technical people will provide a better image of competence than a slick sales guy. It doesn't matter how high your closing rate is if nobody calls. Of course, if people call and your closing rate is too low, that's a problem too. The initial challenge, though, is getting the customer's call.

        By thinking of your customer-facing staff as consultants or IT buyers for your customer who just happen to be on your payroll, you alleviate the issues of overpromising, of saying something not possible when it is, of your customer's first contact appearing clueless in general (which some customers will take as an actual insult), and of having to switch a customer from a salesperson to a more technical contact during the process of moving from sales to spec gathering. Having one personable, polite, well-speaking technical person lead the customer through getting familiar with your company all the way to delivery of the project will pay far bigger dividends than hiring someone who can shuffle customers on to the technical people as fast as possible.

Re: Certifications are dumb.
by eyepopslikeamosquito (Bishop) on Apr 08, 2008 at 22:00 UTC

    I agree strongly with your views on this. The qualities you seek can be hard to evaluate accurately, however, so I'd be interested in hearing any ideas you may have on specific tactics for evaluating candidates. For example, how do you find out what a candidate's peers really think of them? Do you contact the candidate's old company and ask them? How can you tell if they're being truthful? (Some folks are reluctant to tell the unadulterated truth about what they really think about someone for various reasons, e.g. fear of legal action).

    I've been through the hiring process a few times and wrote a node about it a while back: On Interviewing and Interview Questions.

Re: Certifications are dumb.
by sundialsvc4 (Abbot) on Apr 09, 2008 at 03:46 UTC

    There might be no other major industry on this planet that has bloomed so quickly, and so much out of youth. There's probably not a single six-year-old on the western side of this planet who has not daily encountered a product of the software industry in his or her daily life.

    But you can encounter a professional-grade software product, and even appreciate its sophistication at some level or another, and even understand a great deal about “how” it was made ... without understanding the overall process that actually went on.

    If I walk up to a brick building, I “understand” at some level or another that those bricks consist of fired clay; that the mortar between them was put there by a trowel; that the bricks were artfully set in place one at a time. But that knowledge does not make me a mason.

    Nor does it make me an architect, or a surveyor, or a project planner. Especially not any of these, because while I can “see” a brick wall, it might never even occur to me to wonder how exactly the right number of bricks joined by exactly the right amount of motar happened to wind up precisely here, in a carefully positioned structure that does not fall down.

    You have to learn to be a master mason by starting out as an apprentice:   schlepping hundreds of pounds of bricks around and watching all the while. There is no substitute for it; nor can there be. My first job consisted of tearing paper off a line-printer and shoving it through a slot. I didn't care:   I was inside. I read. I watched. I listened. I absorbed. (The original Macintosh was still three years away...)

    I also believe that you cannot hope to obtain the “master masons” that you require without growing them. The classic trades have a well-developed system... apprentice, journeyman, master. Ours has none of this. Maybe it should.

Re: Certifications are dumb.
by hardburn (Abbot) on Apr 09, 2008 at 02:44 UTC

    Where were you three years ago when I was stuck in a position I hated? :)

    I've studiously avoided certifications. Even if you're good at what you do and just have a cert as a resume line item, you only end up working with other people who have no skills beyond a cert.

    The very reason I've come to prefer Perl is not because it's the best language out there, but because it tends to attract some of the best people.

    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

      The very reason I've come to prefer Perl is not because it's the best language out there, but because it tends to attract some of the best people.

      Odd, the way that works...

Re: Certifications are dumb.
by sundialsvc4 (Abbot) on Apr 09, 2008 at 21:24 UTC

    Something to consider:   no matter how good you are at Perl, your skill-set is not particularly unique. So, if all that you have to offer me is, “I know Perl! tah-daaah!” ... I'm gonna give you a blank stare and reply, “So?”

    I can take any suitably-washed person off the street and in less than six months turn him or her into a functional Perl programmer. After a manner of speaking, that is...

    I could teach him or her the fundamental, basically rote skills of “a code-monkey.” I could also teach him enough to allow him to acquire a certification! But I could not embue him or her with experience.

    They say that there are three stages of knowledge:

    1. You know what you don't know. (Stares at you with dumbfounded amazement.)
    2. You don't know what you don't know. (Knows just enough to be dangerous.)
    3. You don't know what you know. (Master.)
    The most-difficult stage is the second one... which is where most people rush out to buy “certifications.” They might be seeking it as a form of education, but much more likely they seek it to validate their present level of knowledge and experience ... which they don't yet know to be limited.

    A person who has proceeded to Mastery no longer seeks validation. He or she might be just as puzzled as the next person when faced with a new and unfamiliar situation, but he or she possesses a depth of experience, from working with this language or from some other, to which the present situation can relate. He or she comes up with a suitable answer, and may or may not be able to immediately say where it came from.

    More important than this, though, is the fact that a Master's predictions and strategies, while you may not initially understand them nor appreciate them, will be well-reasoned and reliable. The thought-process expressed by such a person makes startling “intuitive leaps” rather than a pedantic progression. The downside to this approach, though, is that many Masters are very specialized in their knowledge, very-deep though it may be. Yet there are people out there, bringing down salaries well into six figures, who are Masters of many things.

    The unionized trades have a formalized progression that matches this:   Apprentice, Journeyman, Master. You cannot buy a “fast-forward” button. The only way to progress is... time. Each stage is usually also accompanied by a formal testing and certification process, standard to that union and that industry, but you are required to spend a certain amount of on-the-job time at each stage before being eligible for advancement.

Re: Certifications are dumb.
by Gavin (Archbishop) on Apr 09, 2008 at 17:17 UTC

    From my own personal experience of modern business management structures there are too many "Team Players" and not enough "Movers and Shakers"

    Too many team players result in too many meetings that decide nothing and make no progress.

    Without strong dynamic leaders and go-getters business levels out to mediocrity at best, you only have to look at the way Local Authorities are run in the UK

      Too many team players result in too many meetings that decide nothing and make no progress.
      yep, and to prevent that you need good team leaders.
      in several companies i encouraged a regular developer meeting once a week. what i had in mind was a short meeting where everybody said in two or three sentences what they're working on, and if they have something important which concerns all developers, or most of them.
      unfortunately it often happened that the meetings lasted way too long because several developers were giving lengthy descriptions of the problems they had what would have better been talked about in a team meeting with only the people directly concerned. the others were bored, so nobody really looked forward to the meetings any more.
      i'm not a fan of hierarchies where hierarchy means power. but hierarchies where the people with the best communication and organizing skills moderate meetings and delegate work are invaluable.
      there are companies which try to attract applicants by saying that the hierarchy is low (flat?). but the more employees you have the more you need a bit of hierarchy. only that the bosses should not be seen as the ones who make decisions but try to hear the arguments of their team and lead the decision process.

      update: so i'd also say do not weight team skills too high but also search for people who can be team leaders. if they are good they can lead also loners into a good team.
Re: Certifications are dumb.
by Herkum (Parson) on Apr 09, 2008 at 19:03 UTC

    I think that you are slightly off in referring to people who are team players and loners. You should focus on is communication skills and how well they can share and exchange ideas. Good ideas can be like a virus, infecting others with concepts and energy but only if you have people that are willing to listen.

    The worst people I have worked with are smarter than the average bear( this is not a generalization, but an observation). Their ego has gotten too big and they stop listening believing that they have nothing left to learn. They are also piss poor communicators because they cannot explain concepts to other people( must be their fault that they are not smart enough to understand... ).

    The worst part are these are the sort technical people that end up in key positions in their organization. Most people who don't want to deal with the crap and have skills leave for another position. You then have no one else who knows the system and can support it. It turns around continues to feed their ego that they know more than other people and it is a nasty cycle. So when I see the lone programmer I think of this type of person.

    Personally I like to program alone because I find it easier to concentrate on my work. But I don't consider myself a lone programmer because I like to interact with other people to learn what they are doing and exchange ideas. How can you become a better programmer by locking yourself in a room?

Re: Certifications are dumb.
by samtregar (Abbot) on Apr 09, 2008 at 19:12 UTC
    And, most importantly, I need to know how well you communicate and how driven you are.

    In my experience the last thing you listed - how driven a person is - is practically the only thing that matters. Sure, it takes a certain amount of native intelligence and attention to detail to do a good job, but without some kind of inner drive that won't do it. I'd take a self-motivated, eager beginner over a more experienced slacker any day.

    The problem is, how do you tell? Most people manage to put on a good, chipper face for interviews and many can sustain it for months on the job. True slacker-hood rarely shows its face early.

    I think you need to be ready to cut dead weight quickly and mercilessly. Your good employees deserve it. Don't be drawn into endless "come to Jesus" meetings - they just don't work! If your company is too big for you to personally know who the slackers are that means you have to empower your technical leaders with the power to terminate, and encourage them to use it.


Re: Certifications are dumb.
by g0n (Priest) on Apr 12, 2008 at 18:27 UTC
    We are currently enjoying the benefits of two connected business doctrines:

    • Core competencies: focus your energies on what you do best
    • Commoditise services: if something can be done on a simple fixed or unit cost basis, outsource it to someone else. If it can't, simplify it until it can.

    So lowest cost, most efficient method of recruiting is to have a 'pick list' approach, and low skilled people following the pick list. Certifications are one element on that pick list.

    Do industry certifications mean anything about someones competence? Almost invariably not.

    Do recruiters rely on them? Almost invariably.

    Is this a bad thing? Almost certainly.

    Will complaining about it change a thing? Nope.

    The fact is, recruiters don't want to get the 'best person for the job'. They want to shortlist the required number of candidates that are capable of getting the job (however badly they'd do it), so they can make their commission and move onto the next requirement. (I was openly told this by a recruiter in one of the biggest UK agencies only a few days ago by the way).

    Similarly, non-outsourced recruiters just want to get someone who can fulfill the list of criteria they have, because that's what their job is.

    This isn't universally true, but where senior management have embraced core competencies as a means for efficiency and cost savings, it does tend to be (and that's pretty damn widespread).

    So thats the first problem: the jobs are in the hands of people who don't know anything about them (dragonchild being a rare exception). Certifications are one way of finding out whether someone can do the job (however badly).

    The key phrase here is 'however badly', and that highlights the second problem: in most cases it doesn't matter to the recruiter or even the requirement owner if the person being recruited will do a bad job, because

    a) the bad job is good enough

    b) the bad job is cheap

    c) probably no one will ever notice it's bad

    d) your much vaunted quality process (which you spent a fortune devising and implementing) will ensure problems get intercepted.

    Sure they'd both rather have a skilled person, and if the process happens to find one, that's great as long as it doesn't cost more. But if it just finds someone barely adequate, that's fine. Hence the popularity of certifications with recruiters.

    Now if I could just find a job as 'departmental bad tempered cynic'....


    "If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
    John Brunner, "The Shockwave Rider".

Re: Certifications are dumb.
by zentara (Archbishop) on Apr 09, 2008 at 19:19 UTC
    How about a system where you get a 90 day trial employment period, and if you show promise, it can be extended, if not you are released. Possibly even at a reduced pay rate, such that the difference will be given to you, as a hiring bonus, if you survive the trial period by demonstration of your skills(which you claim to have by your resume).

    Of course, a system like that would be ripe for abuse by the employers, where workers are released routinely before 90 days. That happened in the auto industry, where new workers received a lower status for 90 days, and the employers were not liable for Unemployment Insurance, until that 90 day point was hit. Of course, everyone got let go at 89 days, for some petty reason.

    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
      amarquis is correct and I think I alluded to that up in my original post. Employees, especially those whom Drucker calls "information workers", take a very long time to get "slotted in" to a new position. Just think how long it takes before you're truly proficient with a new codebase. Now, imagine that what you have to get up to speed on is:
      • 150 client relationships (salesperson)
      • 200 employees and their families (HR rep)
      • 20 applications and their user annoyances (support staff)
      • 5 applications and all their environments w/bugs (QA)
      • 10 market segments and their needs (marketing)
      Factory work, such as the auto industry, doesn't require as long of a ramp-up time, so this kind of system is ripe for abuse there.

      Personally, I don't like such a system because it means that I don't have faith in my ability to pair up the right person and the right job. It says "I didn't pick you so much as we randomly came together." As an employee, I preferred it when my employer gave me the "I choose YOU, Pikachu!" feeling about the position. I'd like to do the same as an employer.

      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

      It's not really ripe for abuse simply because in the first 90 days very little production gets done. Even if you hire at a discount, you are throwing money away (In addition to your senior guys who have to train disposable employees).

Re: Certifications are dumb.
by talexb (Chancellor) on Apr 14, 2008 at 02:17 UTC

    I was at a meeting of the EE Program Advisory Committee at Conestoga College Friday morning, and talk turned to certifications.

    I voiced the (possibly radical) idea that certifications are almost useless unless it's to appease an HR person ("Each candidate must have A, C, B, D, E, F and G.") I was pleasantly surprised to find that everyone at the meeting agreed with me -- certifications generally mean that you're book smart and that you passed an exam. They don't provide much support for how smart you are or what cool problems you've solved recently.

    For me, the best interview process is one that's part closed questions, perhaps to expand more on their resume .. and part open-ended questions, where you ask them to go up to the white board and do a presentation on some problems they've solved lately. If they've got what it takes, that presentation should be a pleasure to listen to -- if not, then they're not cooked yet. Thanks, and we'll be in touch.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: Certifications are dumb.
by Anonymous Monk on Aug 24, 2016 at 23:00 UTC
    these certifcates thing is a piece of trash #REMOVE CERTIFCATES

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://679020]
Approved by Erez
Front-paged by Old_Gray_Bear
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2022-10-07 15:13 GMT
Find Nodes?
    Voting Booth?
    My preferred way to holiday/vacation is:

    Results (30 votes). Check out past polls.