Forem: remoet.dev

Tech Job Market Report: May 2026

Carl-W — Fri, 01 May 2026 18:33:22 +0000

The remote-first job market is a smaller pond than the discourse suggests.

12,798 active tech jobs across the 1,056 companies we track on remoet.dev. 1,788 of them are fully remote. That is 14%. The other 86% want you in a chair somewhere, full or part time. The May numbers are below.

Where the work actually is

Location policy	Jobs	Share
Fully remote	1,788	14%
Remote, region-restricted	2,611	20%
Hybrid	2,079	16%
Onsite	1,493	12%
Unspecified	4,827	38%

The "unspecified" bucket is the one to be honest about. Most career-page scrapers don't normalize location policy, and in practice those jobs tend onsite or region-restricted. Read the listing before you celebrate.

Hiring is concentrated

The top 15 companies have 3,143 open roles between them. Almost a quarter of the entire pool.

Databricks, 407
Speechify, 381
OpenAI, 256
Airwallex, 222
Canonical, 216
Snowflake, 203
Anthropic, 175
Roblox, 171
Relativity, 166
Zscaler, 162
MongoDB, 161
Cloudflare, 156
Sezzle, 147
Stripe, 142
Nebius, 136

If you have not starred the 30 to 50 companies that match your stack, you are missing where the jobs actually are. Job-board search is keyword soup. The leverage is in narrowing to the cluster, then watching that cluster.

What pays

Salary bands by tech, from 3,338 postings with disclosed USD comp. The data skews toward US states with pay-transparency laws (CA, CO, NY, WA), so absolute levels run high. Filtered to techs with at least 50 postings.

Tech	Avg low	Avg high	Postings
PyTorch	$237k	$381k	75
LLM	$214k	$296k	150
Rust	$210k	$285k	109
Spark	$187k	$267k	164
GCP	$187k	$251k	321
Azure	$185k	$250k	227
Snowflake	$181k	$242k	73
Python	$181k	$252k	748
Kubernetes	$176k	$249k	385
Go	$176k	$236k	234
Scala	$175k	$248k	94

The rank is more useful than the absolute numbers. PyTorch leads. AI ecosystem stuff (LLM, AI, Spark) clusters in the $180k to $290k band. Python on its own pays the same as Go. The premium is in what you stack on top of Python, not Python itself. If you are getting offers in the $130k to $160k range and the table above looks alien, the gap is geographic and disclosure-driven, not skill-driven.

The junior squeeze

328 active postings tag themselves as junior-level. About 2.6% of everything open. The split:

Senior: 5,707
Mid: 1,936
Junior: 328

Senior outnumbers junior seventeen to one. If you are in your first three years, the market is genuinely tight for you. The play is not to apply harder. The play is to treat the junior subset as your working set, sort by company-stack match, and apply where you have a credible argument.

Why this report is shorter than last month

We expanded coverage substantially through April. Month-over-month job totals look inflated until the new sources stabilize. Treat absolute numbers as current snapshots, not as growth signals, until the next report.

If you want to slice this data yourself by stack, location, or experience level, connect an AI agent to Remoet via MCP and ask it directly. It is faster than any filter UI and a lot more honest than keyword search.

Full report on the Remoet blog.

300+ Remote Companies Using Python in 2026

Carl-W — Thu, 30 Apr 2026 07:40:06 +0000

Python is the #1 most used language on remote engineering teams. 316 companies. 2,569 open jobs. More open slots than any other language, by a wide margin. You write Python. You cannot get an interview. Let me tell you why.

The breadth that makes Python the most-hired language is the same thing keeping you invisible. "Python developer" is the most common label in the industry. Putting it on your resume puts you in the same bucket as every CS grad who finished an Udemy course last Tuesday. The recruiter has 800 of you and 6 minutes. They are not reading.

This post is not a list of remote Python companies. It is an argument about why the list does not save you.

Python wins. You lose.

The data is the foundation of the argument, so here it is.

316 companies use Python in their stack
2,569 open jobs across them, more than any other technology
237 of those companies pair Python with AWS
200 pair it with Kubernetes
73 pair it with PyTorch

Compared to the rest of the field:

Language	Companies	Jobs
Python	316	2,569
TypeScript	275	1,408
JavaScript	238	835
Go	169	854
Java	141	698
Rust	80	321
Ruby	55	180

