The Remote-Only Search Test, One Role's 100 Postings to a Dated Filter Rule

This guide is for job seekers deciding whether to hold out for fully remote work or widen the search to hybrid roles within a commute they can live with. It follows one case, a mid-level Data Analyst in Ohio, from a raw postings pull to a dated filter rule, including the wrong turns that made the remote pool look bigger than it was. Run the same steps on your own role and you end with 100 coded postings, a competition adjustment, and a weekly count you can plan around.

Is a remote-only search viable for your role?

On volume alone, usually not. Published postings data puts fully remote at 2% to 4% of US postings depending on seniority, so a 100-posting sample for a mid-level role holds about 3 remote openings before you remove the ones your state cannot take. Whether it works for you depends on three numbers you can only get locally: remote postings you can actually take, hybrid postings inside your commute band, and how much harder each remote posting is to win.

Start with the benchmark. Robert Half's postings analysis splits work mode by seniority, and it is the cleanest public split because it counts fully remote separately from hybrid.

The onsite column is 100 minus the other two. Seniority doubles your access to remote postings, from 2% to 4%. It does not necessarily improve your odds of landing one, because no public source splits applicant competition by seniority.

These shares move. In the same series, fully onsite postings rose from 64% to 85% across five quarters. Treat the table as a starting point that you replace with your own counts.

The worked case

The case I carry through this guide:

• Role: Data Analyst, mid-level.
• State: Ohio, living near Columbus.
• Window: 4 weeks of postings, inside the 14 to 30 day range the procedure allows.
• Question: remote-only, remote plus hybrid within some number of minutes, or open?

I picked this role on purpose. Data and analytics is where the remote headlines look strongest, so if remote-only fails here, it is a hard sell for most roles. "Viable" means the filter produces enough postings per week to keep up your application pace. Only you can set that number, from your own tracker.

One definition before going further. A first-round count here means the number of postings per week that pass your filter and go into your application queue. Turning that into interviews depends on your own conversion rate, which no public source can give you.

Which remote share should you start from?

Use a share that counts fully remote postings separately from hybrid, takes all postings as the denominator, and matches your seniority. Then replace it with your own sample count as soon as you have one. Each tracker counts something different, and the wrong one can make the remote market look several times bigger than it is.

Wrong turn 1: reading Indeed's figure as remote

My first projection was 8 remote postings in 100, taken from Indeed's 8.4%. That figure is a keyword match on the posting text, and it counts remote and hybrid together. Set it beside Robert Half's 4% and you have counted hybrid twice. The two numbers measure different things, so they do not contradict each other.

Wrong turn 2: the data and analytics headline

PredictLeads reports Data & Analytics at 41.7% remote, which would mean about 42 remote postings in my 100. The problem is the denominator. That figure covers tech postings only, and only those that state a work mode at all. Across all 677,699 technical postings in the same dataset, remote falls from 40.2% to 21.6%. Many postings state no mode, and dropping them roughly doubles the apparent remote market.

The same dataset shows where remote clusters by employer size: 52.6% remote at firms with 11 to 50 employees, against 26.3% at firms with 10,001 or more. That matters in the eligibility step, because small firms are the ones most likely to cap which states they hire in.

Wrong turn 3: sizing remote from people instead of postings

Next I tried to size remote competition from the supply of workers. Refolk's index of professional profiles gives this pair for the title:

It is tempting to read this as "few people want remote, so competition is low." That reading is wrong. A headline keyword counts self-labels, not remote employment or remote applicants. The title match is also loose: in a 25-profile sample, 14 held the exact current title "Data Analyst", and in the remote subset 16 of 25 did.

Then the seniority filter failed. "Entry Level" returned the same 64,988 as the unfiltered query, and "Senior" returned 0. I threw out both figures. Keep the index pair for one thing only: the title pool you compete in is large. It tells you nothing about how many remote openings exist. For that you need postings.

The 100-posting procedure

The test is seven steps, run in order: pull, deduplicate, code, remove ineligible remote, band hybrid, adjust for competition, write the rule. Deduplicate before coding so you never code the same posting twice. Code the work mode before checking eligibility, because eligibility only matters for remote rows, so you check fewer rows.

Time estimates, which no source documents and I have not verified: 1 to 2 hours for the pull, about 30 minutes for deduplication, and 1 to 2 minutes per posting for coding.

On reposts: no public source gives a typical repost rate, so I cannot tell you how many of your 130 raw rows will drop out. Log your own removal count. Reposts inflate whichever pool they fall in, and a remote role reposted to several boards makes the remote pool look busier than it is.

In the worked case, the mid-level benchmark predicts 3 remote, 10 hybrid, and 87 onsite postings in 100. Every count in the rest of this guide starts from those three numbers. When you run it, use your own.

Which remote postings can you actually take?

A remote label describes attendance, not who can be hired. Takeable remote is what remains after you strip out postings with attendance language in the body, country limits, state lists your state is not on, licensure gates you cannot meet, and travel terms you will not accept. For many seekers that removes a fifth or more of the remote pool.

