How can I overcome "years of experience" requirements when applying to positions?

Question

Summary: I have 2 years of experience, but want to get a job that explicitly requires 3-7 years. I consider myself with sufficient skills. How can I get a job that requires more years of experience than I currently have?

---

Having just been rejected as a candidate for a job because I do not show the requisite number of years experience, I have some questions about how "years of experience" is interpreted by hiring managers.

• How can I overcome the assumption that I do not have the skills required because I do not have the "right" number of years of experience?
• Are skills directly proportional to years of experience?

Although my situation concerns programming jobs, it stands to reason that any position in any field requiring "years of experience" may apply.

My specific situation is that I applied for a job as an intermediate software developer (between 3 and 7 years of experience) and I currently have about 2 years of experience. But I feel that I have enough skills for the job. For example, my skills in object oriented programming are very good, I tend to follow SOLID principles and design patterns when necessary, and when speaking with friends with the same experience, they do not seem to know these things. In general, I read a lot of books on the subject and spend many hours at home digging deeper to increase my skills, to the point that I believe I'm more capable than those who might be considered my peers.

How can someone overcome this basic job requirement to show that he/she is qualified? Or are "years experience" set in stone?

Answer 1

In your question you say they ask for

3 - 7 years of experience

Then you go on and on about skill, and how much better you are than the more experienced members of your current peers. 5+ years in the industry would tell you from experience that this is not logically a valid argument. It would also tell you that is it not a significant one to any hiring manager in the industry as well.

People skills, not technical skills

The industry is littered with cowboy coders that don't take direction, don't work as a team, don't integrate well into corporate cultures, over estimate their abilities and denigrate their peers; basically these people make terrible employees (really re-evaluate your original question as you posed it yourself with this criteria).

Experienced hiring managers can smell these personalities a mile (1.609344 kilometers) away and will dismiss them as candidates outright regardless of their technical qualifications.

The two things are not equal in any manner. Experience implies skill and judgement, skill does not imply experience or judgement.

Judgement is Earned

You can be highly skilled but lack the experience to know when to apply that skill. This is what you are not understanding. Reading books and and "knowing" things is NOT the same things as doing things and knowing what works and what does not work in various given situations and how to apply these things.

Judgement comes not from success, but from failures. Most companies want to hire people that have had their failures paid for by previous companies, that is why they require N+ years of experience, it implies they made all the basic, entry level mistakes already and someone else had to pay for them.

Judgement only comes with experience.

Edison invented the light bulb through experiencing failure, not through some raw in-experienced skill.

When Thomas Edison was interviewed by a young reporter who boldly asked Mr. Edison if he felt like a failure and if he thought he should just give up by now. Perplexed, Edison replied, "Young man, why would I feel like a failure? And why would I ever give up? I now know definitively over 9,000 ways that an electric light bulb will not work. Success is almost in my grasp." And shortly after that, and over 10,000 attempts, Edison invented the light bulb.

Even the most skilled don't achieve success without a proportional amount of failure. This is how good judgement is earned.

Experience is not measured in years

It is measured in demonstrable failures and successes. It is measured by the depth and detail you can talk about your accomplishments and how they were achieved and how you would do them today.

10 years of doing the same 1 year of knowledge is not 10 years of experience.

Talent/Skill is useless without Judgement

Talent/Skill allows you to do a task, Judgement tells you what/when not to do!

For example, if you were a talented new Jazz musician, you could improvise and know when and what to play. But only experience of playing lots and lots of gigs with lots and lots of different people will give you the judgement of knowing when not to play.

Experienced musicians and programmers can tell exactly how experienced someone else is just by what the person does not play or not code.

Dunning Kruger Effect

If you’re incompetent, you can’t know you’re incompetent. […] the skills you need to produce a right answer are exactly the skills you need to recognize what a right answer is. —David Dunning

If you do not understand the principle behind this answer you might want to read the above a few more times with a critical inner retrospective.