Python has nearly twice the company surface area of Go and three times the jobs. On paper, you should be drowning in interviews. Most of you are not.

This is the trap. The reason your inbox is empty is not that there are no jobs. There are more jobs for you than for any other developer in the world. The reason your inbox is empty is that 316 companies and several million Python devs makes the label "Python developer" carry zero information. You are a needle in a needle stack. Recruiters cannot find you because there is nothing to find.

The thing that gets you hired is the cluster

Stop thinking of yourself as a Python developer. You are not.

You are a Python plus FastAPI plus PostgreSQL plus AWS person. Or you are a Python plus PyTorch plus C++ person. Or you are a Python plus Django plus MySQL plus six years of legacy Rails person. These are different humans. The company hiring one will reject the other on sight, sometimes in the same hour, and that rejection has nothing to do with how good you are.

The 316 number is misleading. The number that matters is how many companies want your cluster. For most Python devs that number is under 30. Often under 10. That is the real pool you are competing in, and inside that pool you are not interchangeable. You are a credible candidate.

Let me show you what the clusters actually look like.

FastAPI + PostgreSQL: the modern backend

If you have shipped a Python service in the last three years, you probably built it on FastAPI, and it probably talked to Postgres. Flask still exists. Django still exists. Almost nobody is starting greenfield work on either.

Companies that hire this cluster: Distribusion (travel tech), Prolific (research platform), Recharge (subscription commerce), Close (CRM). All of them want to see FastAPI on your GitHub. Not "Python." FastAPI specifically. The label gap matters.

AWS + Kubernetes: where Python becomes infrastructure

237 companies run Python on AWS. 200 on Kubernetes. The overlap is the spine of remote backend work in 2026. If you have spent the last two years writing Terraform and arguing about pod autoscaling, this is the cluster paying you.

The names: PostHog, Canonical, Chainlink Labs, Instructure, Cursor. Python here is a glue language. You are getting hired because of what you can do with it across a Kubernetes cluster, not because you can write a list comprehension.

PyTorch: the cheat code

73 companies. Less than a quarter of the Python pool. This is the cluster you should care about most.

53% of tech postings now require AI or ML skills, and the AI ecosystem speaks Python. PyTorch, TensorFlow, scikit-learn, LangChain, Transformers. Every framework. Every paper. Every weights file. Python.

If you are a Python developer who cannot get an interview, the highest-leverage thing you can do this month is spend a weekend on PyTorch and put a real project on your profile. The frameworks are learnable. The language is already yours. You move from the 316-company pool to the 73-company pool, which is where companies pay top of market and recruiters chase you instead of the other way around.

The 73 include Nebius (AI infrastructure, Yandex spinoff), Scale AI (data labeling), AssemblyAI (speech), HeyGen (AI video), and dozens more. None of them want a "Python developer." They want a PyTorch person.

Python backend + React frontend

Python on the server, React on the client. The boring, profitable middle of the market. PostHog, Khan Academy, Linear, Buffer, Oyster, Spring Health. If your stack is a Python API serving a TypeScript SPA, this is your home and there are dozens of seats open.

Data engineering

Airflow, Spark, dbt, Postgres, Snowflake. The data world does not move fast, and the companies that are good at it stay good at it. Bloomreach, Oddball, Cloudbeds. This is a small-cluster game where most of the hiring happens through people who have shipped pipelines that did not page anyone at 3am.

Python hiding inside non-Python shops

Some of the best Python jobs are at companies you do not think of as Python shops. Vercel, 1Password, DuckDuckGo, Grafana Labs. They have Python somewhere in the stack and they hire Python people for it. You will not find these by searching "remote python jobs." You find them by reading full tech stacks and noticing.

Why none of this works without matching

You have read this far. You agree the cluster matters. Now what.

The honest answer is that "match yourself to the right cluster" is not a thing job boards can do. They search by job title. Title-based search is the reason you keep getting CRUD listings when you want infra work. The fix is not better keyword matching. The fix is matching on the actual graph, your stack against the company's stack.

This is what AI agents are good at. Connect an agent to Remoet, give it your stack, ask it to find the cluster. Not "Python jobs." Something like "companies running Python with PyTorch and Kubernetes that are hiring senior backend engineers." The agent reads the data, finds the slice, and you stop competing with the 316. You compete inside your cluster, where you are actually visible.

