See exactly what to learn next
Close the gap between you and the role you want.
Changing roles or levelling up? The Skills-Gap Analyzer turns ‘what should I learn?’ into a concrete list. Pick a target role and it shows the core skills that role actually requires, checks them against your resume or a list of your skills, and splits them into what you already show and what's worth adding — with a match percentage so you know how close you are.
For every missing skill it gives you a free way to start learning it today (a curated YouTube search and a course search), so the gap becomes a plan. Add the skills honestly, re-check your fit against a real job in TrueFit, and rehearse the interview in AceCoach — all free.
- ✓Core skills for any target role, matched to yours
- ✓Match % plus a clear have / missing split
- ✓A free way to learn every missing skill
- ✓Then re-check your fit and rehearse — free
Reading job postings for the skills that actually matter
Most job descriptions list skills in a jumble of required and preferred, exact and vague, core and nice-to-have. Reading a posting for the real skills it needs requires separating signal from noise. The strongest signal is explicit and repeated. If a posting says 'SQL' three times—in the summary, in a bullet point, and in the required qualifications—SQL is non-negotiable. If it says 'SQL and NoSQL preferred,' that is weaker; you can be missing one and still be viable. Repetition is a good proxy for whether the company actually needs the skill or whether it is filler from a generic job template that has not been customized.
The second signal is specificity. 'Strong communication' is so generic it is nearly useless; every posting says it. 'Experience with event-driven architecture' is specific enough that you can credibly claim it or not. A posting that says 'familiarity with Apache Kafka' is even more specific and tells you the company has a particular technical bet they need you to understand. When you see specificity, take it seriously—companies usually list specific tools because they use them, and vague skills like 'teamwork' or 'problem-solving' are filler that appears in every posting and tells you nothing about how the company works. The specificity rule also works in reverse: if the posting mentions multiple specific databases (PostgreSQL, MongoDB, Redis), the company likely uses that stack and you need at least one. If it only mentions 'databases', they are less particular.
The third signal is context. If the posting emphasizes 'experience with high-scale systems' and mentions databases three times, the core skill is data systems and scale—not front-end frameworks, not DevOps tooling, even if those are listed. The skill hierarchy matters. Reading between the lines also reveals knockout rules disguised as preferences: 'Must have a UK work visa' is non-negotiable despite using softer language. 'BSc in computer science required' is a knockout. The skills analyzer can only check the skills you give it, so read the posting first and decide what the real requirements are versus the wish-list items. A good heuristic: if a skill appears in the 'Required Qualifications' section using 'must', 'required', or years of experience, it is core. If it is in 'Nice to Have' or preceded by 'preferred', it is peripheral.
Identifying skills you already have that the posting doesn't mention
Most people undercount their transferable skills. If you led a team in one role, you've done project management and stakeholder communication—skills applicable to engineering management, product management, and many senior individual-contributor roles. If you've debugged customer issues, you've done root-cause analysis and communication under pressure. If you've worked with databases, you understand data integrity and query performance even if your previous database was PostgreSQL and the new role wants MongoDB. The gap is often smaller than it feels because foundational skills transfer across technologies. A cloud platform specialist who built on AWS has learned the concepts—load balancing, horizontal scaling, managed services—that apply to Google Cloud or Azure. The specific tool is new; the thinking is portable.
The gap analyzer helps by forcing you to name skills you have explicitly rather than assume the posting will see them. A resume that says 'worked on distributed systems' might not match a posting that specifically asks for 'Kubernetes experience,' but both are about managing workloads across machines. You show the overlap in the analyzer and then decide: is Kubernetes something you can pick up quickly given your foundation, or is it a genuine gap? The difference matters for where you focus your learning time. A gap that is 'you know Docker but not Kubernetes' might close in two weeks. A gap that is 'you've never done container orchestration' might take two months. Be precise about the difference.
The common mistake is claiming skills you do not have. In an interview within 20 minutes, most technical claims are testable, and being caught in a lie damages your credibility more than honestly saying 'I haven't used X, but I've built similar systems in Y.' The analyzer is for grounding in reality, not inflating yourself. Some skills are core (usually the early bullets or the named tools); others are core-adjacent (related technologies that show you understand the domain). Be honest about which category each of your skills falls into. If you claim 'expert in PostgreSQL' but have only used it for queries and never tuned indexes or designed schemas, you've overstated. Be the person who says 'I've written SQL queries and debugged performance issues; I have not designed schemas from scratch,' because that credibility is more valuable than an inflated claim.
Prioritising which missing skills are worth learning and how quickly
Not all missing skills are equal. Some are gatekeeping: if the posting asks for 5 years of Go and you have zero Go experience, you're fighting an uphill battle and upskilling before applying makes sense. Others are minor: if the posting wants Go and Rust and you know Go, you're already viable. The rest are about your risk tolerance—do you want to apply knowing you'll need to learn something, or learn first? A useful question to ask: if I do not learn this, am I still employable? If yes, apply and learn on the job. If no, learn first. The bar for gatekeeping skills is typically 'mentioned multiple times' and 'required qualifications', not a single bullet in preferences.
Learning speed matters. Some skills require ramp-up time measured in months (true domain expertise, a complex framework's internals, deeply specialised knowledge). Others you can be credibly dangerous with in weeks (a new database, a syntax-level language difference, a standard library change). The difference usually comes down to how much depth the role needs. If you need to contribute on day one, months of learning is risky. If the team will spend the first month onboarding you, two weeks of learning puts you ahead. Relatedly, ask whether the skill is 'depth' (mastery of one thing) or 'breadth' (knowing multiple things). Breadth skills train faster because you're learning new syntax or tools, not deep principles. Depth skills take longer because you're building mental models.
The Skills Gap Analyzer surfaces free learning paths (curated YouTube searches and course links) for each missing skill. But be ruthless about time allocation. If you're comparing two roles and one requires a skill you'll master in a week while the other requires three months of learning, the effort-to-readiness ratio suggests which to pursue. Conversely, if you're passionate about the field and the gap is a well-established skill everyone needs, learning it once will compound across future roles. The calculus shifts depending on whether you're looking to apply now or building longer-term. A job search with a fixed deadline (visa expiry, relocation date, end of a contract) favors learning-free roles. An open-ended job search favors roles that require investment now but lead to skills you will keep using for years.
Frequently asked questions
What's the difference between required and preferred skills?
Required skills are supposed to be non-negotiable; preferred skills are nice-to-have. In practice, many postings are badly written and 'required' contains wishful thinking. A better test: if the posting lists the skill three times or names a specific tool, it matters. If it appears once as 'familiarity with' or 'experience preferred,' you can be missing it and still win the role.
If I'm missing a skill, should I apply or learn first?
If it is a core skill (named multiple times, specific tool, core to the job), learning makes sense before applying. If it is peripheral, apply anyway—you signal that you understand the domain and can learn the tool. The gap analyzer shows you how close you are to the role; if the match is below 60%, consider learning first to be safer.
How do I know if a skill is worth learning before I apply?
Ask: how fast can I learn it, and how much does the role depend on it? A new framework might take two weeks with solid tutorials; deep expertise in machine-learning infrastructure might take six months. If the role is competitive and the gap is large, spending time learning is reasonable. If the role is not competitive and the gap is small, apply and mention you're keen to learn.
Can I claim transferable skills if I've not used them in the exact context?
Yes, but be specific. 'I've optimised database queries on PostgreSQL and this role uses MySQL' is a genuine transferable skill. 'I've worked with databases, so I can do cloud infrastructure' is not. Transferable skills need a bridge that you can explain in an interview.
What if the posting lists skills I've never heard of?
Search for tutorials or job postings that mention it; that tells you whether it is a core industry skill or a niche tool. If it is a core skill, learning it signals serious career investment. If it is niche, you can note it and apply for roles that align better with your existing expertise.
Part of Job search — 6 free tools in this set.
Part of JobStraight — the honest AI job-search platform. Runs in your browser; your data stays on your device.