18

I see many job adds which require at least x years experience. The question is how do you know when a candidate has the required years of experience? What do you expect from a person with x years experience (edit: effectively how do you check if the CV isn't lying without relying to skill checking)? What can a person with x years experience can do that one with y years (with y < x) cannot do (edit: assuming they have similar skills)?

There can be cases with some passionate programmer with y years experience that has vast knowledge and worked on multiple projects and other programmer with x years experience (x > y) that has worked on few projects and doesn't have that much experience.

Why can not it be reduced to something like this "if you know this technology and you know how to do that stuff (be it design, communication, estimates etc.) then you are suitable for our job"?

I know you cannot hire a fresh graduate with 1 year experience for the post of an enterprise architect but I also see a problem with the facts that almost all ads ask experience. IMHO firstly passion should be taken into account.

Firstly I did not know if the question is suitable for this site but since there is a tag for recruiting and experience I believe it has a place here.

Improve this question
12
  • 11
    asked and answered at TWP: How can I overcome “years of experience” requirements when applying to positions? "Judgement comes not from success, but from failures. Most companies want to hire people that have had their failures paid for by previous companies..."
    – gnat
    Nov 19, 2013 at 18:21
  • 1
    Read my beautifully long essay I wrote below. It may have some value to you =)
    – Joe
    Nov 19, 2013 at 18:32
  • 10
    Passion? Really? What happens when you give them something boring to do? One of the most productive employees I knew was a colleague who was fairly dispassionate about his work, but had a tremendous work ethic and would do anything you asked, with complete fidelity, no matter how many times he had been asked to do it previously.
    – Robert Harvey
    Nov 19, 2013 at 18:36
  • 2
    Don't forget that many times the hiring managers don't work in the field, and have no idea what they're talking about. To them, "X years experience..." may be the only thing that makes sense, since they look at tons of resumes with nonsense words on them every day. Numbers give a simple comparison, even if it might not be a good comparison in all cases.
    – Geobits
    Nov 19, 2013 at 19:55
  • 3
    Expanding what @Matthew I can teach you or send you on a course to get skills, I cannot teach experience. That said, there is a difference between 10 * 1 year experience and 1*10 years experience. Unfortunately when HR went to school they were told integers were commutative when multiplied and have yet to learn the mathematicians are wrong on that one when it comes to experience.
    – mattnz
    Nov 19, 2013 at 20:56

4 Answers 4

Reset to default
11

Your question can be handled by splitting into two sub-questions.

Why use years of experience as a requirement?

Because it's an easily-verifiable metric correlated positively with programming competency. Snagulus's answer already elaborates on the details of correlation, so I'll focus on the "why".

The hard truth is that usually there is more than one candidate for a given position. Also, interviews are quite resource-consuming, especially if they are done "properly", i.e. technical interviews are conducted by technically-competent staff (in this case programmers).

Therefore, some criterion to initially sift through the incoming CVs needs to be used, and preferably one that can be verified by non-technical staff - when in doubt, HR people can always call previous employers and check that yes, John Smith has worked for X years with them.

Why not use "passion" as a requirement instead?

There are at least two problems with this:

how to measure "passion"?

KLOCs logged? Good luck finding that out, also, in programming (and other disciplines), more profuse does not equate to "better".

Open source/hobby projects completed? Not easily checked by HR, and a lot of competent programmers have legitimate reasons to be inactive in that regard - other time-consuming obligations, long work hours with desire to unwind, simple professional fulfillment during work hours etc.

Years of experience? Oh, wait...

is "passion" really a good metric for competence?

As Robert Harvey says in his comment, passion is not really indicative of a competent programming. Compared to experience, it's a mostly orthogonal quality - that is, there exist :

  • passionate and competent programmers and
  • dispassionate and technically competent programmers and
  • passionate and technically incompetent programmers and
  • passionate and non-technically incompetent programmers,
  • etc. etc.

The last example is important in our context - years of experience also show that a given programmer has somehow managed to function in his/her job, whereas an dysfunctionally passionate programmer could, e.g. flat-out refuse to participate in even the simplest task management system (say, Scrum Post-it notes), because "it slows me down."

Final disclaimers

First of all, and fortunately, "years of experience" are often evaluated "loosely" - i.e. if you are applying for a job with language X, but only have "commercial" experience with language Y, similar to X, that is also often taken into account.

Secondly, personally I'm not a fan of "N years of experience", and I'm not the only one. There is a simple alternative - specifying "experience in". That usually suffices as a filter, since candidates are forced to document that experience in their CVs - if you get a candidate for a programming position that has previously only done waitering (and this happens!) you know something may be wrong.