Star the ones that fit. Ten to fifteen is plenty. Let the digest bring you new roles every week without you having to look. That is the workflow. That is all of it.

One last thing

Python being the most-hired language is not what should make you optimistic. The breadth is what is hurting you. Optimism comes from the cluster. Find the 30 companies whose stack matches yours, get visible to those 30, ignore the other 286.

You have more options than you think. You also have less competition than you think, once you are honest about what you actually do for a living.

Stop applying like a Python developer. Start applying like the specific Python developer you are.

Ghost Jobs: 30% of What You're Applying to Doesn't Exist

Carl-W — Mon, 13 Apr 2026 21:24:16 +0000

You applied to 100 jobs last month. About 30 of them didn't exist.

Not "the role was filled." Not "they went with an internal candidate." The job was never real. Nobody was ever going to get hired. The posting was there to serve a purpose that had nothing to do with you.

The numbers are worse than you think

27.4% of U.S. LinkedIn listings are ghost jobs. A Resume Builder survey found 3 in 10 companies have fake job postings live right now. Not by accident. On purpose.

81% of recruiters admit their employer posts roles that don't exist or are already filled. In tech, 40% of companies posted fake jobs in the past year. 79% of those are still up.

Los Angeles has a 30.5% ghost job rate. But it's not a local thing. It's everywhere.

Why companies do this

The reasons are almost never about hiring. That's the part that should piss you off.

Companies post jobs to look like they're growing. If you're raising a Series B and your careers page shows 40 open roles, investors see scale. Whether those roles are real doesn't matter. The perception is the product.

Some companies post jobs to do free market research. They want to see who applies, what salary expectations look like, how deep the talent pool goes in a given city. You spend 45 minutes on your application. They get a data point. Nobody was ever going to call you.

Others use ghost postings as a retention tool. "Look at all these open roles. We could replace you tomorrow." It's a threat dressed up as a careers page.

And then there's plain negligence. A role gets filled internally. Nobody turns off the auto-renew in the ATS. The posting sits there for 6 months collecting applications from people who think it's real. This is probably the most common one, and somehow it's also the most insulting. They couldn't even be bothered to click "close."

15 hours you're not getting back

Each application takes about 30 minutes when you actually do it right. Reading the description, adjusting your resume, writing responses, submitting. Apply to 100 jobs in a month, 30% are ghosts, that's 30 wasted applications. 15 hours. Gone.

But the time isn't the worst part.

You applied. You were qualified. You heard nothing. And you start wondering if you're the problem. Maybe your resume sucks. Maybe you need to learn another framework. Maybe you're too expensive. You internalize the rejection when there was nothing to be rejected from.

The job didn't exist.

72% of job seekers report negative mental health impacts from drawn-out hiring processes. Ghost jobs are a huge part of that. Every fake listing adds another false data point to your "maybe I'm not good enough" story.

How to spot them

None of these are guaranteed. But stacking them together filters out most of the garbage.

Check the posting date. If it's been up for 60+ days, especially at a tech company, something is off. Most real positions fill within 30-45 days. Three months? Either it's a ghost, the role is impossibly niche, or the company can't get their act together. None of those are encouraging.

Read the actual description. Ghost jobs are almost always vague. "Looking for a talented engineer to join our growing team." No tech stack mentioned. No team name. No specific project. Real hiring managers get specific because they need a specific person. Vagueness is a tell.

Look at the company's pulse. Are they active on social media? Have they made recent hires you can see on LinkedIn? Do they have an engineering blog that's been updated this year? A company listing 20 open roles with zero public activity for 4 months is suspicious.

Cross-reference the source. If a job shows up on Indeed, LinkedIn, Glassdoor, and three other boards but isn't on the company's own careers page, it's a stale aggregation. Some distribution service is auto-syndicating a dead listing that nobody bothered to kill.

Job boards won't fix this

Job boards make money from listings. More listings means more page views. More page views means more ad revenue or higher subscription fees. A ghost job and a real job generate the same engagement metrics.

Indeed, LinkedIn, Glassdoor. None of them have an incentive to remove ghost postings. The ghost job is doing exactly what their business model needs. Just not what you need.

The platforms you trust to help you find work are economically rewarded for keeping fake listings live. That's a broken foundation and no amount of UI polish fixes it.

