Skip to main content

​
Overview

Location and preferences act as filters that focus the AI matching engine on jobs the candidate would actually consider. A brilliant technical match is worthless if the job is 200km away and the candidate only wants to work within cycling distance. Similarly, a perfect skills match for a full-time on-site role is irrelevant if the candidate only wants remote contract work. By configuring these preferences, you tell Recruitier exactly what to look for — and what to exclude — so every match that surfaces is a genuine opportunity worth your time and the candidate’s attention.

​
Setting the Candidate Location

​
Google Maps Autocomplete

When you set or update a candidate’s location, Recruitier provides a Google Maps autocomplete field. As you type, it suggests matching locations:
  • Cities: “Amsterdam”, “Rotterdam”, “Utrecht”
  • Neighborhoods: “Amsterdam Zuidoost”, “Rotterdam Centrum”
  • Specific addresses: “Keizersgracht 520, Amsterdam”
  • Regions: “Randstad”, “Noord-Holland”
When you select a suggestion, the system captures three pieces of data:
DataPurposeExample
Display nameHuman-readable location shown in the UI”Amsterdam, Netherlands”
Latitude and longitudePrecise coordinates for distance calculations52.3676, 4.9041
Normalized nameStandardized location format for consistent display”Amsterdam, North Holland, Netherlands”
All three are stored on the candidate profile and serve different purposes in the matching pipeline.
Use city-level locations for most candidates. Street-level precision is rarely needed for job matching, and city-level gives a more natural search radius. If a candidate lives on the border of two cities, pick the one they identify with most or the one closer to the job market they are targeting.

​
Automatic Geocoding

If you enter a location as text without using the autocomplete picker (for example, when editing a profile directly or when location is extracted from a CV), Recruitier attempts to geocode it automatically through a multi-step process:
1

Dutch City Database

The location string is first checked against a comprehensive database of Dutch cities. This provides fast, accurate resolution for the most common case (Dutch candidates looking for Dutch jobs).
2

Nominatim API

If the location is not found in the Dutch city database, it is sent to the Nominatim geocoding API (the open-source geocoding service behind OpenStreetMap). This handles international locations and less common Dutch addresses.
3

AI Normalization

For ambiguous or non-standard location strings (e.g., “somewhere near Rotterdam”, “Randstad area”, “close to Schiphol”), AI-based normalization resolves the location to the most likely coordinates.
If geocoding fails entirely (due to a completely unrecognizable location string), the text is stored but distance-based matching will not be available until valid coordinates are set.
Distance-based matching requires coordinates. If a candidate’s location has not been successfully geocoded (no latitude/longitude), the matching engine skips the location filter entirely and shows jobs regardless of distance. The location penalty factor defaults to 1.0 (no penalty), which means distant jobs will not be penalized. Setting a proper geocoded location ensures relevant geographic results and prevents your candidate from being matched to jobs across the country when they only want local opportunities.

​
Search Radius Configuration

The search radius defines how far from the candidate’s location the AI should look for jobs. This is specified in kilometers and defaults to 40 km when adding a new candidate through the upload wizard. The slider ranges from 5 km to 200 km.
RadiusTypical Use CaseDutch Context
10-15 kmUrban candidates who want to stay in their cityWithin Amsterdam, within Rotterdam
25-30 kmCandidates open to nearby citiesAmsterdam to Amstelveen/Haarlem, Rotterdam to Delft
40 kmDefault. Good for metro areasCovers the core Randstad from a central location
75-100 kmCandidates open to a wider regionAmsterdam to Utrecht, Rotterdam to Eindhoven
150+ kmCandidates willing to relocate or travel extensivelyCross-country coverage

​
How Radius Affects Matching (The Location Penalty)

The search radius does not create a hard cutoff at the boundary. Instead, it defines a three-zone scoring system with graduated penalties:
Jobs located within the candidate’s preferred radius receive the full match score with no location penalty. If a candidate sets a 50km radius and a job is 30km away, it receives a location factor of 1.0 — no reduction.This is the “sweet spot” where the candidate is comfortable commuting.
Jobs between the preferred radius and twice the preferred radius receive a gradually decreasing score. The penalty is applied using linear interpolation:
  • At exactly 1x the radius: factor = 1.0 (no penalty)
  • At 1.5x the radius: factor = 0.85 (15% penalty)
  • At 1.9x the radius: factor = 0.73 (27% penalty)
  • At exactly 2x the radius: factor = 0.7 (30% penalty)
