Remote jobs are not always work-from-anywhere: a filtering guide

Separate four questions that a remote badge cannot answer

A person in Montréal searches for a remote role and finds a posting labelled “Remote — New York.” Can they apply? The badge alone cannot answer. New York might be an office location, a required residence, an administrative posting location or one of several eligible regions. The description may settle the question, but sometimes it does not.

Model four dimensions: work arrangement, permitted work locations, attendance or travel conditions, and working-hours requirements. Treat work authorization as a further condition when the employer states one. A country match in a jobs database is not proof of the person’s authorization to work there.

These dimensions can coexist. A job may be remote within Canada, require quarterly travel to Toronto and require overlap with Pacific business hours. Reducing that record to remote=true removes information the applicant needs to make a decision.

Search for candidates before making eligibility claims

Use remote and country filters to narrow the catalogue, then inspect complete postings for candidates you will display as suitable. The Jobs API remote filter is useful for retrieval. It is not a verification of every applicant’s eligibility, and country membership does not capture every restriction buried in employer prose.

This request retrieves a bounded Canadian remote-job sample with text and optional source fields. For a national remote search, do not automatically add a province filter: a posting may identify Canada without naming every province. An unnecessarily narrow retrieval query can discard a suitable job before your eligibility logic sees it.

Keep all supplied locations. A multi-location role can list several valid alternatives; flattening it to the first city changes its meaning. Follow up on source fields and descriptions when they add an explicit restriction, and keep the original source URL available for the reader.

curl --fail-with-body --get https://api.thejobsapi.com/v1/jobs \
  -H "Authorization: Bearer $THEJOBSAPI_KEY" \
  --data-urlencode 'country=CA' \
  --data-urlencode 'remote=true' \
  --data-urlencode 'description=text' \
  --data-urlencode 'source_fields=true' \
  --data-urlencode 'limit=10'

• Remote and location search filters
• Location handling

Store the evidence behind the normalized result

A useful extraction record stores the source field or exact excerpt, the interpretation, the source check time and the rule or model version that produced it. This lets you explain a rejection and recompute it when the posting changes. The extracted interpretation belongs to your application; it should not replace the original employer wording.

Prefer explicit requirements over a guess from the employer’s headquarters, salary currency or website domain. “CAD 90,000” identifies a currency when stated; it does not establish where an employee must live. An office address may describe the employer without restricting a remote position.

When evidence conflicts, preserve the conflict. A structured remote flag alongside “three days per week at our Vancouver office” needs review or a hybrid classification supported by the text. Do not quietly choose whichever value makes the job qualify for more searches.

{
  "sourceExcerpt": "Remote within Canada; quarterly travel to Toronto required.",
  "sourceField": "description_text",
  "arrangement": "remote",
  "allowedCountries": ["CA"],
  "attendance": "quarterly travel to Toronto",
  "interpretationStatus": "supported_by_excerpt",
  "extractorVersion": "rules-v1"
}

The record is still incomplete for a specific person. It says nothing about whether that person can travel, satisfy the hours or meet other requirements. Attach those checks separately rather than storing a universal “eligible” label on the job.

Use match, conflict and unknown as separate outcomes

Binary logic creates two bad defaults: treating missing evidence as permission, or hiding every job that lacks a well-structured field. Use three outcomes for each hard constraint. “Match” means evidence supports the constraint; “conflict” means evidence contradicts it; “unknown” means you cannot establish either conclusion.

Combine mandatory conditions conservatively. Any established conflict prevents a verified match. If there is no conflict but a required check is unknown, the overall result remains unknown. Only call the relevant constraints satisfied when all of those checks pass. This does not establish overall hiring eligibility or suitability.

Alternative locations use different logic. If the employer allows Canada OR the United States, an applicant need not live in both. But “must live in Canada AND attend Toronto quarterly” has two requirements. Keep the original relationship between conditions; a flat list of place names cannot represent it.

function combineRequiredChecks(checks) {
  if (checks.length === 0) return 'unknown';
  if (checks.some(check => check === 'conflict')) return 'conflict';
  if (checks.every(check => check === 'match')) return 'match';
  return 'unknown';
}

combineRequiredChecks(['match', 'unknown']); // unknown
combineRequiredChecks(['match', 'conflict']); // conflict

Test the cases that break simple keyword rules

Start with synthetic cases whose expected results are explicit, then add reviewed real examples from your product. Synthetic cases make the logic easy to inspect; they do not measure how frequently a failure occurs in your live inventory. Keep a separate evaluation sample across employers and hiring systems for that.

The matrix below uses fictional wording. The outcome refers only to the stated remote/location request and known user context. It is not a complete assessment of the person’s qualifications. Each row includes the reason, because a correct label for the wrong reason is a fragile test.

Also test mixed alternatives, conflicting structured fields and prose, and travel the applicant has not confirmed. Do not let “work from anywhere” override a later explicit country restriction. Preserve both passages and route the contradiction for review.

Design useful results for uncertain jobs

Unknown does not have to mean invisible. A strict “verified location fit” view can show supported matches, while a separate “check location requirements” section can include relevant jobs with unresolved conditions. Explain the difference before a user invests time in an application.

Use specific labels: “Remote within Canada,” “Hybrid in Toronto, two office days weekly,” or “Remote; applicant locations not specified.” Show a short source excerpt for an important restriction. Avoid a green eligibility checkmark next to an unresolved field, even if a small disclaimer appears elsewhere.

Give users control over uncertainty. Someone searching casually may want unspecified-pay or unclear-location roles. Someone who cannot travel needs a stricter view. Store that preference separately from your evidence so changing the display policy does not rewrite the source facts.

Measure false promises and missed opportunities

Review a sample of results labelled as matches. Count how many are actually supported by the original posting for the test applicant’s context. For example, if 50 of 60 reviewed recommendations have supported location fit, precision in that sample is 50 / 60, or 83.3%. Record the ten failures by cause; do not present this hypothetical result as product performance.

Also review excluded and unknown results. A filter can obtain high precision by showing almost nothing. To measure missed suitable jobs, create a separately reviewed set of eligible examples and see how many the system retrieves and classifies correctly. Include national postings without city fields so you catch overly narrow retrieval filters.

Track the unknown rate separately from errors. If an employer does not disclose restrictions, preserving uncertainty is correct. If your extraction missed a clear sentence in the description, that is a fixable error. Those situations need different actions, even if both initially produce an unknown label.

Re-evaluate when the underlying posting changes

Location conditions can change while the job ID remains stable. Store a signature or version for the evidence used in the decision. When the relevant source content changes, rerun extraction and eligibility checks, then update search indexes, saved recommendations and alert queues that depend on the result.

Keep a correction path for users and reviewers. A report such as “this role now requires office attendance” should lead to a source recheck, a corrected classification and a regression example. Do not edit only the visible badge while leaving stale eligibility in the recommendation service.

Before launch, walk one supported match, one explicit conflict and one unknown through retrieval, storage, display and an update. That small end-to-end exercise is more valuable than assuming a remote filter proves the whole product is handling location correctly.