Regulation is coming, slowly

Ontario passed legislation requiring companies to disclose whether a posting is for a real, active vacancy. The U.S. has the TJAAA bill working through Congress with similar requirements.

When lawmakers write bills specifically about fake job postings, the problem has gone past "industry nuisance" into "systemic failure." But regulation is slow. Enforcement is slower. You can't wait for Congress to fix your job search.

Stop searching for jobs. Start tracking companies.

Sounds backwards. But think about it.

The ghost job problem exists because you're interacting with listings, not companies. A listing can be fake. A company can't fake its existence, its tech stack, or whether it's actually made hires recently.

Pick 10-20 companies where your tech stack genuinely overlaps. Track them. Watch for new roles at those specific companies. When one of them posts something, you know it's more likely to be real because you've been watching the company, not a random feed of disconnected listings.

This is what I built Remoet around. 725+ remote tech companies, tracked, with real tech stack data. You star the ones that match your skills, and your AI agent monitors them for you. It doesn't eliminate ghost jobs entirely. Some companies will always play games. But you go from fishing in a pool that's 30% fake to watching a handful of companies you've already vetted.

Apply fewer. Apply better.

The instinct when you learn about ghost jobs is to compensate with volume. "If 30% are fake, I'll just apply to 3x as many." That's the trap. More volume means more time wasted on ghosts, more silence, more false rejections eating at your confidence.

The opposite works. Narrow your target. Verify the company is real and active. Check the posting date. Look at the tech stack. Then apply once, with effort, to something that's actually there.

30% of what you're applying to doesn't exist. The fix isn't applying harder. It's not applying to bullshit.

Frequently Asked Questions

What is a ghost job?

A ghost job is a posting for a position that isn't actually open or that the company never intends to fill. It exists for other reasons: signaling growth to investors, collecting market data, pressuring existing employees, or just negligence where nobody closed the listing after the role was filled internally.

How common are ghost jobs?

Between 27-30% of job listings, depending on the study. Resume Builder found 3 in 10 companies currently have fake postings live. In tech specifically, 40% of companies posted at least one fake job in the past year, and 79% of those are still active.

How do I know if a job posting is fake?

Look for a combination of red flags: the posting has been up for 60+ days, the description is vague with no specific tech stack or team, the same listing appears on aggregator sites but not on the company's own careers page, and the company shows no other signs of active hiring (no recent LinkedIn hires, no social media activity).

Are ghost jobs illegal?

In most places, not yet. Ontario passed legislation requiring disclosure of whether a posting is for an active vacancy. The U.S. has the TJAAA bill in Congress. Regulation is moving, but slowly.

Why don't job boards remove ghost jobs?

Because ghost jobs make them money. A fake listing generates the same page views, ad impressions, and engagement metrics as a real one. The platforms have no economic reason to clean them up.

What Is MCP (Model Context Protocol)? A Practical Guide

Carl-W — Wed, 25 Mar 2026 11:21:58 +0000

MCP (Model Context Protocol) is an open standard that lets AI agents connect to external software, discover available tools, and take actions on your behalf. Instead of being trapped in a chat window, your AI can search databases, manage projects, update profiles, and interact with any service that runs an MCP server.

You've probably seen MCP mentioned everywhere lately. Twitter threads, blog posts, product announcements. Every AI company seems to be shipping an "MCP server" and every developer tool is adding "MCP support." But if you've tried to figure out what MCP actually is, you've probably run into a wall of jargon and protocol specs.

I'm going to cut through that.

MCP in Plain English

Anthropic introduced MCP in November 2024. In December 2025, they donated it to the Agentic AI Foundation under the Linux Foundation, with OpenAI, Block, and others as co-stewards. It's a genuinely open protocol now.

Here's the problem it solves. When you use Claude or ChatGPT, the AI can talk to you, but it can't actually do anything outside that conversation. It can't check your calendar, search a database, file a bug report, or look up your job applications. It's stuck inside a text box.

MCP changes that. It's a universal plug that lets an AI agent reach into other software and take actions on your behalf. Search a job board. Update a project. Star a company. Send a message. Whatever the connected service supports.

