How do you find the exact address of a job or internship listing?

A listing often says “Paris”, “Lyon” or “Balma”. That is better than nothing, but it is not yet an address. A large company may have several offices in the same city: a headquarters, sales branches, a technical campus or a regional office. Choosing the headquarters by default would be quick, but often wrong.

Finding the right workplace means answering a more precise question: which office is this listing, team or location reference actually associated with?

What exactly are we looking for?

A usable address contains at least a street, postcode and city. But those three elements are not enough. There also needs to be a credible reason to link the address to the listing.

Imagine a company with three sites in Paris. Its “Our offices” page proves that all three addresses exist. It does not prove that the Data team works at the first site on the list. The task is therefore not simply to find an office, but to show that the role is attached to that office.

That is why two kinds of evidence are kept separate:

• evidence that the location exists: an official office page, branch directory, contact page or public register;
• evidence of assignment: an address published in the listing, an office reference supplied by the recruitment system, a team page or an explicit link between a job family and a site.

A registered office address in legal notices belongs to the first category. On its own, it does not establish that the internship will take place there.

First: read what the listing already publishes

The listing itself remains the best source. The address may be visible on the page, hidden in its structured data or supplied by the company’s recruitment system.

The system collects, among other things:

• street, postcode and city when provided;
• office or campus name;
• team, department or job family;
• a location reference specific to the recruitment system;
• all locations when a role is offered at multiple sites.

When a listing publishes a complete, consistent address, there is nothing to guess: it becomes the reference. If the listing is updated and that address disappears or changes, the old information is not retained indefinitely as if it were still certain.

Two cases call for restraint. A fully remote role is not assigned a physical address. A genuinely multi-city role is not arbitrarily attached to the first location on the list.

Second: recognise the location in the recruitment system

Recruitment platforms often use a stable identifier for an office. It might look like paris-beaubourg, office-42 or an opaque identifier. This reference is very useful.

If one listing contains both the identifier and a complete address, the link can be retained. Another listing from the same company and source with exactly the same identifier can then resolve to that office without repeating the entire search.

This is stronger than matching words alone. Two teams may write “Paris” while working at different sites. A native office reference distinguishes those locations, provided it remains limited to the correct company and recruitment system.

Third: link the team or job family to an office

When the listing contains neither a street nor a usable location reference, the team becomes an important signal. For example, a “Product & Data” unit might be attached to a particular campus, while customer advisers work in branches in their own cities.

The matching process follows a cautious hierarchy:

1. an explicit connection between the listing and office;
2. a previously known native location reference;
3. a rule specific to the team or department;
4. a rule specific to the job family;
5. an office explicitly associated with the city;
6. a single office in the city, only when its professional role is sufficiently established.

The last option can help for a genuinely unique bank branch in a municipality or a clearly identified regional office. It becomes risky when a company has several sites. In that case, the system returns to city-level information rather than choosing at random.

Where the web and AI help

The web is particularly useful when a listing gives a city and team but no street. The search is limited to sources that can provide evidence: the company’s official site, its locations page, branch directory, team page or establishment register.

An AI model can help read these pages, identify passages containing an address and rank the most relevant sources. It can reduce repetitive reading when several listings share the same company, city and team.

It does not decide the displayed address alone. Its suggestion must still pass deterministic checks:

• the quotation must contain the expected street, postcode and city;
• the street number must not be confused with another, such as 1 and 11;
• the assignment evidence must link the team or location to that address in the same passage;
• contradictory sources cause the system to abstain;
• a legal page cannot be turned into evidence of a workplace.

AI therefore acts as a reader and scout, not the final arbiter. Searches are grouped by company and city and cached, so the same problem is not sent to the model for every listing.

How to read the confidence rating

Not all addresses have equally strong evidence. The rating visible on a listing summarises how the result was obtained.

This score is not a mathematical probability. A 4/5 does not mean “an 80% chance”. It indicates the level of evidence and helps explain whether the address comes from the listing, an explicit link or a more contextual estimate.

From text to a point on the map

Once an address is selected, the marker still needs to be placed correctly on the map. In France, the street and number are compared with results from the public Géoplateforme geocoding service.

The first result is not accepted automatically. The number, street and locality must match. For a range such as “27–31 avenue…”, both ends can be checked before placing the marker between them. If the service returns only a nearby street or a point that is too imprecise, no misleading map is displayed.

The map therefore visualises an address that has already been validated. It is not used to invent the location closest to the city centre.

Errors this method aims to avoid

Four errors are particularly easy to make:

• mistaking the registered office for the workplace because it is easy to find;
• choosing the first office in a city when the company has several;
• reusing an old address after a campus or location reference changes;
• publishing an approximate marker on a nearby street because the geocoder ranked it first.

To avoid these shortcuts, evidence is dated, can be withdrawn and becomes unusable when it conflicts. The displayed result can therefore return to “city only” if the information is no longer strong enough.

What you see on Screeningpass

On Screeningpass, the listings page deliberately remains easy to read and displays the city. The detailed listing can show the full workplace, its confidence rating, the nature of the estimate, a link to available evidence and a map marker.

This distinction matters: a useful address is not simply a street found on the web. It is a street connected to the right listing, in the right city, for the right company, with enough evidence to explain why it is displayed.

When serious doubt remains, seeing only the city is not a silent failure. It is the most honest information available. You can browse listings and open their details to see the precision of the proposed location.