Most advice about getting noticed assumes a recruiter reads your profile. Usually they don't, at least not first. They run a query, get a list, and open maybe the top twenty results. If your record never enters that list, nothing on it counts: not the achievements, not the metrics you worked hard to quantify, not the Dutch course you finished last spring. The skills recruiters search Netherlands employers rely on are typed as literal terms into a search box, and that is a different thing from the skills you have.

So this is a mechanics problem, not a quality problem. A data engineer with eight years of Airflow and dbt behind her can sit invisible for months because her profile says "building reliable data platforms" instead of naming the tools as discrete entries. The index does not infer. It matches strings.

Below is how those tools work, where profiles fall out of the results, and what to change about your own listing this week.

Your real skill set is fuzzy and layered. You know Kubernetes well enough to debug a failing deployment at 23:00, you can read enough Terraform to be dangerous, and you once spent six months on a Snowflake migration you would not call yourself an expert in. All of that is accurate, and none of it is searchable in that form.

A recruiter's tool holds a much simpler object: a set of discrete strings attached to your record. Either "Kubernetes" is one of them or it isn't. There is no partial credit, no "familiar with", no weighting for how well you actually did the work. The honesty you build into prose ("exposure to Terraform in a supporting role") is invisible to the index and only starts mattering once a human opens the file.

That means you need two lists. One is the truthful, nuanced version that lives in your experience bullets and your interview answers. The other is a flat set of tags whose only job is to put you in the result set. They don't conflict, as long as every tag is something you can defend in a conversation.

Prose explains your skills. Tags decide whether your profile appears at all.

Why "good skills" and "findable skills" are not the same thing

LinkedIn Recruiter, an applicant tracking system, a sourcing tool, the search inside a job board: the pattern is the same everywhere. A structured query runs against indexed fields, filters narrow the output, and a ranked list comes back.

Boolean search recruiters use looks dated and works fine. A query for a Dutch fintech backend role might be assembled as (Java OR Kotlin) AND (Spring OR "Spring Boot") AND (Kafka OR RabbitMQ) NOT recruiter, with filters layered on top for location, seniority and language. Semantic and AI-assisted search exists and is spreading, but it sits alongside explicit term matching rather than replacing it, and most sourcers fall back to literal keywords when they want precision on a hard requirement.

Two things follow from that.

Synonyms are the recruiter's problem to anticipate and yours to solve. If the sourcer writes "Kotlin" and your profile says "JVM languages", you are out of that search. If they write "Power BI" and you wrote "BI tooling", same result. You cannot edit their query. You can make sure your record contains the literal string.

And how recruiters search LinkedIn differs from how they search a CV database in one way that matters practically. On LinkedIn the skills section is a controlled list with its own identifiers, so "Java" is a specific entity rather than a word in a sentence. In a CV database the document gets parsed, and parsing quality varies enormously. A two-column layout, a skills graphic with little progress bars, or a skills block that is really part of an image can be indexed as nothing at all. It is one of several reasons the CV format Dutch employers actually want stays boringly plain.

The keyword query produces a few thousand records. Filters shrink that to something a person can read in an afternoon: location within reach of Eindhoven, current title, years in the field, languages, sometimes availability. Plenty of candidates lose at the filter stage rather than the keyword stage, often on things they could correct in five minutes. A blank location field. A profile that says "Netherlands" when the search was drawn as a radius around Amsterdam. No indication of which languages they can work in.

The mismatch that hides qualified candidates from matching roles

The gap between your vocabulary and the sourcer's usually runs in one of three directions.

- You wrote the outcome, they searched the tool. "Automated the monthly close, cutting three days from the cycle" is a strong bullet and contains zero searchable skill. If that work ran on SAP and Alteryx, those two words belong in the skills list as well as in the story.

- You used your last employer's internal name. In-house platforms, internal frameworks and team-invented job titles are invisible outside the company that created them. Translate every one of them into the market term.

- You used the regional variant. Titles travel badly. "Technology Analyst" may describe precisely what a Dutch company calls a Software Engineer or a DevOps Engineer. Recruiters search the title they are hiring for, not the one printed on your old badge.

There is a Dutch-language layer on top of this. Some roles are sourced in Dutch even when the working language on the team is English: financieel analist, verpleegkundige, projectleider, inkoper. If you are targeting a field where Dutch terminology dominates the market, carrying both the English and the Dutch term somewhere in your profile costs you nothing. It is a narrow version of the broader case for why learning Dutch moves your career here, except the search benefit arrives long before any fluency does.