Well Roundedness

If you had more experience in the workforce, you would not need to ask this question, and would already know that demonstrating your skill is more important than documenting it.

There are countless examples of more skilled, but less experienced people being beaten by less skilled, but more experienced opponents in almost every case imaginable.

Even in the world of Chess, a game where knowledge/skill is highly coveted, experience still wins the day in most cases (human vs. human of course).

How to overcome this?

Just like with liberal arts, a portfolio of work demonstrates your capabilities better than a list of technology abbreviations and keywords in a resume.

I started out as a Graphic Designer/Video Production/Animator, I taught myself everything I have ever learned about software and hardware because I had to write my own 2D and 3D animation tools back in the 1980's and 1990's. I had to build the custom hardware interfaces to adapt hardware not designed for the Amiga so I could use them.

Just like a portfolio is the most important thing to an artist, a portfolio of work on GitHub or lack thereof tells me more about you than a resume full of abbreviations, acronyms, and meaningless buzzwords could ever do.

If you are really close to what someone is looking for, one can demonstrate that you know what they are looking for, or it can demonstrate that you can learn it quickly.

Answer 2

Short version: They might have chosen a reason that is not personal and not debatable

It takes time to acquire skill as well as experience. You may be a good coder, but not experienced enough for their taste with handling projects, or they didn't think you were a good fit on the team.

Have you considered that there might be multiple reasons for them not wanting you, but that the rejection reason is one that is very hard to discuss? This might actually be because they were polite instead of having to tell you that they think you have a bad attitude or is not good enough and - even worse - that you disagree and start discussing it. Saying "You do not have the experience we are looking for" is neutral and closes the discussion before it starts.

You may want to ask them if they have any suggestions on how you can improve - besides working more years - to be a better fit in their company. You might learn a thing or two.

---

EDIT 2021: There was a bit of discussion about people not learning at the same speed. This is true. You can learn a lot quickly, but my guess is that the experience requested is not just about raw code writing skills but more having experienced the whole software project cycle end to end, preferrably several times. That simply takes time!

If you don't understand that, then you don't have the insights they are explicitly looking for.

Answer 3

I actually have hired, specifically for what is described here, so I'll use some examples from software engineering.

While I agree that experience will give you more - expertise in subject matter, people skills, and well-roundedness - I believe that all these points can be (and are) typically clarified in the job description. I can say I'm looking for specifics in these areas, and keep the field open to a larger pool.

So... what's experience?

It's having had the time in the field to see the feedback loop caused by your own decisions.

Particularly in engineering, you'll (and your team) will make various decisions about how you'll do the work, what the design will be and other basic assumptions. You'll go along proceeding with some sort of plan, which is inevitably flawed. Show me a plan that worked perfectly and you'll be showing me either a very small project, or a very unperceptive engineer. No plan survives contact with reality, and even a very good plan may work well in unexpected ways and poorly in others.

As time goes on, you'll adjust the plan, people and technologies will come and go, and reality will not trod along in a predictable fashion. The team will come up with new solutions and changes to the plan to compensate for what they've learned.

This feedback loop is what seasons an engineer. Much like a hands on lab is usually much preferred to book learning and rote memorization - experience living through a product lifecycle (or several!) gives the candidate more practical information about what works - both for their team and for themselves. It can include design heuristics, ways to improve development processes, good work habits, research tricks, and experience with how to get things done across an organization.

Variation in years

It's not a fixed thing - in fact 3-7 sounds about right. There's a point after 2 but before ...8? where there's a significant number of cases where an engineer says "Oh... that did not work before, let's try some other way" some significant portion of the time. And yet they are not so burned by experience that they can't see the hope in trying new things and going with new strategies. After 10, I see a sweeping difference - usually from a diversity of work experiences that means that what the engineer sees applies not just to their main area of work, but to the pieces of the organization around them.

It definitely isn't a fixed number. Here's some samples in variation:

• An engineer who's switched between many projects over a very short span of time, never having seen the full release of any of them is likely to have less experience from this perspective.
• An engineer who's worked several internships and then 1-2 years with the same group may have more than the standard 2 years of experience since he's seen that group survive 3-4 years worth of history, regardless of having been there for fixed time spaces (say a summer internship during schooling)
• Someone working in a very small shop with lots of DIY may gain richer experience faster. I don't see too many of these operating as strongly experienced on the short end (2 years), but I do see it start to factor in in the 7 vs. 13 year range - a person from a small startup who has had to do just about anything shows more experience than a guy who's worked for 13 years always doing a small piece of the business, never questioning the process never going beyond his small bit of the world.

Is there an Equation?

Nope... but did you really expect a yes?

It is definitely a factor of:

Time working + experiences survived + nature of role & responsibilities + lessons learned

I'd say most roles have an instinctive scoring factor. And it can be as much related to gaps in the current team as the nature of the work they do. I don't need customer facing skills, for example, on a huge defense contracting team where all customer contact is buffered by management. And types of customer contact are very different between sales engineering and IT technical support. Experience with one at some level does help with the other, but someone who fits the desired profile more closely but with fewer years may well get the higher rating.

In essence some of the "experience factor" comes down to saying (as a hiring manger) - "how easily can I jam this square peg into my triangular hole?" as well as "will it be easier or harder than with this circular peg?"

Interviewing for the Experience

The difference between experience and "not enough experience" or "not the right experience" come down, for me, to questions of "what did you learn doing the things on your resume?".

If in response to these questions the answer is:

• well, I haven't been working long enough to have learned much.
• I have no clue, I keep changing projects and never followed up with the people on the projects to see what happened.

Then I'm probably going to say - "doesn't have the experience".

If, however, I get:

• I keep switching projects, but I noticed that when they released the product, it had XYZ reactions, which made me glad/regretful that we did ABC.

• Well, I haven't made it through a full lifecycle, but I have a pantheon of ways not to kick off a project, so far we've failed at the last 5 attempts, but we learned not to do E, F, G, H, and most especially I.

• Some thoughtful insights about ways to improve process after a true lifecycle is completed

Then I'm going to rate the candidate more favorably. Note - failure is pretty common. Experiencing failure is often even more powerful than experiencing success. If you join a humming, successful, complex project right off the bat and do a fine job, you may actually have less experience just because you haven't seen a major disaster, nor have you learned how to survive it. We all should be so lucky!

Can I beat the system?

Maybe. Could you have an in depth conversation about the strengths and gaps in your skill-set? How your own experiences and biases have helped and hindered your teams so far? How your projects have succeeded or failed or been less efficient on more than a "the textbook says it, therefore it must be true" level? Then the challenge is largely conveying that in the interview.

Keep in mind that the job rec was written based on at least one person's experience. Probably several. There are myriad strategies for how a job rec is written and each company can be different - but the 3-7 range is canonical enough that there's some group think out there on why this time in the field matters. If you are going to sell an alternate idea, realize that you may have to go above and beyond to show why you, particularly, are the outlier and that you are somehow more seasoned than the years you have would normally indicate.

Also realize that they are considering you in light of a pool. If someone with all your skills walked in for the same job the next hour after you left the room, but they had some experience you hadn't had yet -- then there's no reason to compromise.

Answer 4

Other answers have addressed why they care about years of experience, but to answer the question in your title, how to overcome this, the answer is: start with the cover letter.

You might not be able to overcome it (for the reasons explained by others), but if you can, it will be because, in the cover letter, you acknowledged their requirement and then explained why you should be considered anyway. Highlight what you can do and stay away from comparisons to your coworkers. If that gets you as far as a phone screen, you will then have an opportunity to show them what you can do.

Answer 5

Individuals learn at different rates and have different experiences that help them learn. So no, skills do not directly relate to experience. There are people who are greatly skilled with only a few years of experience and people who have many years of experience who are not greatly skilled.

