Job search
How to Build a Target-Company List for a Focused Job Search
A target list is a maintained portfolio of fit hypotheses with removal rules.

Build a target-company list around a specific kind of work, then maintain it with evidence, a next action and a removal rule. Start with a few employers you can explain. Separate companies with a suitable current opening from companies worth watching. A short list with reasons you can verify and update gives you a clearer next task than recognition alone.
Use recent roles on LandOffer.ai to discover employers alongside direct career pages. LandOffer publishes this guide. Public source examples were checked October 8, 2026. Tessa Grant and the five companies in her completed list are fictional; the dates, decisions and changes below are teaching inputs, not reports about actual employers.
Define what earns a company a place
Tessa wants backend work on storage and data access, prefers remote US employment, and can demonstrate service implementation and database migration work. She wants a team with shared design review. She does not want a role whose primary duty is sales demonstrations or hardware firmware.
That brief gives her an admission rule: a company enters the list when a public source suggests a plausible team or role matching the desired work and no known hard condition rules it out. A recognizable product or a friend's enthusiasm can trigger research, but neither is enough to make the company an active target.
Choose a practical capacity. Tessa starts with five companies because she can revisit all five without displacing application preparation. Five is an illustrative choice, not an optimum supported by a study. Your capacity depends on the depth of research, the number of distinct role families and the time available to maintain the list.
Keep role constraints visible outside the company description, so a broad company policy does not hide a restriction on the opening you are considering. An employer may have offices worldwide while one team hires only in a particular region. A company's remote policy can provide context without answering whether the current opening supports your location. Apply hard conditions at the role level before spending a tailoring session.
Give each entry a testable reason
“Great culture” is a weak reason when it has no source or definition. “The engineering page describes design reviews, and the current role includes storage APIs” is a hypothesis you can inspect. It identifies the type of evidence you have and the remaining questions.
Public employer pages vary in detail. Supabase's careers page displayed specific engineering functions when checked. Linear's careers page combined working principles with role variants. YC's Ashby list showed regional variants. These examples support keeping both a company source and a role source; they do not certify culture or fit.
Write the reason in your own terms. “Storage role with an existing service team” helps Tessa compare an employer against her brief. Copying the company's mission statement into the reason field gives her little help deciding which work to prepare for next.
Record what would change your mind. A location conflict, a required operating responsibility you cannot support, a role closure or a clearer description of unrelated work can move an entry out. Your list needs a way to shrink when evidence no longer supports an entry. Otherwise it becomes a collection of previous browsing sessions rather than a tool for a current decision.
Use three states with different actions
Active means a current opening appears suitable enough for a concrete preparation action. It does not mean the application is submitted or that the employer has assessed you. Tessa links the opening, chooses relevant evidence and schedules the next work session.
Watch means the company's work remains relevant but a suitable opening is absent, incomplete or unresolved. The entry needs a reason and a review date. “Watch indefinitely” provides no stopping point and can consume attention every day without producing useful information.
Archive means current evidence does not justify further work in this search. Keep a short reason so you do not repeatedly rediscover and reconsider the same mismatch. Archiving is a search decision, not a claim that the company is undesirable for every candidate.
An unresolved condition can justify a watch state with a specific question. If a role's location is unclear, name that uncertainty. If a company has no suitable function, do not mark every field unknown and treat it as equally promising as an active opening. State changes should reflect the actual blocker.
Inspect Tessa's completed first list
The following companies, sources and changes are fictional. “Career page” refers to an invented employer's page; the list does not provide fabricated links to real job postings. A CSV and JSON version are retained with this local article package for inspection and reuse.
| Company | Why it fits or entered research | Current role evidence | State and next action | Review date |
|---|---|---|---|---|
| Hazel Storage | Storage service work resembles Tessa's migration experience | Backend engineer; Remote US; shared design review described | Active: select migration and API evidence | October 12, 2026 |
| Mariner Data | Data access product and relevant engineering team | No suitable opening on the fictional career page | Watch: inspect the direct role list once | October 22, 2026 |
| Cobalt Mesh | Interesting networking product | Current opening requires primary kernel work | Archive: function differs from current brief | No routine review |
| Pine Ledger | Backend product features and database work | Location unclear between two fictional official descriptions | Watch: resolve US remote condition | October 15, 2026 |
| Ember Archive | Storage tooling and application services | Suitable role, but current opening is office-only outside Tessa's range | Archive: known location conflict | Reopen only if condition changes |
This list produces one active preparation task, two bounded watch tasks and two exclusions. It does not invent application counts or recruiter interest. Tessa can see where to spend her next session and why the other companies should not consume the same amount of work.
Notice that Mariner and Pine share a state but need different actions. Mariner needs a future opening; Pine needs a current location answer. A single “follow up” label would hide that distinction. A next action should say what information or completed work changes the state.