The only dated public snapshot of remote eligibility scope is WorkinVirtual's, from 112 listings:

A sample of 112 is small, so use it to understand the mechanism, not as a rate for your role. The documented reasons employers restrict remote jobs to certain states:

• Payroll nexus. One full-time remote employee is generally enough to create nexus, a tax connection to the state that triggers employer registration and withholding. Each new state adds payroll overhead, so smaller employers keep their lists short.
• Pay-transparency exposure. An employer based in a state without pay-transparency rules may avoid listing jobs in a state that has them.
• Licensure. Postings can be limited to states where the candidate holds a licence, or where the employer participates in the Nurse Licensure Compact.

ADP lists restricting remote work to select states as an ordinary management tactic, so expect it. Watch the location line too. "Remote" next to a city name can mean in-state only. Search the body for "must reside".

A remote label describes attendance. It does not tell you whether your state can be hired.

The worked case through eligibility

Three remote postings come out of the coding step. The worst case for an Ohio seeker treats every selected-state list as excluding Ohio, which removes 21.4%: 3 × 0.786 ≈ 2.4 takeable. The best case is all 3. I flag "remote with travel" rows separately rather than dropping them, because the travel terms decide those.

One gap I cannot close for you: how often a "remote" label is contradicted by attendance language in the description. No public rate exists, only cases. One documented case is Inno Supps, which labeled a copywriter role remote "for visibility" while the role required office presence. Your coding step catches these. Count them, and you will have your own rate for your role.

How far should you commute for a hybrid job?

Set the radius in peak-hour minutes, not miles, and scale it by office days per week. A 45-minute one-way commute three days a week costs about 270 minutes a week, roughly the same as a five-day commute at the national mean of 27.4 minutes (274 minutes). That parity point is a sound default ceiling for a hybrid band.

The banding anchors come from the Census Bureau's American Community Survey (ACS) table S0801, which measures one-way travel time to work:

The five bands, and what each one means:

• 0 to 19 minutes: at or under the most common commute. Take any office-day count.
• 20 to 29 minutes: around the national mean. Fine up to four or five days.
• 30 to 44 minutes: above the mean, near New York's state average. Best at three days or fewer.
• 45 to 59 minutes: works at two or three days.
• 60 or more minutes: the commute only 9.5% of workers have. Two days at most, and only for a role you badly want.

Office days change the limit more than distance does. Dividing 274 weekly minutes by round trips gives the one-way limit at parity:

This parity rule is my opinion, not a published standard. If you commute well now, use your current weekly minutes as the ceiling instead.

In the worked case, the benchmark gives 10 hybrid postings. I cannot tell you how they spread across bands around Columbus, because that depends on where the offices are and where you live. That is exactly what the maps step produces. Code each hybrid row with both its band and its days per week, because a 50-minute office at two days passes the parity test and the same office at four days fails it.

Are remote jobs harder to get?

Yes. On LinkedIn's published shares of US paid postings and applications, a remote posting drew roughly 4 to 8 times the applications of a non-remote posting, and the gap widened as remote postings got scarcer. The competition adjustment divides your takeable remote count by that multiple, so you can compare a remote posting with a hybrid or onsite one on equal terms.

LinkedIn does not publish applicants per posting. It publishes the remote share of postings and the remote share of applications. Divide one by the other and you get a per-posting index for each group:

How the multiple is built: the remote index is the share of applications divided by the share of postings (35 ÷ 8 = 4.38 for the latest row). The non-remote index does the same for everything else (65 ÷ 92 = 0.71). Divide the first by the second and you get 6.2x. The Jan 2024 row comes through a secondary source, so give it less weight. LinkedIn's own directly stated figure from early in the series was lower, at 2.7x the applications of onsite jobs. It was built differently, comparing remote with onsite only rather than with everything non-remote.

The mechanism is the useful part. Remote postings dropped faster than the number of people applying to them, so each remote posting carries more applicants than it did. Expect the multiple to stay high wherever remote postings are scarce.

The worked case through the adjustment

• Default multiple, 6.2x: 2.4 to 3 takeable remote postings ÷ 6.2 ≈ 0.4 to 0.5 onsite-equivalent postings in four weeks.
• Most generous multiple, 2.7x: 2.4 to 3 ÷ 2.7 ≈ 0.9 to 1.1.
• Harshest multiple, 7.7x: about 0.3 to 0.4.

Under any of the three multiples, four weeks of remote-only searching is worth about one onsite-equivalent posting or less. Hybrid rows keep a weight of 1.0, because LinkedIn's non-remote group includes hybrid, so the data cannot separate them.

With that much competition, choose remote postings carefully rather than applying to all of them. Refolk scores how well you fit each posting, so you can see which of your two or three remote rows are worth tailoring for before you spend the time.

Where does the remote-only test go wrong?

Most errors make the remote pool look bigger or the hybrid pool look smaller than it really is, and both push you toward a remote-only search that will not produce enough postings. Each failure mode below gives what it looks like, why it misleads, and the check.