However, in general, the person with more years of experience has been through more of the software development cycle and has experienced both successes and failures and has had to maintain drek written by people who didn't have enough experience or skill. You will look back at yourself in ten years and realize how little you knew then. So yes, the smart, motivated person will, in fact, have more skills after ten years of experience than he had at 2 years. He may have better skills at two years than the less motivated or less intelligent have at 10 though.

Now as to what they told you. In the first place, this is not necessarily why you were rejected, but it is an acceptable excuse to give the person. People are not hired for many reasons such as fit with the team, personality, sex, race, religion. Some of those aren't things that companies can say out loud (as the discrimination is illegal for some of these; it happens nonetheless), so they hit on an acceptable reason like lack of experience.

Next, at two years, no matter how smart you are, you may truly lack experience of the kind they are looking for. Maybe they really need the person you will be at 7 years of experience. How much time have you spent mentoring others or leading a team or designing the architecture or even delivering a product. Do you coordinate with QA and clients? And on and on. You may have been competing with people who have that level of skill as well as programming skills that are far more extensive than yours. If I have good candidates who have the experience levels I am looking for, then why would I, as the hiring offical, take a risk on someone who truly has only beginner experience no matter how good he perceives he is? Anytime you are talking about hiring, you always have to consider that no matter how good you are, they might be interviewing ten people who are better than you. You don't know the qualifications of the people they did interview and hire; they might be blowing you out of the water.

Does all that mean you shouldn't apply for jobs unless you have all the paper qualifications? No, because you never know what the competition will be or exactly what kind of person the hiring offical really wants. Some might prefer the young, hot-shot to the person with 1 year of experience repeated ten times, some might need the person with truly advanced skills because of the type of job they are doing, some might prefer the guy who doesn't have superior skills but is reliable and can do the low level work thay have available to be done (you don't want to hire the hot-shot for the dull job either, neither of you is likely to be happy with the results).

Answer 6

We stopped using "years of experience" on job descriptions at work partially because HR were worried about "ageism" cases being brought for the reasons you state. While this has been relaxed, it did force all of us to address what we really meant by years of experience, and quantify what we were looking for more precisely in job adverts.

With any potential employee, I'm asking myself three basic questions:

• Do they have the minimum technical skill base I need to hit the ground running in the job when they start?

• What developmental level are they at in the other "preferred" technical skills, and what support will they need to grow?

• What developmental level are their soft skills at, and what support will they need to grow?

The "developmental level" is based upon the "situational leadership" model, and in particular for the last question, I'm really looking at how much hands-on management work that person is likely to generate and how much they are likely to dampen/remove (based on my current team profile).

To me, the soft-skills and team fit are key to a sucessful recruitment. Hard, technical skills alone are not enough, as I am interested in team productivity as a whole, not individual productivity.

The key areas are:

• Project delivery: Essentially the size, complexity and dollar value of the project they can be trusted to bring in within agreed (or renegotiated) time, cost and quality constraints, based upon their proven track record and/or understanding of failed projects

• Communication: Knowledge of their own and others' communication/personality styles, and ability to adjust the style based on audience and setting. Ability to be effective in team discussions without antagonizing others or being confrontational. Ability to provide constructive feedback and/or coaching/mentoring of junior staff. Ability to create win/win business cases, proposals or discussions for the team as a whole.

• Business understanding: Knowledge of the business framework we operate under, including expenses, budget cycle, CAPEX/OPEX, budgeting, tenders/contracts, roles performed by other staff and business improvement.

I have a set of expectations for these key skills at the different levels I have within my team; this typically falls within a "years of experience" band but there are always "outliers" who either pick these things up very fast, or who never pick them up at all.

In looking for these skills, I tend to look for "key achievements" as opposed to "role responsibilities/duties" on a CV/resume. In recruiting, I'm not very interested in what you were supposed to have been doing, more what you have delivered and learned so far.

In putting your CV/resume and cover letter together, focussing on these areas with reference to the key points on the Hay Scale can overcome the need for specific years of experience.

Answer 7

Are skills directly proportional to number of years of experience?

Only if you learn at a constant rate. Did you learn exactly the same amount last week as you did the week before? And how does, say, the last month compare to the first few months that you started learning about programming?

It's hard to measure your learning rate precisely, but I think most people would say that they don't learn at a constant rate. Sometimes you learn a lot very quickly, sometimes you don't. If you accept that, then the answer is obviously no, skills are not directly proportional to experience.

I was just rejected as a candidate for a job because I do not show the number of years of experience they require.

That's too bad. Don't take it personally -- try to remember that it's very difficult to tell over the course of just an hour or two how much somebody knows. You may be right that all your reading and practice could make you better qualified than someone with more experience, but the folks doing the hiring for the position in question a) may not have been allowed to consider someone with less than the required number of years of experience; b) may not have been willing to take a chance that you're one of the unusual individuals who is wise beyond his or her years; and/or c) may not have bothered to look very closely at the rest of your résumé once they realized that you didn't meet one of their basic requirements.