Yeah, I know, the USB analogy is the cliche everyone uses for MCP. But it's accurate, so I'll use it anyway: before USB, every device had its own proprietary connector. Printers, keyboards, cameras, all different cables. USB standardized the physical connection. MCP standardizes the AI-to-software connection.

How It Actually Works

Under the hood, MCP uses JSON-RPC 2.0 as its wire protocol. If you've worked with LSP (Language Server Protocol), the architecture will feel familiar. There are two sides to every MCP connection:

The client is your AI agent. Claude Desktop, Cursor, Windsurf, Claude Code, Cline. These are the apps where you type prompts and have conversations. They speak MCP natively.

The server is whatever tool or service you want the agent to access. A GitHub MCP server lets your agent manage repos and issues. A Notion MCP server lets it read and write documents. A Remoet MCP server lets it search remote job listings, manage your developer profile, and track applications.

When a client connects to a server, the server advertises its capabilities through three primitives:

Tools: Actions the agent can execute. Searching listings, creating a profile entry, submitting an application. These are the most commonly used primitive.
Resources: Data the agent can read, like files, database records, or configuration. Think of these as GET endpoints.
Prompts: Predefined templates that guide the agent through specific workflows. Less common but useful for complex multi-step tasks.

Each tool has a name, a description, and a JSON Schema defining its inputs. The AI reads those descriptions and figures out which tools to call based on what you ask.

So when you say "find me remote companies hiring React developers," the agent looks at the available tools, picks the search tool, fills in the right parameters, calls it, and returns the results. You never have to know the tool exists. You just describe what you want.

MCP vs Function Calling

This is the confusion I see most often. Function calling is a model-level feature where the AI can output structured JSON to invoke predefined functions. It's been around since 2023. MCP is the transport and discovery layer that sits on top of function calling.

Think of it this way: function calling is the engine. MCP is the road network.

Without MCP, every developer has to manually define function schemas, wire them up to API clients, handle authentication, and build the plumbing for each integration from scratch. MCP standardizes all of that. The server describes its tools once, any MCP client can discover and use them, and the client's function calling capability handles the actual invocation.

So they're complementary, not competing. Function calling is what lets the model decide to call a tool. MCP is what lets the model discover tools dynamically from external servers and execute them over a standardized transport.

MCP vs A2A (Agent-to-Agent Protocol)

Google released their Agent-to-Agent (A2A) protocol in early 2025, and I keep seeing people ask whether it competes with MCP. Short answer: no. They solve different problems.

MCP connects an agent to tools and data. A2A connects an agent to another agent. MCP is about giving one agent hands to interact with software. A2A is about letting multiple agents collaborate with each other on a task. You'd likely use both in a mature agentic system, with MCP for tool access and A2A for multi-agent coordination.

The Three Primitives in Practice

I mentioned Tools, Resources, and Prompts above, but it's worth seeing how they play out in a real MCP server.

Remoet has 38 MCP tools. When your agent connects, it receives all 38 tool definitions with their descriptions and parameter schemas. The agent doesn't need documentation. It reads the tool descriptions and figures out the right calls.

Ask "find companies using Go and Kubernetes" and the agent picks the search tool. Ask "show my applications" and it picks the applications tool. Ask "update my summary" and it picks the profile update tool. All from the same conversational interface. No menus, no navigation, no context switching.

This is fundamentally different from a traditional API integration. With an API, a developer writes code to call specific endpoints with specific parameters. With MCP, you describe your intent in natural language and the AI handles the rest.

Security: OAuth 2.1, PKCE, and Prompt Injection

I won't sugarcoat this: connecting AI agents to live services introduces real security considerations.

On the authentication side, MCP supports OAuth 2.1 with PKCE (Proof Key for Code Exchange). This is the same security standard used by major web applications. Each connection requires explicit user authorization, and you can revoke access at any time. Remoet's MCP implementation enforces PKCE on every authorization, with session limits and LRU eviction to prevent resource exhaustion.

