You find a role you would like, recognize most of the work, and then reach the requirements section. It asks for more years of experience than you have, a tool you have never used, and knowledge of an industry you are trying to enter.
Should you apply? Often, yes. But “apply anyway” is not a complete strategy. Some gaps are manageable; others mean the job would be difficult to do or impossible to accept. The useful question is whether you can make a credible case for doing the central work.
There is no universal percentage of requirements you need to meet. A missing preferred tool and a missing professional qualification do not carry the same weight.
Start with the work, not the wishlist
Read the responsibilities first. Try to describe the job in one sentence without copying the title.
For example: “This person will maintain the customer-facing application, work with a designer on new features, and handle production issues with the team.”
Now ask whether you have done comparable work. The title might be unfamiliar, while the responsibilities are close to your experience. The reverse also happens: a familiar “Software Engineer” title may hide a role centered on a specialty you have barely encountered.
Pay attention to the verbs. “Support,” “contribute,” “own,” and “lead” imply different levels of responsibility. A position asking someone to lead architecture across several teams is not simply the same job with a larger list of technologies.
Sort the requirements into three groups
Conditions that determine whether the arrangement works
These include location, working hours, travel, start date, and any explicitly required credentials or eligibility. Read them literally. If something is ambiguous and there is an appropriate contact, ask a precise question before investing in a long application.
Do not assume “remote” means you can work from anywhere. Likewise, do not claim eligibility you do not have because the rest of the role looks suitable.
Capabilities needed to do the main job
These deserve most of your attention. Can you carry out the main responsibilities at the requested level? Can you give an example of similar work, including your own contribution?
For a customer-facing technical role, communicating clearly may be as central as troubleshooting. For a team lead, helping others make decisions may matter more than familiarity with every library in the stack.
Preferences and potentially learnable gaps
Words such as “preferred,” “a plus,” or “nice to have” are useful signals, although job descriptions are not always written consistently. A tool may be learnable if you understand the underlying work. Industry knowledge may be less important if the team expects to teach it.
Be careful not to label every weakness “learnable.” Almost anything can be learned eventually. The question is whether the gap is reasonable for this role, with the support and time likely to be available.
Replace percentage matching with an evidence check
Choose the three responsibilities that seem most central. Under each, write one piece of evidence from employment, study, volunteering, or a substantial project.
Imagine a developer applying for a role using a framework they have not used professionally:
| Central responsibility | Relevant evidence | Gap to explain |
|---|---|---|
| Build customer-facing features | Shipped account management features with design input | Different frontend framework |
| Investigate defects | Reproduced and fixed recurring form failures | Unfamiliar monitoring tool |
| Lead a small team | No comparable experience | Significant leadership gap |
The first two gaps may be manageable for an individual contributor role. The third matters if team leadership is the reason the employer is hiring. Counting this as “two out of three” would miss the point.
How to handle years of experience
Treat years as a signal about expected depth, not a number you can quietly round up. Someone asking for five years may want independent delivery and good judgment. Your evidence might demonstrate those qualities with fewer years, but the employer may still use the stated minimum.
Apply when the work is credible for you and the effort is proportionate. Keep your actual dates. Do not add overlapping projects together or convert course time into professional experience.
If you are far below the requested level and have little evidence of the central responsibilities, look for a more suitable position at the same company. That can be a better use of your interest than forcing an application for the wrong role.
Make the application about your relevant strengths
You do not need to open a cover letter with a list of everything you lack. Explain the match, then address a meaningful gap if doing so helps the reader.
For example:
My recent work has involved building and maintaining customer-facing features with React, including a redesign of account settings. Your team uses Vue; while I have not used it professionally, the role's emphasis on product collaboration, testing, and accessible interfaces closely matches my experience.
This illustrative paragraph does two useful things: it gives evidence and keeps the limitation honest. “I am a fast learner” on its own does neither.
Use the tailoring checklist to put your strongest relevant examples near the top of your CV.
Make a decision and move on
Apply when the central work fits, the practical conditions work, and the gaps are explainable. Clarify first when one unanswered question determines whether the job is possible. Skip when the role mainly requires a capability you cannot yet demonstrate.
For a stretch application, set a reasonable time limit. It is fine to take a chance; it is less useful to spend an entire day arguing with a job description while suitable openings wait.
Your aim is not to prove that you deserve every role you see. It is to recognize the opportunities where a reader can understand why you might succeed.