Also, realize that experience brings more than just OO programming skills... there's domain knowledge, leadership, time management, persistence, and other "soft" skills that are sometimes even more important than mad coding ability.

One more thing to consider is that an employer may be obligated to reject you if you don't have enough experience to qualify for the position under the stated requirements. Employers may be required by law or by company policy (mostly to avoid discrimination lawsuits) to reject applicants whose skills or experience don't meet the minimum requirements for the position. In such cases, there's nothing you can do but ask the employer to give you a call if the requirements change.

Answer 8

Skills are not directly proportional to experience, but in general, the more experience you have the better your skills are. Skills are hard to evaluate without a quantitative test of some sort, which is likewise hard to develop. Some people who look good on paper flail about helplessly when given a coding or debugging test, while some fresh out of college can rapidly eclipse peers with two or three years of industry experience.

In short: it's hard to properly evaluate programming skills, so many companies don't even try and instead fall back on a crippled metric. If you really want the job, I'd follow-up with a letter explaining why you feel they should reconsider, and giving specific examples of your skills. If they've already rejected you, what have you got to lose?

Answer 9

There are some good answers here, but one of the biggest questions seems unanswered.

Did you get to interview?

If you got to interview then you're qualified enough, and the reason for rejection is more likely the way you answered the questions, presented yourself & your personality. There is more to any technical job than just technical knowledge and experience, there's the 'soft' side as well. You may have to interface with clients, people less technically minded or senior stakeholders - all of these things will be considered too.

If you didn't get to interview, then you need to review what information you gave the person shortlisting, and decide how you can make it better. You're at a disadvantage vs. someone with more years under their belt, so you need to make up for it with some compelling and evidenced statements about what you've done to date, and what makes you feel you can live up to the challenge6. This means submitting a solid covering letter showing diligent research on the company, enthusiasm, and an explanation of why your CV fits this role.

In both cases, ask for more feedback - maybe even a phonecall to discuss.

Finally: it's a hard fact of life that experience can get over-valued, don't forget to consider biting the bullet, going for a more junior role, and proving you have what it takes to get an early promotion.

Answer 10

Skills and experience are not necessarily proportionate. I know lots of people who are very highly experienced (read: they have been in the industry for a long period of time), but they are complete idiots when it comes to technology. In these scenarios, it doesn't matter how much experience they have. If they're incompetent and are incapable, then they offer much less business value than someone (like you, OP) who is passionate and studies hard on their own time. Personal interest and passion for technology are heavily overlooked by prospective employers, perhaps validly in some cases.

I tend to think that through passion and personal interest in technology, comes business value. Someone with the right technical skills can solve business problems that managers come up with -- expecting a purely technical person to fully understand the business isn't always practical. Should they understand the basics of business? Sure. Should they be making business decisions? Probably not.

