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.

“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.

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)

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.