1. Mismatched denominators. Indeed's 8.4% beside Robert Half's 4% looks like two estimates of the same thing. It is not: one combines remote and hybrid by keyword, the other counts fully remote only. Check: confirm both figures count the same mode over the same denominator.
2. Labeled-only denominators. A remote share computed only over postings that state a mode roughly doubles the market (21.6% becomes 40.2% in tech). Check: ask whether postings with no stated mode were dropped.
3. Trusting the board tag. False positive: "remote" in the location field, while the body says to report to the office 2 to 3 days a week. The Inno Supps copywriter posting is a documented case. Check: search the text for "days" and "week".
4. The location line as a hidden state list. "Remote" next to a city can mean in-state only. A selected-state list covered 21.4% of listings in the WorkinVirtual snapshot. Check: search the body for "must reside" and for state names.
5. Repost inflation. The same remote role on three boards counts three times. No public repost rate exists. Check: deduplicate on employer, normalised title, and location, and log what you removed.
6. Miles instead of minutes. A 14.4-mile radius is a national average, and state mean times differ by 15.7 minutes between New York and North Dakota. Check: band at peak-hour time from your own address.
7. Reading the multiple as a fact about one posting. LinkedIn's shares mix all role families, and no public multiple exists by role, seniority, or eligibility scope. A state-restricted remote posting probably draws fewer applicants than a worldwide one, but that is not established. Check: run the 2.7x to 7.7x range and see whether your rule changes.
8. Raw pay gaps. Remote tech postings advertise 13% less than onsite ones, which looks like a reason to skip remote. Within the same company and level the gap is 0.3%, ranging from a 2.6% discount to a 2.0% premium. Worker-level data from the San Francisco Fed points the other way, with a remote premium of 12% that falls to 6.6% under added controls. Check: compare pay only within the same employer and level.
9. Headline keywords as a proxy for remote workers. The 113 "remote" profiles in Refolk's index count self-labels, and the title match is loose (14 of 25 exact). Check: use people counts for pool size only, and postings for openings.
10. Broken filters returning plausible numbers. The index's seniority filter returned the full 64,988 for "Entry Level" and 0 for "Senior". Both look like answers. Check: if a filtered count equals the unfiltered count, or falls to zero, the filter failed.

The state also matters before you start. JobLeads puts the remote share of new postings at 10% in Oregon and 2% in South Carolina, roughly fivefold. If your state is at the low end, adding a hybrid band will raise your count far more than waiting for remote postings will.

Writing the filter rule and keeping it current

Pick the narrowest rule whose weekly count keeps up with your application pace, write it down with its inputs and the date, and re-run the sample when your state, seniority, or pace changes. The rule is a decision about the market as it stands, and the market shifts every quarter.

Here are the three candidate rules for the worked case, on a four-week window. Hybrid and onsite counts assume every row falls inside your band, so they are upper bounds. Banding cuts them.

For this case, remote-only gives about one-tenth of an onsite-equivalent posting a week, which cannot sustain a search. Remote plus hybrid within the parity band is the rule I would write. You would go fully open only if your banded hybrid count still falls short of your pace. Onsite rows then need their own five-day commute check, against the 20 to 29 minute band.

Widening from remote-only to remote plus hybrid raised the worked case from under one raw posting a week to about three, and an open search adds far more. More postings means more tailoring. Refolk drafts a tailored resume and cover letter for each posting from your own history, so a wider filter does not multiply your writing time.

Use this log and rule sheet as-is. The header row goes at the top of your spreadsheet. The rule block goes wherever you keep search decisions.

posting_id,employer,title_normalised,location_line,first_seen,repost_of,mode_from_text,office_days_per_week,eligibility_scope,my_state_ok,peak_minutes_one_way,commute_band,weight,notes

FILTER RULE - dated: YYYY-MM-DD
Role and level:
Home state and address used for timing:
Window: __ days | Raw rows: __ | Reposts removed: __ | Unique: 100
Remote coded from text: __ | Takeable: __ | Excluded (state/country/licence/travel): __
Hybrid by band: 0-19: __ | 20-29: __ | 30-44: __ | 45-59: __ | 60+: __
Onsite: __
Competition multiple used: __x (range tested: 2.7x to 7.7x)
Rule: [remote-only | remote plus hybrid within __ minutes at peak, max __ office days | open]
Expected weekly count: __ raw | __ onsite-equivalent
Application pace this must sustain: __ per week
Re-check on: YYYY-MM-DD

To keep the rule current, re-check the inputs that move:

• Remote shares: Robert Half publishes its split quarterly. Indeed's Hiring Lab remote-tracker data is public under a CC BY 4.0 licence in its GitHub repository, so you can pull the series yourself.
• The competition multiple: recompute it whenever LinkedIn publishes a new pair of postings and applications shares, using the same division as above.
• Your own sample: re-pull 100 postings when you change level, state, or target title, or when your weekly first-round count drifts from the rule's estimate.