Answer 11

There is a strong link between skills & experience, however there are no causality.

They increase together probably for the same reason: acquisition of knowledge.

Therefore, I personnally think that one's capacity of getting that addition knowledge faster than others is the key.

But seriously, most of us are average guys and acquire new knowledge in a normal manner. Therefore common sense would indicate that years of experience is a good prediction of your current skills, no matter if in a small portion of case, they miss a genius.

Answer 12

If you would like to overcome the obstacles that you currently incur, consider becoming a member of a local professional group or even an officer. Examples can range from a JUG, .NET or Oracle user group. You will meet a lot of people, be able to prove your worth and be introduced to positions where all this "experience" is not the ultimate criteria.

Another possibility would be to write an application from which you feel others can benefit and place it on the web. Having something that a potential employer can review may be invaluable or at least much better than a well written cover letter.

In these times, we all need to think outside of the box.

Answer 13

There are many answers but I don't think this one has been posted:

Apply anyway!

A lot of the time, the person who wrote the job description hasn't exactly done a thorough analysis of what's required for the job. They might not even know themselves, and be a HR person with a vague or off-the-top-of-the-head list given to them from a technical person. It's often a wish list rather than a set of strict rules. The person who wrote it might not be reviewing your CV.

This especially applies to the Years of Experience part, where they might well have pulled a number off the top of their heads. What they mean is "Not a beginner/graduate". How could they know how many years is required to do this job?

You might be up against someone with 5 years on them, or you might not. Even if you are, you may turn out to be a better fit (e.g. a lower salary expectation, have a more likeable / enthusiastic personality, or experience specific to their requirements, or live close by).

You might even turn out to be the most experienced person who applies!

TL;DR - They might not know what they want!

Answer 14

How do you know they didn't hire someone more qualified? There is a difference between being good enough and being the best candidate.

Two things are missing from your description of your qualifications:

1. Have you actually built something similar to what is required in this position? Open source contributions. A sophisticated personal web site. Or anything of substance during your nearly 2 years of work.
2. Who knows what you know? Where are your references? As far as we can tell, you only have a bunch of friends who aren't very skilled.

Everyone who applies for these jobs have read a book. You need to demonstrate your knowledge in something a little more tangible. A programmer with 10 years of "experience" who hasn't built anything, is worse off than someone fresh out of college.

Answer 15

If one takes a broad enough definition, the only thing the potential employer is concerned about is skills. But skills come in a wide set, some can be technical, others are less so. Some can be acquired rapidly by someone gifted, others need time and practice to acquire and come mainly with experience (and experience tends to be a good way to solidify all the skills BTW), that is time spent outside your depth (years spent inside your comfort zone isn't really experience as you don't learn anything).

In my experience, proving that your technical skills are above average isn't really a problem. The hiring team knows quite well that technical skills vary a lot, but when asking for experience, that's not all that they ask about.

Even if your technical skills are as good as you think, you just haven't had the time to get acquainted with the numerous differences between theory and practice -- book writers tend to oversell a lot --, to meet in person enough different situations so that when faced with something new, you immediately see similarities with what you have already lived through and know what really works and what doesn't. Having seen such similarities often enough to take them with a grain of salt and be ready for the subtle differences which will show.

Even if your technical skills are as good as you think, you probably haven't the visible legitimacy allowing you to be taken as a peer by others of intermediate level and as a mentor by beginners. Yes, that's part of the job. Those and other interpersonal skills is important and it often seems that the more you are technically oriented, the more the interpersonal skills are harder to acquire.

Yet, you may acquire experience related skills more rapidly than others, because you are more gifted, because you are more lucky and get enough variety yet be stable enough to get the time needed to learn instead of jumping around. It is then more easy to get them recognized by those you are working with before trying out to get hired elsewhere. And it is more easy if you know someone who can speak for you there. If you aren't recognized where you are now, if you know nobody where you want to be, you'll have a very hard time to get hired at an higher level than your current one.

