Remote job location rules: a TypeScript model for vacancy cards

Imagine two fictional vacancy cards. Both say “remote” and name the same city. One explicitly accepts applicants living elsewhere; the other says nothing about where an applicant may reside. A UI that turns both cards into “work from anywhere” has added information that was never supplied.

This is a small domain-model problem with a visible career consequence. Work mode describes an arrangement. A city label describes a location. Eligibility to work from a particular country is another question. Treating them as one field makes the interface look simpler while making its meaning less precise.

Start with what a card actually exposes

A public Data/AI Engineer card on HireSeeker displays Kazakhstan, Astana and office work beside the role. These are distinct labels in an expanded vacancy view. Keeping these labels visible gives the reader several useful pieces of context before opening the original announcement.

The example is useful to data engineers and backend developers for the same reason a typed API response is useful: separate fields let the reader ask separate questions. There is no need to derive a fictional remote condition from a real office-work label, or to make a city stand in for the employer's hiring policy.

Give an unanswered question its own state

Here is an illustrative TypeScript model for keeping these concepts separate in a vacancy interface:

type Stated<T> =
  | { kind: "stated"; value: T }
  | { kind: "not-stated" };

type WorkMode = "office" | "hybrid" | "remote";

type VacancyPlace = {
  country: Stated<string>;
  city: Stated<string>;
  workMode: Stated<WorkMode>;
  applicantResidenceRule: Stated<string>;
};

function residenceText(place: VacancyPlace): string {
  const rule = place.applicantResidenceRule;
  return rule.kind === "stated"
    ? rule.value
    : "Applicant residence conditions are not stated";
}

The important choice is not the particular property names. It is that not-stated is representable without becoming an empty string, a universal permission, or a negative answer. The renderer can display what it knows and leave an unanswered question visible.

The model deliberately does not produce an “eligible” Boolean. A vacancy interface cannot determine a specific person's eligibility from these labels alone. Nor does this example attempt to parse a legal rule or decide whether a restriction applies to an individual.

Rendering without inventing a relationship

For a fictional remote card, workMode may be stated while applicantResidenceRule remains not-stated. The UI can render those two facts together: remote work is indicated; residence conditions are unspecified. Neither fact cancels the other.

For a fictional hybrid card, a city may help describe the office location. It still does not specify the frequency of visits unless that condition is also supplied. A model that preserves independent fields lets later detail add meaning without rewriting what the original label said.

HireSeeker's public vacancy view provides a concrete place to observe location and work-mode presentation in an IT job product. The small model above asks a narrower engineering question than whether a role is attractive: can the interface distinguish a stated condition from a conclusion supplied by the interface itself?

“Remote” is useful information. “Applicants may live anywhere” is different information. An unanswered residence question should remain unanswered until there is something that actually answers it.