Skills: check. Education: check. Experience: not so much. What should you do when you know you're capable of a job, but the requirements says you're too inexperienced? The workplace experts at Stack Exchange offer some helpful advice.
Having just been rejected for a job because I do not show the requisite number of years of 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.
See the full original question here.
Have You Ever Been Experienced? (Answered by bethlakshmi)
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, while still keeping the field open to a larger pool.
So what's my idea of proper experience? It's having had enough time in the field to see the results caused by your own decisions and workflow.
Particularly in engineering, you 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 proceed with some sort of plan, which is inevitably flawed, because our plans never work out perfectly.
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 in 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 in an organization.
Regarding the variation in years listed in a job's requirements, it's not a fixed thing. In my hiring experience, there's a period with new engineers who have two years of experience, but less than eight, when they can realize what has and hasn't worked before—and yet they are not so burned by experience that they can't see the hope in trying new things and new strategies. After ten, I see a sweeping difference—they have a diversity of work experience that allows the engineer to understand how the main area of their work affects the organization around them.
I view experience as the sum of a few factors: time working, experiences survived, the nature of the role and responsibilities, and potential 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 very 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 the 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 to questions of "what did you learn doing the things on your resume?"
If in response to these questions the answer is something like:
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 that they don'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.
Or some thoughtful insights about ways to improve process after a true lifecycle is completed
Then I'm going to rate the candidate more favorably. Know that past 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 requirement was written based on at least one person's experience. Probably several. There are myriad strategies for how a job requirement is written and each company can be different, but the three to seven year 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 your experience 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.
Focus on Skills, and Know the Hay Scale (Answered by GuyM)
We stopped using "years of experience" on job descriptions at work partially because our human resources department was worried about "ageism" cases being brought up. While this has been relaxed, it did force all of us to address what we really meant by "years of experience," and to quantify what we were looking for more precisely in job advertisements.
With any potential employee, I'm asking myself three basic questions:
- Do they have the minimum technical skill base 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 (personal communication 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 or remove, based on my current team profile.
To me, the soft-skills and team fit are key to a successful 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, but rather 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.
Start with the Cover Letter (Answered by Monica Cellio)
Other answers have addressed why they care about years of experience, but to answer the question directly, the answer is: start with the cover letter.
You might not be able to overcome it (for the aforementioned reasons), 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.
Disagree with the answers above? Leave your own answer or submit a comment at the original question. Find more questions like it at The Workplace, a question and answer community for career-related advice. And if you've got your own question that requires a solution, ask. You'll get an answer. (And it's free.)
Image remixed from ducu59us (Shutterstock), artenot (Shutterstock), and uckmond (Shutterstock).
0 comments:
Post a Comment