We Built a CV Scanner That Compares Skills Against Real Jobs. Then Production Exposed a Bottleneck.

Derrick Muturi — Fri, 06 Nov 2026 12:14:56 +0000

Building an AI-powered application is one thing. Getting it to behave reliably when someone actually uses it is another.

I've been building Glassbox, a tool that compares the skills on a CV against skills mentioned in real tech job descriptions.

The idea is straightforward: instead of assigning someone an unexplained career score, show them where their documented skills overlap with what employers are asking for.

But the engineering turned out to be much more interesting than the original idea.

How the pipeline works

At a high level, Glassbox:

Reads the uploaded CV and extracts its skills.
Retrieves relevant tech job descriptions.
Normalizes and compares the extracted skills against the job market.
Uses title embeddings to help match relevant roles.
Produces an analysis of skills in demand, overlaps and potential gaps.

The application uses a Next.js frontend, a Python backend, PostgreSQL, and an ONNX-based embedding component.

One design principle has been important throughout: the results need to be explainable. Seeing that six of the ten most-requested skills for a role are already on your CV is more useful than receiving a mysterious 60% hiring score.

When production started struggling

A recent production investigation uncovered a particularly expensive part of the pipeline.

We measured two live scan requests:

Stage	Request A	Request B
Job search	15.7s	16.6s
Embedding	27.1s	31.1s
Scoring	0.23s	0.22s
Total request	51.8s	57.3s

PDF extraction was almost negligible.

The surprising part wasn't the AI model itself. It was the amount of repeated work being performed around it.

Embedding thousands of job titles for each comparison could consume more time than extracting CV skills and scoring results combined.

Earlier, we had also investigated a memory-sensitive embedding path and introduced bounded inference batches of 32 inputs.

Introducing a bounded embedding cache

We then implemented a cache for job-title vectors.

The reasoning was simple: job titles frequently repeat across requests. If the same title has already been embedded by the same model, we shouldn't perform the inference again.

We deliberately kept the cache bounded at 4,096 entries instead of letting process memory grow indefinitely.

Importantly, CV-derived profiles remain outside that cache.

We benchmarked the change against the same synthetic workload containing 4,000 jobs.

Run	Before	After
Cold	9.68s	8.02s
Warm run 1	13.03s	1.24s
Warm run 2	8.27s	1.14s

The fixture-backed responses produced identical JSON hashes before and after the change, including the job ordering and the 3,893 jobs retained by the existing role filter.

That mattered. A performance improvement that silently changes the analysis is not necessarily an improvement.

The important caveat

These were local synthetic benchmarks, not production end-to-end measurements after deployment.

Only three runs were performed, so they aren't enough to establish reliable latency percentiles.

And there's another constraint: the backend can scale to zero, meaning an in-memory cache is lost whenever the container shuts down.

Cold scans still need embedding, and job retrieval alone was taking roughly 16 seconds in the measured production requests.

So caching helps, but it doesn't finish the optimization story.

What building Glassbox has taught me

Three lessons stand out:

Measure stages separately. An endpoint taking 50 seconds tells you very little until you know where those seconds are going.

Preserve behavior when optimizing. Identical output and bounded memory mattered just as much as lower latency.

Building a working AI demo isn't the same as building a usable product. Loading states, production failures, long waits and recovery paths are part of the user experience.

We're still improving Glassbox, and I'm interested in hearing how other developers approach caching, CPU inference and latency in resource-constrained applications.

If you're curious about the product itself, you can try it here:

Glassbox

And if you've built a similar pipeline, I'd especially love to know: how do you balance cold-start costs against keeping an inference service warm?

What Do Entry-Level Software Jobs Actually Ask For Compared With Senior Roles?

Derrick Muturi — Wed, 14 Oct 2026 08:58:12 +0000

People often talk about entry-level software jobs as if they’re just senior roles with a smaller salary. But do the job advertisements actually ask for the same skills?

I wanted to look beyond the usual discussions and compare what employers list in their job ads.

I collected software job advertisements for the week of October 12, 2026, and compared 559 entry-level jobs with 2,237 senior jobs. Here’s what stood out.

1. Entry-level jobs list fewer required skills, but the list isn’t exactly short

The typical entry-level software job in the sample listed four required skills. For senior roles, that number was six.

That’s a difference, but four required skills can still represent a substantial amount of knowledge, particularly for someone trying to land their first job.

And the number of skills alone doesn’t tell us how difficult those requirements are. Four highly specialized skills can be a bigger barrier than six familiar ones.

Still, the difference suggests that the advertisements distinguish between what they expect from someone starting out and what they expect from a senior engineer.

2. C++ appears more often in entry-level ads

One result I found interesting was the difference in programming languages.

C++ appeared in 29% of the entry-level ads, compared with 14% of senior ads.

That’s roughly twice the share.

Kubernetes showed the opposite pattern. It appeared in 12% of entry-level ads and 25% of senior ads.

These are two examples of how skill mentions can vary between experience levels. They don’t tell us why employers ask for particular skills, or whether those skills are essential to doing the job.

But they do raise an interesting question: how much do the skills employers advertise for entry-level roles differ from those they advertise for experienced engineers?

3. Some entry-level ads mention several programming languages

Of the 559 entry-level ads, 222 (about 40%) mentioned at least three programming languages.

That might sound like a lot for a role aimed at someone starting their career.

There’s an important qualification, though: this count includes languages mentioned as nice to have, not just languages listed as requirements.

It would be misleading to interpret this as meaning that 40% of entry-level jobs require candidates to know three or more languages.

It’s a count of what the advertisements mention, not a measure of what candidates must master before applying.

That distinction matters when we’re trying to understand what job ads actually communicate to people entering the industry.

What can we conclude?

These numbers offer a snapshot of how the collected advertisements describe entry-level and senior software roles. They don’t tell us everything about hiring practices, and they can’t establish what the wider job market looks like.

The data covers one week of advertisements from selected company career boards and other sources. The sample leans toward US-based tech and AI employers, so it isn’t representative of every employer or region.

I built Glassbox to count the skills and requirements that appear in tech job ads and make those patterns easier to examine.

I’ll be updating the counts weekly. It’ll be interesting to see which differences persist and which change as the collected job advertisements change.