This graduated approach ensures that a great job just outside the preferred radius is not completely hidden, while jobs at the far edge of acceptability receive a meaningful penalty that pushes them down the rankings.Example: For a 50km radius, a job at 75km (1.5x) gets an 85% location factor. If the AI scored this match at 90%, the final score would be 90% x 0.85 = 76.5%.
Jobs beyond twice the preferred radius are excluded entirely from search results. They are not retrieved, not scored, and never shown to you. For a 50km radius, this means jobs beyond 100km are invisible.This hard cutoff prevents the system from wasting scoring resources on jobs that are clearly too far away.
The default search radius is 40 km when adding a new candidate through the wizard. For most candidates in the Netherlands, this covers their local metro area and surrounding cities. For a candidate based in Amsterdam with a 40km radius, this covers Amsterdam, Haarlem, Hilversum, Almere, and surrounding areas. Jobs up to 80km are visible (with penalty), and beyond 80km they are excluded. You can adjust the radius at any time from the candidate’s profile.

​
Remote Jobs and Location

Jobs marked as remote bypass the location filter entirely. They always receive a location factor of 1.0 (no penalty), regardless of the candidate’s location or search radius:
  • A candidate in Maastricht with a 25km radius will still see remote jobs from companies in Amsterdam
  • A candidate in Groningen with a 10km radius will see remote jobs from Rotterdam
  • The location penalty calculation is simply skipped for remote positions
This means that enabling the “Remote” flexibility preference effectively opens up the entire job database for remote-flagged positions, regardless of geographic constraints.
For candidates who are truly location-flexible (willing to relocate or work remotely), consider setting a large radius (150km+) AND enabling the Remote preference. This gives you the widest possible job pool while still applying geographic scoring to on-site and hybrid roles.

​
Jobs Without Location Data

Some job listings do not include a specific location or the location could not be geocoded. When either the candidate or the job is missing coordinate data, the location penalty defaults to 1.0 (no penalty). This means:
  • Jobs without coordinates are treated as if they are within the candidate’s radius
  • Candidates without coordinates see jobs from all locations without penalty
This is a deliberate design choice to avoid hiding potentially relevant jobs due to missing data. However, it means that candidates without proper geocoded locations may see geographically irrelevant matches. Always ensure your candidates have a properly geocoded location.

​
Salary Expectations

Configure the candidate’s salary expectations to help evaluate matches:
  • Minimum salary — The lowest acceptable compensation
  • Maximum salary — The target or ideal compensation
These values are stored on the candidate profile as salary_expectation_min and salary_expectation_max.
Many job listings in the database do not include salary data. When a job listing does not have compensation information, salary filtering is not applied and the match is evaluated based on other factors (skills, title, experience, location). Salary preferences are most useful when your job database has compensation information, which varies by source and market.
Even when salary data is sparse in job listings, setting salary expectations on the candidate profile is still valuable. It helps you, as the recruiter, quickly filter and prioritize matches during your review. You know the candidate’s range, so you can mentally assess each match against it.

​
Job Type Preferences

Set which types of employment the candidate is open to:
Job TypeDescriptionCommon Use Case
Full-timeStandard full-time employment (36-40 hours)Most common preference
Part-timePart-time or reduced hours positionsParents, students, semi-retired professionals
ContractFixed-term contract or freelance engagementsContractors, interim professionals, ZZP-ers
You can select multiple job types. If no preference is set, the matching engine defaults to searching for all three types (full-time, part-time, and contract).
For contractors and freelancers in the Netherlands (ZZP-ers), select “Contract” and potentially “Full-time” as well. Many companies post contract roles as full-time positions, and having both selected ensures you do not miss these opportunities.

​
Flexibility Preferences

