The Hidden Engineering Problem in Global Hiring: Jobs Don’t Translate Cleanly Across Borders

QNAQ — Thu, 24 Sep 2026 08:41:18 +0000

A global job platform looks simple from the outside.

A company publishes a job. A person searches for it. They find each other. Everyone is happy. Somewhere, presumably, a bell rings. 🔔

Then you try building the thing.

And discover that the global labour market has spent decades inventing different words, rules and expectations for almost everything.

A job title in London may mean something slightly different in Berlin. A “remote” job in the US may still require the candidate to live in one particular state. €60,000 in Lisbon and €60,000 in Amsterdam are the same number and very different offers.

The difficult part of global hiring is not storing more jobs.

It is making different labour markets understandable to each other.

And that is a much more interesting engineering problem.

Job Titles Are Not IDs

Developers like identifiers. They are clean, predictable and usually mean one thing.

Job titles are none of those things.

Take something simple: Account Manager

Depending on the company, that person may work in sales, customer success, advertising, recruitment, finance or technology.

Now try: Business Development Manager

Sometimes that means outbound sales. Sometimes partnerships. Sometimes market expansion.

And sometimes the job description appears to mean:

“Please somehow make the company grow.”

Very actionable. 😄

If a global job search engine treats titles as exact categories, it loses useful relationships. If it treats everything as similar, search becomes useless.

A better structure looks more like this:

Role family: Commercial
Specialization: Account Management
Skills: Client relationships, Sales, Negotiation, CRM

Now we are not simply matching words.

We are translating meaning.

Seniority Is Surprisingly Chaotic

You would think humanity could agree on what “Senior” means.

We cannot.

One company hires a Senior Engineer with four years of experience. Another wants eight. A third has Junior, Mid, Senior, Staff, Senior Staff, Principal and Distinguished.

At some point the career ladder starts looking like airline loyalty status.

A global recruitment system cannot safely assume that Senior = Senior everywhere.

Seniority may depend on years of experience, technical complexity, team size, management responsibility, decision-making authority and scope of work.

The label helps.

The context helps much more.

Salary Search Gets Weird Fast

Now add money.

A candidate wants jobs paying at least €60,000.

Easy.

Until the database contains:

€60,000 / year
$75,000 / year
£55,000 / year
€4,500 / month
CHF 85,000 / year
₹2,400,000 / year

Currency conversion solves part of the problem.

Only part.

Does the salary include bonuses? Is it gross or net? Twelve payments or fourteen? Stock options? Commission? Healthcare? Company car? Remote allowance?

Suddenly the salary field is no longer a number.

It is a small financial ecosystem.

For international job search, salary data needs structure before it can be compared properly.

{
  "currency": "EUR",
  "period": "year",
  "minimum": 60000,
  "maximum": 75000,
  "variable_compensation": true
}

The system needs structure.

The human still needs the details.

Because people remain strangely interested in being paid correctly.

“Remote” Might Be the Least Precise Word in Hiring

Remote sounds binary.

Remote: yes or no.

Reality is more creative.

Remote worldwide
Remote within the EU
Remote in Germany only
Remote within two hours of CET
Remote, but visit the office once a month
Remote, but only from approved countries
Remote three days per week

One word. Seven completely different situations.

So this: remote = true

is often not particularly useful.

A better model needs to understand work mode, allowed regions, time zones and office requirements.

That is less elegant.

It is also much closer to reality.

A sentence that describes a lot of software engineering, actually.

Languages Have the Same Problem

Language requirements look simple until employers start describing them.

“Fluent English.”

“Business English.”

“Advanced English.”

“Professional working proficiency.”

“Strong communication skills.”

“Comfortable working in English.”

A human can usually understand that these phrases overlap.

A search engine sees different strings.

That means multilingual job search needs normalization too.

A candidate searching for roles that require B2 English should not miss a relevant job simply because the employer wrote “professional English required.”

The machine needs to understand the relationship.

The user should not have to think about it.

Geography Is More Than Latitude and Longitude

Knowing that Berlin is in Germany is easy.

Knowing whether a particular person can realistically take a job there is harder.

A global hiring platform may need to understand several different questions:

Where is the job?
Where can the employee work from?
Where is the candidate now?
Where are they willing to relocate?
Where can the employer legally hire?

Five completely different questions.

All traditionally hiding inside one innocent field called: location

Poor location.

It never asked for this much responsibility.

Search Needs Translation Before It Needs Intelligence

This is usually the point where someone says:

“AI can solve it.”

Sometimes it can.

But before intelligence comes representation.

If the underlying system does not distinguish salary period, work mode, role family, seniority, language requirements and geographic eligibility, then the AI layer has to reinterpret the same chaos again and again.

A cleaner architecture looks something like this:

Raw job data
↓
Normalization
↓
Structured attributes
↓
Search and matching
↓
AI enrichment

AI becomes much more useful after the system has already done some basic thinking.

Very inconsiderate of reality not to fit neatly into a vector database.

The Global Job Market Needs an Internal Language

This may be the most interesting part.

A global hiring platform eventually needs its own internal vocabulary.

Not something users see.

Something the system understands.

For example:

Software Developer
Software Engineer
Développeur logiciel
Softwareentwickler

Different languages. Different conventions. Potentially related roles.

The user should be able to search naturally.

The platform should understand the underlying concept and return relevant results.

That is less like building a traditional job board.

It is closer to building a translation layer between labour markets.

And once you see the problem that way, a lot of product decisions change.

This Is One of the Problems Behind QNAQ

At QNAQ, we think about global hiring as a translation problem as much as a search problem.

Different markets describe jobs differently. Candidates describe experience differently. Salary, location, language, skills and mobility all need context.

The goal is not to force the entire world into one rigid format.

That would be wonderfully organized and completely unrealistic.

The goal is to create enough structure that people and opportunities from different markets can still discover each other.

That is a much more practical definition of global job search.

And probably a more useful one.

qnaq.com

The Interface Can Be Simple Because the Backend Isn’t

The nicest products usually hide enormous complexity.

A user sees: Search jobs

Behind that button may be multilingual search, taxonomy mapping, salary normalization, location rules, remote eligibility, ranking, skills matching, candidate data and AI enrichment.

And that is exactly how it should be.

Users should not need to understand the data model.

They just want a relevant opportunity.

Good software takes complexity away from the user.

It does not pretend the complexity never existed.

Global hiring already has enough edge cases.

We really do not need to invent more. 😄

DEV Community: QNAQ