Improve this answer
2
  • Enh, even if passion and capability are orthogonal, they are not uncorrelated. You'll find many more passionate skilled programmers than unpassionate skilled programmers.
    – Telastyn
    Nov 20, 2013 at 13:48
  • 1
    @Telastyn : you're right in that I should have possibly qualified that statement with "mostly" (which I think I'll do now). However, I would be cautious about the "many more" qualifier - note that you can lose passion, but you don't automatically lose the skills. It's not like all dispassionate programmers start dispassionate.
    – mikołak
    Nov 20, 2013 at 15:03
44

"Years of experience" is more of a probability scale than a measure of anything concrete. With more years in, you get an increased chance that a person has encountered things such as:

  • Has participated in a crisis-like event.
  • Has seen a project from beginning to end.
  • Has seen a project fail to begin or end.
  • Has worked on legacy code.
  • Has worked on a blank slate and made something.
  • Has implemented design decisions.
  • Has designed a system.
  • Has written a bug, released a bad fix, taken down a server; Has screwed up, essentially.
  • Has fixed a screw-up.
  • Has found the weird edge cases in the language they work in, and seen a place where they matter.
  • Has learned that things currently in the codebase might be dumb.
  • Note, these things are a small, non-mandatory sample, and also include dozens of little things that can be found working in a live environment.

Again, it's a chance thing, and it depends entirely on /where/ they got those years of experience. One person could have worked in a single project on a team of several hundred people and become highly specialized. Another could have been in a trial-by-fire small shop, and become more of a generalist as they deal with servers/installation/coding/QA/DBA/project management. There's also people who find themselves getting the same year of experience over and over again.

It's a rough measure, but on average a person will have been exposed to more potential learning events the longer they've been working, and it's useful as a preliminary data point. The rest of the resume (and more importantly the interview) are for figuring out what they actually know, and what they've actually done.

Improve this answer
3
  • 1
    I definitly agree with this, as I have found that the only real way to get deep knowledge that helps you in any venture is to have gotten your hands filthy dirty, hacking out some extremely obtuse crap because you had to. The had to is the hard part. with only schooling, and maybe a part time job or two, you just never had to, get it done, crank it out, dealing with people who don't care about the hackishness of your solution and get the technical part done to achieve a business goal. that cranking teaches you about how to do it next time. It's is jus reallyhard to teach this.
    – Andyz Smith
    Nov 19, 2013 at 19:22
  • 1
    It's almost a character maturity thing. You can't teach wisdom jus can't . wisdom comes from goong through todays comtemporary crises and learning someing relevant about the situation we are in today and what you may, in your lifetime, do about it. no way to write that book baby
    – Andyz Smith
    Nov 19, 2013 at 19:24
  • 1
    +1. It is mainly about having had the opportunity to learn from your own, and others', mistakes and dumb decisions, learning the painful lessons the hard way, and having at least some ideas about how to avoid the same things when you come to work for me. Of course, I'll need to interview to figure out whether you actually took the opportunity to learn from the crises you have experienced...
    – Bill Michell
    Nov 20, 2013 at 11:23
7

I will answer this by addressing each of your questions in the post.

The question is how do you know when a candidate has the required years of experience?

This is normally what the interview process aims to filter out. Multiple interviews are conducted and you can normally evaluate a candidates experience against some of your own in-house developers.

What do you expect from a person with x years experience?

You would expect them to fulfil the job requirements that are specified in a job post. For example:

"We are looking for a senior PHP developer with 10+ years experience working in system design and architecture to restructure our system tools as the Chief architect, whilst managing K amount of senior and junior developers and guiding them along the way. The job will also require... (etc. etc.)"

What can a person with x years experience can do that one with y years (with y < x) cannot do?

You're looking at experience wrong in this case. Job posts don't only ask for number of years, but also experience in the technologies that the company is using. Like you could have 10 years experience in C++ development, and say I am a gaming company looking for C++ developers with even 5 years experience. You still wouldn't be my ideal candidate because you've never worked in the gaming industry before. My job post would actually specify: X amount of years experience in A, B, C aspects of programming.

There can be cases with some passionate programmer with y years experience that has vast knowledge and worked on multiple projects and other programmer with x years experience (x > y) that has worked on few projects and doesn't have that much experience.

Read my previous answer. Experience is tied to the tools you're experienced in. X amount of years in A, B, C tools.

Why can not it be resumed to something like this "if you know this technology and you know how to do that stuff (be it design, communication, estimates etc.) then you are suitable for our job"?

