I Built a Tool That Matches Your Tech Stack Against 435 Live JavaScript Job Listings

I run a small JavaScript job board called JSGuruJobs. Over the past year and a half, I've manually curated about 435 job listings — reading each one, tagging the technologies, and adding them to the database.

A few weeks ago I had a simple question: if I were a candidate with my own stack, how many of these jobs would I actually qualify for?

I couldn't find a tool that answered this using real, current job data. Most career tools use survey data or self-reported salaries. I wanted something based on what employers are actually asking for right now.

So I built one.

What it does

You enter your tech stack — say React, TypeScript, and Node.js — and the tool checks it against every active listing in the database. You get back:

• What percentage of jobs match your skills
• How many are strong matches (50%+ skill overlap) vs partial matches
• Which countries have the most matching jobs
• The top 5 skills you could add to unlock the most additional jobs

That last part turned out to be the most interesting. Instead of generic "learn TypeScript" advice, it tells you specifically: "Adding Next.js would unlock 47 more jobs for your current stack." The recommendation is different for everyone because it depends on what you already know.

You can try it here: jsgurujobs.com/match

How it works

The architecture is simple. Every job in my database has a tags field — a JSON array of technologies extracted from the listing. When you submit your stack, the controller does three things.

1. Match calculation

For each job, I normalize both the job's tags and the user's input to canonical names (so "node", "Node.js", "nodejs" all become "Node.js"), then count the overlap:

$overlap = $jobTags->intersect($userStackSet)->count();
$totalJobTags = $jobTags->count();
$ratio = $overlap / $totalJobTags;

if ($ratio >= 0.5) {
    $strong++;    // Strong match: you know half or more of what they want
} elseif ($overlap >= 1) {
    $partial++;   // Partial match: at least one skill overlaps
}

I went with a 50% threshold for "strong match" after testing. A stricter threshold (requiring all tags to match) made the results feel too pessimistic — most listings ask for 6-8 technologies, and nobody knows all of them. A looser threshold made the results meaningless. 50% felt right: if a job asks for React, TypeScript, Node.js, and PostgreSQL, knowing React and TypeScript gets you a strong match.

2. Skill recommendations

This was the trickiest part to get right. For each technology that the user does NOT already know, I count how many currently-unmatched jobs contain that technology:

foreach ($allJobs as $job) {
    if ($alreadyMatchedSet->has($job->id)) continue;  // skip jobs user already matches

    foreach ($jobTags as $tag) {
        if ($userStackLower->contains(strtolower($tag))) continue;  // skip skills user has
        $techBoosts[$tag]++;
    }
}

The key insight: I only count jobs the user does NOT already match. If you already match a job that requires Next.js, adding Next.js to your stack doesn't unlock anything new. This makes the recommendations genuinely personalized rather than just "here are the most popular technologies."

3. Tag normalization

This turned out to be where most of the bugs lived. Job listings use inconsistent naming: "Node", "Node.js", "nodejs", "NodeJS" all mean the same thing. I built a normalization map:

$aliases = [
    'js' => 'JavaScript',
    'javascript' => 'JavaScript',
    'ts' => 'TypeScript',
    'node' => 'Node.js',
    'nodejs' => 'Node.js',
    'node.js' => 'Node.js',
    // ... about 40 more mappings
];

Not elegant, but it works. And it needs to work both ways — normalizing user input and normalizing job tags — so the same map handles both.

What I learned from the data

After launching and watching people use it, a few patterns stood out.

React + TypeScript is the baseline. These two together match roughly 55-60% of all listings. If you're a JavaScript developer and don't know TypeScript yet, you're excluding yourself from the majority of the market.

The third skill matters more than you'd think. Going from React + TypeScript to React + TypeScript + Node.js jumps you from ~60% to ~75%. That one addition opens up all the fullstack roles.

Some skills have almost zero marginal value. If you already know React, adding Vue.js unlocks very few new jobs — most Vue jobs don't also require React, and most React jobs don't care about Vue. Your time is better spent learning Node.js or Next.js.

Country distribution is uneven. About 35% of all JavaScript listings are in the US, but some technology combinations skew heavily toward specific regions. Node.js + TypeScript is disproportionately popular in Germany and Poland, for example.

Technical decisions I'd make differently

Server-side rendering was the right call. The form submits as a GET request with the stack in the query string: /match?stack=react,typescript,nodejs. This means every result is a shareable URL, and Google can index the empty state page. If I'd built it as a client-side SPA, I'd have lost both of these.

I should have added caching earlier. Every form submission runs a query against all 435 jobs. At my current scale this is fine (takes ~50ms), but I can already see it becoming a problem if traffic grows. A simple cache layer with a 1-hour TTL would solve it.

The normalization map should be in the database. Having 40+ hardcoded aliases in a PHP array works, but every time I encounter a new variation in a job listing ("React.js" vs "ReactJS" vs "react"), I have to update the code. A database table would be cleaner.

Try it

The tool is free, no signup required: jsgurujobs.com/match

If you find a bug or have an idea for what to add, I'd genuinely appreciate hearing about it — I'm building this solo and feedback is how I learn what matters.

If you're curious about the JavaScript job market more broadly, the JSGuruJobs job board has all 435 listings browsable by technology and country.