Then the plain failure: an empty skills field, or three entries in it. A lot of genuinely strong candidates have exactly that. It is rarely modesty. Nobody told them the field was load-bearing.

Treat the skills keywords on your CV Netherlands employers will read, and the skills field on any profile, as two surfaces fed by one source list. Build the list once, properly.

- Step 1: harvest from live job ads, not from memory. Open eight to twelve vacancies you would genuinely apply for, ideally at recognised sponsors (erkend referent) so you are not optimising for jobs that are closed to you anyway. Copy out every hard skill, tool, framework, certification and method they name. Terms that repeat across several ads are the terms recruiters are searching with, because the ad text and the search query usually come out of the same intake conversation with the hiring manager.

- Step 2: keep only what you can defend. If a term shows up in six ads and you have never touched it, that is a learning target, not a tag. Listing it puts you into searches you will lose on the first screening call, which wastes more of your time than theirs.

- Step 3: write the exact string and the common variant. "Amazon Web Services (AWS)". "PostgreSQL" and "SQL", if both are true. "Scrum" rather than "agile ways of working". Spell the acronym out once and use the short form elsewhere, because sourcers type whichever version they happen to be used to.

- Step 4: order by what you want next, not by what you did last. Many tools surface the first handful of skills prominently, and a human scanning a result list reads top down. If you are aiming at platform engineering, platform tooling goes first even if your previous title pointed somewhere else.

- Step 5: put the terms where they actually get indexed. A plain-text skills block on the CV, one line per cluster. The same terms inside the experience bullets where they belong, since some parsers weight that section higher. And the profile skills field filled out completely.

Twenty to thirty-five terms grouped into four or five clusters by function (languages, cloud, data, tooling, domain) is a reasonable target. Ninety terms is worse, not better: you read as unfocused to the person who eventually opens the file, and the extra tags are not winning you searches anyway.

One thing this does not fix is a profile that is findable and then disappointing. Tags get you into the list; the document still has to survive a thirty-second read, which is the same problem a cover letter for an international candidate has to solve once someone is already interested.

Run this against your current CV and profile. It catches most of the common failures without any tooling.

Most people come out of this with three to six fixes. None take long. The effect shows up as inbound messages several weeks later, which makes the whole exercise easy to skip and hard to feel.

Recruiters at Dutch companies screen on work authorisation early, because it decides whether the role is open to you at all. There is no standard field for it in most systems, which produces an odd stand-off: candidates who need sponsorship leave the topic out and hope to raise it later, recruiters who cannot sponsor are trying to filter those candidates away, and recruiters who can sponsor are trying to find them.

Being explicit helps in both directions. One factual line, something like "EU citizen, no permit required" or "requires highly skilled migrant sponsorship, currently on an orientation year permit", saves a call that was going nowhere and makes you visible to the sponsors looking specifically for people in your position. If you are still working out which companies those are, the route from IND sponsor list names to actual applications covers getting from the register to a shortlist, and the guide to finding visa sponsorship jobs in the Netherlands covers where those vacancies surface in the first place.

What none of this requires is publishing your immigration history or your permit expiry date. Current status, and what a new employer would have to do: that is the entire relevant content.

Optimising a fully open profile has a real cost. Once your name, employer and contact route are public and indexed, you get everything the index hands out: the relevant approach from a sponsor in Utrecht, plus the agency mass-mail, the crypto role, the twelve messages about a city you never mentioned. Some people accept that trade happily. People looking quietly while employed, and anyone whose current manager uses the same sourcing tools, often can't.

The other shape is a profile that is searchable by skills without being identifiable by default. The sourcer sees the skill set, the seniority, the location and the authorisation status, runs the same Boolean query, and gets a match. Your name and contact details stay with you until you decide a particular approach is worth answering. Discoverability is unchanged; what changes is who holds the decision about contact.

That is why it makes sense to optimise a candidate profile Netherlands recruiters can query alongside your public one rather than instead of it. Build the tag list once and use it in both places. Which terms deserve the top of that list overlaps heavily with the skills that actually get internationals hired in Dutch tech, worth reading before you decide the order.

ArrowLancer's Talent Search is launching: Dutch hiring teams will be able to search the profiles candidates choose to publish, by skills, and your name and contact details are only shared once you accept. If that is the version of recruiter search you want to be inside, it is on the pricing and features page, and you can browse visa-sponsored jobs while your new tag list is still fresh.