This can and does happen. If you can prove yourself then experience in years doesn't matter. For a guy like yourself, you seem more suited to a smaller dev shop, where the interviewer/recruiter is a developer him/herself. Bigger companies normally have HRs doing this type of stuff, which is why they make the job requirements so broad that you basically need a PhD with 15+ years experience to write small functions for their website (over-exaggeration but it kind of explains the flaws in programmer recruiting, especially for the bigger companies - although not all of them suffer from this ailment)

Improve this answer
5
  • 2
    You tend to assume that people with more experience have better skills than those with fewer experience; in general this is a valid assumption but then you should measure skill and not experience... so try and give the answers assuming that you have 2 persons with same skills and different experience.
    – Random42
    Nov 19, 2013 at 18:44
  • That is why I mentioned the interview process is a multifaceted thing. I also mentioned that experience is tied to what you are experienced in, which relates to skills. As my last point also mentioned, experience isn't everything, you just need to look for where your skills are valued most. The thing with experience is that it kind of acts like a buffer for doing an initial screening and filtering out candidates, thereafter comes other aspects, like skill, as you mentioned.
    – Joe
    Nov 19, 2013 at 18:47
  • If ultimately everything is reduced to skills, then why is experience brought into discussion? The only reason I see is "we don't have enough time to check them all and it is reasonable to let some good programmers not apply then interview many bad ones".
    – Random42
    Nov 19, 2013 at 18:50
  • 1
    It isn't ultimately reduced to skills only. It is the entire package of experience, skills, candidate history, psychological analysis, etc. It sounds like you're having a tough time getting people to see you're talented but lack years of experience. The best way to address this is to build your portfolio on a place like GitHub for people to see. If you have the skills, the recruiters will see that you've backed it up.
    – Joe
    Nov 19, 2013 at 18:53
  • 1
    I've had skillful, inexperienced as well as unskillful, inexperienced people work for me; the main difference is that unskillful, inexperienced people often do less damage (and less work) when setting out on the wrong path, and rarely argue or question when you tell them to change course. Skill coupled with inexperience therefore has a short-term risk, but hopefully longer-term benefit and payoff; and, I say "hopefully", since "experience" isn't implied with the passage of time and accumulation of failures.
    – michael
    Nov 20, 2013 at 6:24
1

Years experience is simply a filter that gives a "rough" estimate about what is expected of the person utilizing the desired skills listed in the job description.

Here's prettty much what I would expect, but others may have different ideas:

2 years or less - You should be able to do specific tasks that you are told to do, with employers knowing that there will be a learning curve with a fair amount of supervision for most of those tasks.

3 - 5 years - You should be able to do the tasks you are told to do, without much hand-holding because you should already have done similar tasks in your 0 to 2 years experience. You should also be starting to show some "smart" initiative and be able to handle smaller tasks that aren't necessarily clearly defined. (e.g. Be able to design modules from the requirements, where you have to track some of those requirements down yourself).

5 - 7 years - You should be able to work on your own and be able to decide what those "tasks" from above are. You should be able to handle mid-sized tasks that aren't clearly defined. (e.g. Be able to design/implement/selloff subsystems). You should also be starting to lead subsystem teams in this time-range. Give necessary presentations of subsystems they are responsible for, to at least the internal team.

8 - 10 years - Can be relied upon to be given very large and/or the critical subsystems of the project. Resident expert in several technologies. Can lead large subsystem teams. Give presentations of the subsystems they are responsible for to the customer.

10+ years - Can handle pretty much any software task thrown at them, within the confines of the job description AND most other semi-related software tasks. Resident expert in a large number of software areas. Can lead large projects, from requirements through selloff. Understands system design and not just module/subsystem design. Is able to design reliable, robust and maintainable systems. Is the software interface to the customer, including presentations from a systems perspective. Can adequately put together bid proposals and schedules.

While the years of experience definition is vague, it is not only for the employer's benefit but it is also a guide to the job-seeker. Thus, if you get hired, claiming you have 8 to 10 years experience and come on the job and need to be told every little task you need to do then at best your future at the company is "very limited" if you even last very long at all. First impressions are hard to change, so even if you get better as a developer, people will still likely maintain their original impression of you.

I've seen a fair number of "senior" developers get hired that were gone in a matter of months or in a couple of years were put on the "employee development" program, which is really just the fast track to being the first on the layoff list. If those same developers had come in at a lower level (of course that means lower pay) then they very well may have been considered a successful hire and seen as performing adequately.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.