Answer 16

No, skills are not proportional to numbers of years of experience. I think what you are experiencing is quite common among young developers. Young people often have more energy, are more open to learn new things, they might be able to spend more of their spare time on acquiring programming skills, and might have more up-to-date programming knowledge from school. In short, their coding skills might be better than many of their more experienced collegues.

That said, there are other types of skills and knowledge that can only be built from several years of experience, and perhaps it was those skills they were looking for in your case. After many years of experience one becomes better at assessing risk, better at separating the useful new tools and technologies from the hype, better at estimating, and better at creating architectures for solving big, complicated problems. Don't underestimate the gut feeling of an experienced developer.

Finally, I think a successful development team needs both kinds of people. The young, skilled and energetic, as well as the more experienced and perhaps more conservative, developer.

Answer 17

Okay, first of all, how much the stated "years of experience" matters is largely about market. One of the more amusing things about being a client side web developer for instance is seeing ads requesting more years experience in a given technology than said technology has actually existed. Naturally, they tend to bend on years of experience since it culls 100% of their resumes.

As somebody else wisely pointed out, you're screwed on HR automation software. When people specifically spell out requirements like this AND want you to rewrite a resume using a series of forms on their site, don't bother. In fact, I stopped touching these period, regardless of how well I matched the criteria because I've never, not once, received interest from wasting time on one of those and I realized the time was better spent hunting down more leads failing attempts at actually contacting somebody about the position directly.

Another instance where it's going to matter a lot more is when you have a lot of competition. Take Java devs. Lots of jobs, but also lots and lots of Java devs. That makes phase 1 of the hirer's search the grand culling of resumes, usually based on some arbitrary stat like years of experience just to trim the piles to something manageable. In cases like these you might indeed be a 2-year guy who deserves to rub elbows with five year devs, but you're likely SOL barring opportunities where you actually know people doing the hiring and they have a rough idea of your skill. So yes, in this case, the best thing you can do is make contacts within your local developer community to head off phase 1 at the pass.