Define the candidate’s work arrangement preferences:
FlexibilityDescriptionImplications for Matching
On-siteIn-office work at the employer’s locationLocation and radius are critical; only nearby jobs make sense
HybridMix of office and remote workLocation matters but radius can be slightly larger
RemoteFully remote positionsBypasses location filter entirely (factor = 1.0)
Like job types, you can select multiple flexibility options. These preferences are passed as filters to the vector search stage. If no flexibility preference is set, all arrangements are included.
If a candidate only wants remote work, make sure “Remote” is selected as a flexibility preference. Without this, the location filter may exclude remote jobs that are posted by companies far from the candidate. Conversely, if a candidate does NOT want remote work, make sure “Remote” is not selected to avoid being flooded with remote positions that do not match their preference.

​
How Preferences Affect the Matching Pipeline

All preferences work together to narrow the job search in a layered filtering approach: 
Full Job Database (thousands of active positions)
  |
  |-- Filter: is_active = true (only active jobs)
  |-- Filter: posted within last 6 months (recency)
  |-- Filter: has company name (data quality)
  |-- Filter: not staffing/recruiting agency (exclude competitors)
  |
  |-- Filter by job type (full-time, part-time, contract)
  |-- Filter by flexibility (on-site, hybrid, remote)
  |-- Filter by location + radius (exclude beyond 2x radius)
  |
  |-- Score by location (penalize jobs between 1x and 2x radius)
  |-- Score by skills vector similarity (45% weight)
  |-- Score by title vector similarity (35% weight)
  |-- Score by experience vector similarity (20% weight)
  |
  |-- AI Score by role fit, skills fit, experience fit, secondary fit
  |-- Apply location penalty to final score
  |
  |-- Final ranked list (up to 200 matches)
The more specific the preferences, the more targeted the results. Setting tight preferences produces fewer but more relevant matches. Broader preferences cast a wider net but may include less relevant opportunities.
Start with moderate preferences and tighten them if needed. It is easier to narrow down from a large result set than to miss opportunities by being too restrictive upfront. If a candidate receives 150+ matches with too many irrelevant ones, tighten the radius or be more specific about job types. If they receive fewer than 20 matches, consider broadening the radius or adding more flexibility options.

​
Automatic Re-Matching on Location Changes

When you update a candidate’s location or search radius, Recruitier detects that these changes affect matching results and automatically triggers a re-match. The system monitors the following fields as re-match triggers:
FieldTrigger Condition
LocationText value changed
LatitudeCoordinate value changed
LongitudeCoordinate value changed
Preferred radiusRadius value changed (in km)
When any of these change, the matching pipeline runs again with the updated parameters. The re-matching process:
  1. Identifies all existing protected matches (favorited, applied, contacted, interviewing, offer stage, placed)
  2. Collects protected match job IDs into an exclude list
  3. Runs the full 5-stage matching pipeline with updated location parameters
  4. Adds new matches alongside existing protected ones
  5. Old pending matches that are no longer geographically relevant may be replaced
Re-matching replaces pending matches (those in the “New Matches” stage) with fresh results based on the new location. Matches that you have already interacted with — favorited, contacted, interviewing, applied, offer stage, or placed — are always preserved and will not be removed. Only unacted-upon pending matches are affected.
Changes to salary expectations, job type preferences, or flexibility preferences do not automatically trigger re-matching. If you update these preferences and want new matches, you can manually trigger a re-match from the candidate profile. This is by design to prevent excessive re-matching from minor preference tweaks.

​
Configuring Preferences: Best Practices

Ask the Candidate

Do not guess on preferences. A 5-minute conversation about location tolerance, salary expectations, and work arrangement preferences saves hours of reviewing irrelevant matches. Ask specifically: “What is the furthest you would commute daily?” and “Would you consider fully remote?”

Consider the Dutch Market

In the Netherlands, the Randstad area (Amsterdam, Rotterdam, The Hague, Utrecht) is densely connected by public transport. A 50km radius from Amsterdam covers most of this region. For candidates outside the Randstad (e.g., Eindhoven, Groningen, Maastricht), a larger radius (75-100km) may be needed to reach enough job opportunities.

Update When Priorities Change

Candidates’ preferences evolve. If someone initially wanted on-site work but is now open to hybrid, update the profile. Similarly, if a candidate initially set a 25km radius but realizes they need to widen their search, increasing to 50km triggers re-matching and surfaces new opportunities.

Use Remote for Max Coverage

If a candidate is truly flexible about remote work, enabling the “Remote” preference dramatically expands their job pool. Remote jobs bypass the location filter entirely, meaning a candidate in Maastricht can match with remote opportunities from companies anywhere in the Netherlands (or beyond).

