跳到正文
DEV Community· Vladimir Grigoryan·· 3 小時前AI 評分34

職位招聘資訊中的遠端布林欄位未能説明甚麼

What a boolean remote field leaves out of a job posting

AI 導讀

三則工程職位招聘資訊顯示,單一遠端布林欄位未能交代求職者可居住的地點、招聘範圍及附帶條件。文章建議分開記錄招聘地點、工作模式、遠端選項、條件和證據,並明確表示未知,避免把缺失資訊誤當成可全球招聘的承諾。三個例子揭示資料建模問題,但不足以判斷這種情況在整個市場有多普遍。

正文

A job posting marked remote: true still leaves a fairly basic question unanswered: where can the person doing the job actually live?

I checked three engineering postings on 23 October 2026. Their location fields were useful, but each needed more context from the description.

Three examples

ClickUp, Senior Backend Engineer, Cloud Platform. The location type is Remote, with seven countries listed. Italy is absent. That establishes where the role is advertised; it does not establish eligibility from an unlisted country. Employer source.

Stream, Staff Software Engineer, Backend. The location type is Hybrid. The locations and description also include a conditional remote option from the EU. A filter that kept only postings labelled Remote could lose this option. Employer source.

Alpaca, Senior Full-Stack Engineer, Internal Tools. The company describes a globally distributed team. This particular vacancy is advertised for North and South America. Company-level information and job-level restrictions need to remain separate. Employer source.

Store the questions separately

Here is an illustrative TypeScript model. It describes facts extracted from a posting. It is a design example, not a claim that it has been implemented in a product.

type HiringScope =
  | { kind: "countries"; codes: string[] }
  | { kind: "region"; label: string }
  | { kind: "unknown" };

type LocationFacts = {
  advertisedMode: "remote" | "hybrid" | "onsite" | "unknown";
  remoteOption: "explicit" | "conditional" | "unknown";
  hiringScope: HiringScope;
  conditions: string[];
  evidence: {
    url: string;
    checkedAt: string;
    notes: string[];
  };
};

The distinction matters in the Stream example. You can retain the advertised Hybrid label and record the conditional EU remote option alongside it. A single boolean makes that awkward: either value loses part of what the employer wrote.

The region label should also retain the employer’s wording. EU and Europe are different scopes. Converting both to the same set of countries silently adds an assumption.

Unknown needs a real representation

An empty country list can mean several things: no restriction was stated, extraction failed, or the employer described a region instead. If the application treats all three as worldwide, missing information becomes a promise to the reader.

The model above keeps an explicit unknown state. A production parser would also need to distinguish missing information from extraction failure and retain conflicting evidence. Those cases deserve different handling, even if the UI initially shows both as “check with employer”.

Country names in a location field should not automatically become a verified list of countries where the company can employ someone. That is another claim, and it needs its own evidence.

What I would show the reader

A useful location summary could say:

  • Advertised arrangement: Hybrid.
  • Remote option: The employer will consider the right person working from the EU.
  • Still to confirm: The arrangement for hiring someone in your country.
  • Source checked: 23 October 2026, with a link to the employer’s page.

That gives the reader something concrete to verify before investing time in an application. Working-hour requirements, office attendance and work permission still need their own checks.

Three postings are enough to expose a modelling problem. They do not tell us how common it is across the market. And a posting remaining online does not, by itself, prove that its conditions are unchanged.

AI assistance was used for research and drafting. The three employer examples were checked against their original hiring pages on 23 October 2026.

來源:DEV Community · dev.to