Another thing to consider is your general local community culture in regards to jr. level employment in general. I realized I was going to have to one day leave my hometown where I grew up in upstate NY when, while searching for a summer job, I saw the ad: "Asphalt (pavement?) rakers wanted - five years minimum experience" Now, I must confess that I do not know precisely what the craft of asphalt and/or pavement (long enough ago that I can't remember which it was) raking entails but I'm highly dubious on the matter of it taking 5 full-time years of raking anything that isn't subatomic to get the gist of it. Solution: Examine the sorts of ads you see for similar positions in other parts of the country and be prepared to GTFO.

And the one general thing that can't hurt regardless of industry is to do some relevant, useful open source work and make it available. If that's not possible, blog about your craft. Do whatever you can to establish some street cred that helps you make the argument that you are better than your average 2-your dev in your industry.

But again, context is everything. If it's all closed proprietary tech, you have a ton of competition and you're unlikely to gain a following talking/debating about the right/wrong ways to do things, you may just have to settle for paying your dues. Or choose to pursue a skill-transferable technology where these obstacles are easier to overcome or nonexistent.

Edit - I didn't really address this aspect of your question:

"Are skills directly proportional to years of experience?"

Some things are about raw talent and problem solving ability. Others are simply about having encountered the same problem enough times to know the exact right thing to do that most other people in your shoes with similar levels of experience would do. It's subtle, but yes, experience can/does matter in a lot of cases. Calling yourself mid rather than Jr. level at 2 years doesn't strike me as particularly cocky, however, and raw talent/problem-solving ability can definitely be a gap closer depending on what responsibilities need to be met.

Answer 18

Marcof. I read your post only and tried not to read too much of what others said, bt I did see some cynisms in their comments. To me you are spot on. Your skill is excellent, and you're confident. That's a super plus, and don't scale it back. However, remember that since you pretty much # (pun intended) more experience programmers into the ground, you have to make sure that your employer doesn't feel like you wouldn't respect the seasoned people you might work with.

• Employers always ask for more experience than they need, or want to pay (correctly) for.
• Technically, you're better for the job from an employer perspective because they can get your extra skill for free and pay you based on your years of experience.

Try to figure out what it is about the employer that makes you want to work there. It's corny, but it'll keep you from saying too many statements about being a coding king. Also, try to identify the softer, less technical aspects that make you a match for the position - or put another way, why is it you even enjoy coding? Tell them what you like most about being a coder and how you feel those aspects will be in their company from what you read. Tell them you want to learn from the guru's they have so that you can grow even more and contribute.

Keep shooting for those jobs out of your "range". Experience listed is always what the employer is stretching to get in an ideal world. If they like you, you're in as you DO have the skill.

By the way, if you can create a physical portfolio for yourself, maybe of things you've worked on, or a visualization of an object, process, etc it could be a way to bring to life the advance skills you use on a daily basis. You mentioned knowing/adhering to structure others in your current workplace didn't know about. Find a playful (i.e. non-condescending) way to bring up this knowledge. For instance, suppose there is a function or method you use a lot that is advance. Turn that into a question

"Do you guys use functionX to do process Y when making programs about topic Z?"
"Is it ok to byte shift, use blah-blah encoding for this type of thing?"

Do not doubt yourself, just keep trying. Know when to be confident in your answers, and know when to be relaxed in presenting your expertise. Also, whatever you do, don't ever say you're better than your coworkers. If they compile that info, you won't make it to runtime.

Answer 19

Here's one problem that will cause you to be rejected at some companies without anyone ever reviewing your application: HR automation software. The HR person will plug in 3-7 years experience in whatever into the program. It will read resumes and filter those out that don't meet the criteria. If you put 2 years on your resume, it will be filtered out by the software and no human, not even an HR human, will ever read your information.

You can stretch your experience from 2 to 3 years to get by this digital guardian but you will be lying so that could cause you problems down the road. The other alternative is to try to develop contacts with hiring managers who'll be able to bypass the 'bot and HR and give you a chance.

Answer 20

Position descriptions and requirements are meant to do 2 things: attract the notice of people that would want the job, and filter out those that aren't a good fit for the job. The filtering part is both inside and outside the company (i.e. it discourages people from applying, and it gives HR a quick way of tossing the application when the resume doesn't meet the requirements, without requiring that HR be competent enough to judge someone on their merits).

You can overcome the first part of the filtering, simply by applying for the job regardless of whether you have the required experience or not. The second part of the filtering depends entirely upon the company and the job market. It may not be possible to overcome it due to policy, and even if the company is willing to overlook their own requirements under the right circumstances, there would still be the question of do those circumstances exists for you...

Basically you have to convince those that are picking people for interviews, that you're a good choice. If you're coming into the company cold (don't have an internal reference for the job), then the best place to do this is in the cover letter. You'll need to show in your cover letter that you have what you think they are looking to gain from those extra years of experience. If you get it right, it might get you to an interview.

Answer 21

Everyone wants someone who is experienced, but not everyone absolutely needs it.

For some jobs, you will be working in a team of developers. A team of developers needs one person who is really experienced and can handle any kind of problem that turns up, and can live with other people who are less experienced as long as they listen to the experienced person. In that situation, the experienced person might feel that there is too much load on their shoulders and ask for someone else with a lot of experience, but it isn't an absolute must.

For other jobs, you are the only one. If you can't solve a problem, there is nobody to solve it. That's where the experience is a must and not negotiable.

So you need to figure out if it's the first or the second kind of job. The second kind, you have very little chance. The first kind, you may have a chance. Best to tell them that you have some experience, and how good you are at picking up new skills and learning from those who have the experience.

Answer 22

If it is a software developer position, just say you really really love python. Nobody with the "years of experience" will bean you on this advantage.