Store sources and dates without building a second tracker
The company list tracks your interest hypothesis and research decision. Your application tracker tracks a particular application and its actual state. Link the two when needed, but do not copy every application field into each company row. Multiple applications at one employer make that duplication especially confusing.
For a company entry, keep its name, desired team or function, fit reason, source, last checked date, state, next action and review date. For an active opening, add the exact role source and the hard conditions that affected the decision. Keep application submissions and receipts in the application record.
Use the last checked date for what you actually inspected. Viewing a homepage should not refresh the date for a detailed job description you did not reopen. Similarly, changing your preference is a new decision, not a new observation of the employer. Separate those events in a short note.
A source can become unavailable. Preserve the former observation as dated context, then mark current availability unknown. Do not silently retain “opening active” because a saved copy still exists. The list should show whether the next step is preparing an application or returning to a current official source.
Review a second cycle and change the list
In the fictional October 15 review, Hazel's role remains suitable and Tessa has finished selecting her migration and API evidence. She keeps Hazel active and changes the next action to reviewing the actual application requirements. Evidence selection is complete; submission is still a separate future event.
Pine's fictional employer route clarifies that the opening is office-based outside her range. Tessa moves Pine from Watch to Archive and records the location conflict. This prevents another week of resume preparation for a role she would decline on a hard condition.
Mariner's fictional direct page now lists a backend data-access opening marked Remote US. Tessa reads its duties and finds application-service work with shared review. She promotes it to Active, records the new source observation and chooses a service contribution for preparation. She does not assume it fits merely because the company was already on Watch.
The revised list has two active entries and three archives. There is no need to replace every archived employer immediately. Tessa's next two sessions already have named work: Hazel's requirements review and Mariner's service-evidence selection. The list is valuable because it directs action, not because it maintains a fixed impressive size.
Decide when to stop watching
Give each watch entry a reconsideration condition. “Review when an application-service role appears” is useful. “Check all jobs daily” is usually broader than the reason the company earned a place. Use the company's relevant official route where available, and avoid treating every announcement as a new hiring signal.
You can archive a watch entry after repeated reviews reveal no relevant function, after your constraints change, or when the source no longer supports the original reason. That is a maintenance judgment, not a prediction that the employer will never hire. Preserve a trigger for reopening only if it helps your current search.
Tessa would reopen Ember if a suitable role becomes remote in her supported region. She would reopen Cobalt only if the company lists application-service work or her own desired function changes. The distinction matters: one is a location change, the other a change in the work itself.
Do not interpret silence as a personal rejection when you have not applied. A company without a suitable listing has supplied no decision about your candidacy. Tessa's archives record her selection decisions, not employer responses. Keep research outcomes distinct from employer responses so your list remains a factual decision aid.
Use the list to prepare a better conversation
A company note should help you ask a specific question if you reach a conversation. Tessa can ask Hazel how design review works for service changes or ask Mariner which data-access component the opening will own. Those questions follow from the sources and her work interests.
Avoid repeating company slogans as evidence of preparation. Describe what you understood, identify what is unresolved and explain why that uncertainty matters to the role. A narrow question often produces more usable information than asking whether the culture is good.
Keep interest separate from advocacy. You can admire a company's product while deciding its current role does not fit. You can also investigate an unfamiliar employer when the described work is relevant. The target list should support both decisions without forcing a prestige ranking.
Finish with a list you can act on
Tessa now has a concrete queue: Hazel's requirements review and Mariner's evidence selection. Pine's location question is resolved through exclusion. Cobalt and Ember have explicit reopening conditions. Every entry either earns a current task or stops consuming routine attention.
For your own list, begin with a small set of employers and complete the reason, source, state and next action for each. Remove any company whose only reason is recognition. If a material condition is unknown, name the question and set a review date. Then choose the active entry whose next step you can actually complete.
Find one plausible employer through LandOffer's recent roles, inspect its direct career route and add it only with a specific work reason. At your next review, be willing to promote, hold or remove it. Adding a company starts research; save an actual submission state only after completing a separate employer application. At the next review, you can reopen the reasons and decisions without trying to remember why a familiar logo entered your list.
Sources and Further Reading
- Supabase careers: public engineering functions and location labels, checked October 8, 2026.
- Linear careers: public role variants and working principles, not independent culture verification.
- YC's Ashby openings: regional listings illustrating why company and role sources should be stored separately.