The trickier risk is prompt injection. If an MCP server returns malicious content in tool results, it could theoretically trick the agent into taking unintended actions. Good MCP implementations mitigate this by treating all tool results as untrusted data (Remoet's server description explicitly instructs agents to do this), but it's an active area of research. The MCP spec itself is evolving to add better guardrails here.

If you're evaluating MCP servers, look for ones that use OAuth 2.1 rather than just API keys, enforce PKCE, and document their approach to prompt injection defense.

Who Supports MCP Today

The ecosystem has grown fast. Thousands of MCP servers are now listed across various directories, and the number is climbing weekly.

On the client side:

Claude Desktop and Claude Web have native MCP support, including custom connectors via OAuth
Claude Code supports MCP servers out of the box via the CLI
Cursor has built-in MCP configuration
Windsurf supports MCP servers in its settings
VS Code now has native MCP support through GitHub Copilot
Cline and Continue also support MCP

On the server side, the ecosystem spans every category:

Category	Examples
Development	GitHub, Linear, Sentry
Productivity	Notion, Slack, Google Drive
Data	Supabase, PostgreSQL, various database connectors
Search	Brave Search, Context7 (documentation search)
Career & Jobs	Remoet (remote job search, profile management, applications)
Automation	n8n, Zapier

What's striking is that MCP servers aren't just developer tools anymore. They're showing up in every vertical: job platforms, finance tools, CRM systems, e-commerce. Any software with an API can become an MCP server, and increasingly, they are.

Why This Matters For You

If you're a developer, MCP means you can automate a huge chunk of your workflow through conversation. Instead of context-switching between 15 browser tabs, you tell your agent what you need and it handles the tool-hopping.

If you're job hunting, this is where it gets genuinely interesting. Traditional job boards make you do all the work: search, filter, scroll, click into each listing, apply one by one. An MCP-connected job platform flips that. You tell your agent "find companies using my tech stack that are actively hiring" and it does the searching, filtering, and shortlisting for you.

That's exactly what Remoet does. Connect your AI agent once, and it handles the rest: finding companies that match your stack, tracking applications, messaging hiring teams. Your agent becomes your career assistant.

But beyond any single platform, the bigger shift is this: software is becoming conversational. Instead of learning each app's UI, you describe what you want and your agent navigates the tools for you. MCP is what makes that possible at scale.

Getting Started

If you want to try MCP yourself, the setup is simpler than you'd expect. Most MCP-compatible AI apps let you add servers through a configuration file or settings page. You typically need an API key or OAuth authorization from the service you want to connect, and then you're up and running.

We've got a detailed setup guide covering Claude Desktop, Claude Code, Cursor, and Windsurf in our post on how to set up MCP servers.

For a complete walkthrough of what AI-powered job search looks like in practice, check out our agent job search guide.

Frequently Asked Questions

Is MCP only for Claude?

No. MCP is an open protocol governed by the Linux Foundation. While Anthropic created it, it's been adopted by Claude, Cursor, Windsurf, VS Code, Cline, Continue, and others. Any AI client can implement MCP support. OpenAI added MCP support to their agents SDK in early 2025.

Do I need to be a developer to use MCP?

Not necessarily. Some setups require editing a JSON config file, which is a bit technical. But Claude Web supports custom MCP connectors through a point-and-click OAuth flow that requires zero coding. Desktop Extensions are also making one-click installs possible. The trend is clearly toward making MCP accessible to everyone.

Is MCP secure?

MCP supports OAuth 2.1 with PKCE for authentication, which is the same security standard used by major web applications. Each connection requires explicit authorization. You control which services your agent can access and can revoke access at any time. The main emerging concern is prompt injection through tool results, which is an active area of research in the MCP community.

What's the difference between MCP and a browser extension or plugin?

Browser extensions and plugins are specific to one application. A Chrome extension only works in Chrome. A ChatGPT plugin only worked in ChatGPT (and OpenAI deprecated them). MCP is standardized across all compatible AI clients. Build one MCP server and it works with Claude, Cursor, Windsurf, VS Code, and any future client that supports the protocol. Build once, work everywhere.

How many MCP servers can I connect at once?

There's no hard protocol limit. You can connect as many MCP servers as your AI client supports. Most people connect 3 to 10 servers depending on their workflow, covering things like code management, documentation, search, and whatever domain-specific tools they need.

Why Companies Area Restrict Jobs, Even if They Are Remote

Carl-W — Thu, 29 Feb 2024 16:39:45 +0000

Currently, remote work is becoming more mainstream than ever, especially for software engineers who actually only need a computer and a stable internet connection to perform their duties, the fact that companies restrict jobs to geographic areas might seem weird.

Why would it matter where you are if your work and contributions are happening over the internet? This question is often discussed by software engineers looking for remote positions with mostly eye-rolling 🙄 and ridicule. However, there are very valid reasons for this from the company's point of view.

Navigating the maze of taxation and legalities

The primary hurdle for companies employing internationally is the legal complexity. Different countries have unique employment laws, tax regulations, and social security requirements. For a company based in one country, ensuring compliance across all these different jurisdictions can be a logistical nightmare. This complexity isn't just about following the law; it's also about the significant administrative burden involved in managing these requirements for employees in multiple countries. For software engineers, this means that despite the borderless nature of their work, the legal borders significantly impact where they can be employed even if they are remote.

Most globally remote companies that hire regardless of location solve this issue by legally treating everyone as a contractor. The responsibility then falls on the engineer who needs to handle taxes and the administration work by themselves in the country they reside in.

We are making a focused post on this topic alone soon, but in short, this also means that if a software engineer is not prepared for this they might lose out on an opportunity because they do not understand the legal foundation on which they operate. Candidates must also understand that as contractors the contract to the hiring company is just that, a contract. Subsequently, that also means less employment security compared to if you were employed locally since contracts are often renewed on a fixed time basis and the terms might be unfavorable.

We can make the assumption that companies who only hire in their own legal region, want to operate their business more predictably, and they also want to provide the same standard to all their employees. For example, health insurance, pension, vacation days, sick leave, and so forth works differently in almost all countries. Further, equity schemes which are a great way for companies to invest in their employees most likely do not work over international borders easily.

Tax Implications

If the company has the intention of hiring a real employee, taxation is a critical concern for them when hiring internationally. Employing someone in a different country can introduce tax obligations not only for the employee but also for the employer in the employee's country of residence. This can include corporate taxes, payroll taxes, and other contributions that vary widely across jurisdictions. For companies, managing this tax landscape is challenging and often leads them to restrict job postings to regions where they are fully equipped to handle these obligations.

Practically if the candidate is in a different country and they are not going to be treated as a contractor, the company will need to register their company in that jurisdiction, officially employ them, set up bank accounts, and submit tax reports to that government regularly. This is not likely something a small to medium company has the capacity to do.

Offering Equitable Benefits

Beyond legal and tax issues, there's the challenge of providing fair employee benefits. Health insurance, retirement savings plans, and other benefits are deeply tied to local laws and market standards.

A benefits package that's competitive in one country might be lacking in another due to different expectations or requirements. Companies strive to offer fair and attractive benefits to all employees, but the variance in what that means across different countries can lead to geographic restrictions on job postings.

Some companies offer services in this capacity helping hiring companies to bridge the gap but that comes at the cost of having another entity to deal with and obviously, they are not doing it for free.

Collaboration and Time Zones

Software engineering is a collaborative field. While asynchronous work is possible, real-time communication is sometimes crucial for team cohesion, brainstorming, and problem-solving.

Time zone differences can make these interactions difficult, if not almost impossible, to coordinate when team members are spread too thinly across the globe. By restricting jobs to certain areas, companies aim to cluster their workforce within time zones that allow for efficient collaboration.

There can be benefits of having the workforce spread over the world, for instance when it comes to server monitoring. The on-call schedule will be natural as people go on and off work as the world rotates. That is most a benefit for a larger company but most likely impossible for a smaller one.

Conclusion

For software engineers looking for remote work, these restrictions might initially seem like unnecessary. However, they are rooted in legitimate challenges related to legal compliance, taxation, and the practicalities of managing a distributed team. If you understand these reasons it can help you navigate the remote job market more effectively.

If asked during interviews it also shows that you have a fundamental grasp of what it means to work remotely. Not only in a worker capacity but also what responsibility you have towards the company. If you cannot handle your own taxes as a small business you will struggle in your role.

As the remote work landscape continues to evolve, we might see more companies developing strategies to overcome these barriers, expanding the opportunities for software engineers to be "employed" across borders. But until then, if you are looking at global job postings, you will need to be prepared to also handle the extra administration that comes with that, together with the understanding that a substantial part of the money coming in will go to taxes and social fees.

P.S.

If you like this sort of content from engineers who have been working remotely for close to a decade consider creating an account at https://remoet.dev where we send and collect related information. Remote working is the future, and we need to be as informed as we can be.

This post was created for https://blog.remoet.dev