​
Advanced

​
The Location Penalty Formula

The location penalty is a deterministic calculation applied after AI scoring. It is multiplicative, meaning it reduces the AI score by a percentage based on distance. Here is the exact formula: 
if distance <= preferred_radius:
    location_factor = 1.0

elif distance <= 2 * preferred_radius:
    # Linear interpolation from 1.0 to 0.7
    ratio = (distance - preferred_radius) / preferred_radius
    location_factor = 1.0 - (0.3 * ratio)

elif distance > 2 * preferred_radius:
    # Excluded during search (never reaches scoring)
    location_factor = N/A (job not retrieved)

# Special cases:
if job_is_remote:
    location_factor = 1.0

if candidate_has_no_coordinates or job_has_no_coordinates:
    location_factor = 1.0
Applied to the final score: final_score = ai_score * location_factor Example calculations:
Candidate RadiusJob DistanceLocation FactorAI ScoreFinal Score
50 km30 km1.085%85%
50 km60 km0.9485%80%
50 km75 km0.8585%72%
50 km95 km0.7385%62%
50 km100 km0.7085%60%
50 km101 kmExcluded85%N/A
50 kmRemote1.085%85%

​
How Geocoding Works Internally

The GeocodingService follows a cascading resolution strategy designed for the Dutch market:
  1. Dutch City Database: A pre-loaded list of Dutch cities with their coordinates. This provides sub-millisecond resolution for the most common case. Cities are matched case-insensitively with common variations handled (e.g., “Den Haag” and “‘s-Gravenhage” both resolve to The Hague).
  2. Nominatim API: For locations not in the Dutch database (international locations, specific addresses, neighborhoods), the Nominatim API provides geocoding. This is the same service that powers OpenStreetMap search. Results include coordinates, display name, and a normalized address string.
  3. AI Normalization: For location strings that neither the database nor Nominatim can resolve (ambiguous descriptions, regional names, informal location references), AI-based normalization attempts to interpret the intent and map it to specific coordinates. For example, “Randstad area” might resolve to a central point like Utrecht.

​
Interaction Between Location and Other Filters

The location filter interacts with other matching parameters in specific ways:
  • Staffing/recruiting agency exclusion: Applied before location filtering. Jobs from staffing agencies are excluded regardless of location.
  • Recency filter (6 months): Applied before location filtering. Old jobs are excluded regardless of proximity.
  • Job type and flexibility filters: Applied at the same stage as location. These are AND conditions — a job must pass all filters to be included.
  • Vector search: Runs after all filters are applied. The fetch limit of 400 provides a buffer for post-filtering, with a display limit of 200 final matches.

​
Preferences Stored as JSONB

Job type preferences and flexibility preferences are stored as JSONB arrays on the candidate entity:
  • preferred_job_types: ["full-time", "contract"]
  • preferred_flexibility: ["hybrid", "remote"]
  • preferred_locations: JSONB array of preferred location objects (for candidates who want to search in multiple areas)
This JSONB storage allows flexible multi-selection without requiring separate database tables for preferences. The matching pipeline reads these arrays and applies them as filter criteria during the vector search stage.

​
Power-User Tips

For candidates targeting the Randstad: Set the location to Utrecht (central) with a 50km radius. This single configuration covers Amsterdam, Rotterdam, The Hague, and Utrecht — the four major cities of the Randstad. You can then let the location penalty naturally prioritize closer jobs.
For fully remote candidates: Set a reasonable home location (for hybrid job matching) but enable the “Remote” flexibility preference. This gives you the best of both worlds — local hybrid/on-site jobs are location-scored normally, while remote jobs from anywhere appear without penalty.
Watch for the “no coordinates” default. If a candidate or job has no geocoded coordinates, the location factor defaults to 1.0 (no penalty). This means distant jobs appear with artificially high scores. If you notice a candidate getting many geographically inappropriate matches, check that their location has been properly geocoded with latitude/longitude values.
Changing preferences like job type and flexibility does not trigger automatic re-matching (unlike location changes, which do trigger it). If you update these preferences and want fresh results, manually trigger a re-match from the candidate profile. This design prevents unnecessary re-matching from minor preference adjustments.