DEV Community: Jerry Kasem

Why Your US Remote Job Search Is Failing Before Anyone Reads Your Code

Jerry Kasem — Wed, 22 Jul 2026 17:50:53 +0000

You spend a Sunday afternoon on LinkedIn or We Work Remotely. You filter for remote. You see hundreds of roles with salaries that would change your life. You apply to twelve of them. Three weeks later you have three rejections and nine silences, and every rejection says some version of the same thing: we are only considering candidates authorized to work in the United States.

This is not bad luck. It is the structure of the market, and once you see it clearly, you stop wasting months on the wrong search.

What "US remote" actually means

The big job boards index tens of thousands of roles tagged as remote. The overwhelming majority of those roles are remote inside the United States. The company has not thought about international hiring. Their legal team has not approved it. Their payroll system cannot handle it. The recruiter who wrote the post did not even consider that someone in Brno or Košice would apply.

When they say remote, they mean: you can work from your couch in Austin instead of the office in Austin.

Work authorization kills your application before it reaches a hiring manager. Before anyone looks at your GitHub. Before anyone reads the system design you wrote in the cover letter. The filter is automatic, it is early, and it has nothing to do with your skills.

Remote roles already get many times the applications of on-site roles. You are competing in the most crowded pool in the market, and you are disqualified on the first filter.

The companies that actually hire you exist, but they are a different set

There are US companies hiring developers in Europe right now. GitLab works across 60 or more countries. Zapier has 800 or more people across 40. Automattic has 2000 or more people across 96 countries. These are not unicorns. They are proof that the model exists.

But those flagship examples are not where your opportunity lives day to day. Your real opportunity is in the layer below them: smaller US companies, Series A and B startups, bootstrapped SaaS businesses that are between 20 and 200 people. These companies think in contractors and international collaborators from day one because they have never had the budget or the inclination to limit themselves to one geography.

They almost never post on the boards you are searching. They hire through referrals, through conversations, through someone on their team knowing someone. When they do post, they post in places you are probably not looking.

You cannot out-apply this problem

The instinct when a job search stalls is to apply harder. More applications, better resume formatting, faster responses. That instinct is wrong here because the constraint is not effort, it is access.

The companies that will actually hire you in Czechia or Slovakia are not reading your application in a portal. They are talking to people. The decision to bring on a remote contractor in Central Europe happens in a Slack conversation or after a conference talk or when a founder sees someone in a niche community answer a hard question well.

You find these companies by reaching the person who decides, not the system that filters. That means identifying founders and engineering leads at the right size and stage of company, understanding enough about their business to have a real conversation, and making contact like a peer, not like an applicant.

This is slower to start than submitting fifty applications on a Saturday. It is also the only approach that actually works for your situation.

What this changes about your search

Stop measuring your search by applications sent. That number is nearly meaningless for your target market.

Start measuring by real conversations initiated with people who have actual hiring authority at companies that are structurally open to international contractors. Ten of those conversations in a month is a better search than a hundred portal submissions.

The roles that pay well and are genuinely open to you are out there. That money is real, and it is well above what the same work pays locally. The path to it is just not through the front page of LinkedIn Jobs.

The market is not closed to you. You are searching in the wrong place.

Written by Jerry Kasem, cofounder of CzechDevUSA. I help senior engineers in Central Europe get seen by US companies, and I help US teams hire them without the markup or the hiring risk. I write about the cross-border hiring wall on LinkedIn: https://www.linkedin.com/company/czechdevusa. If you want to see which US remote roles are actually hiring your stack, the free tools are in the first comment.

The European Tax: Why Senior Czech and Slovak Engineers Stay Invisible to US Companies

Jerry Kasem — Wed, 22 Jul 2026 17:49:30 +0000

The number on your invoice is probably not your problem

You have the skills. You have shipped production code that would get you an interview at any US company if a human ever saw it. But you are not getting calls from US companies, or the calls you get stall out at a rate that does not feel right for your experience level.

That gap is not about your English. It is not about your timezone. It is a tax. A probability tax. And it has three components that stack silently against you.

Deduction 1: The anchor

When a recruiter in Austin or Seattle asks "what are you looking for?", most Central European engineers answer with a number they calculated from the Prague or Bratislava market. Maybe they bumped it up 20% to feel ambitious. That number still lands in the US context as a signal, not a salary expectation. The signal it sends is: this person does not know what they replace.

A senior backend engineer in a US hub costs a company far more than their base salary once you add benefits, payroll taxes, and office overhead. A remote engineer who could replace that seat, but names a number anchored to their local market, has just told the hiring manager something unintended: either the candidate does not understand the market, or there is a catch. Neither reading helps you.

The anchor is not humility. It is misfiring information.

Deduction 2: The filter

Remote tech roles now receive many times the applications of on-site roles. That means the resume screen is brutal before any human judgment enters the picture. ATS systems, keyword matching, and the first ten-second skim by a recruiter working through hundreds of open applications, these are not neutral processes.

Central European resumes tend to have structural habits that cost them in this filter. Education listed before experience. A long profile summary that reads like a LinkedIn bio. Project descriptions that describe technology used rather than outcomes delivered. A US recruiter is scanning for evidence that you solved a problem at scale. If that evidence is buried or formatted in a way that feels foreign, you are out before the senior engineer on the team ever sees your name.

This is not unfair. It is a filter you can understand and work with once you know it exists.

Deduction 3: The risk read

US tech companies that are not already operating across borders have a real and specific fear: timezone gaps that slow pull requests, legal ambiguity around contracts, the question of what happens if there is a compliance issue in a country their legal team has never dealt with. Some of that fear is irrational. Some of it is legitimate.

If your application materials, your GitHub, your communication style, and your interview behavior do not actively address that fear, the hiring manager's brain fills in the blank conservatively. You get read as a risk even when you are not one.

Companies like GitLab operate across 60 or more countries. Zapier has more than 800 people across 40. These companies have solved the infrastructure problem of international remote hiring. But mid-size US product companies that have not done it before need more from you than competence. They need their fear resolved.

Why each deduction compounds the others

Here is the brutal math. If the anchor misreads you, fewer conversations start. If the filter removes you, the conversations that would have started never do. If the risk read kills the late-stage call, the interviews that made it through do not convert.

None of these three things is about your ability to write good code. You could be the best distributed systems engineer your prospective employer has ever seen, and all three deductions could still apply simultaneously.

That is what makes it a tax on probability rather than a tax on skill. Skill is table stakes. The tax is everything that sits between your skill and a US company's willingness to bet on you.

This is a solvable problem

The three deductions are not permanent. The anchor problem has a fix once you understand what a US senior role actually costs the company. The filter problem has a fix once you understand what signal US recruiters are scanning for. The risk read problem has a fix once you understand what specific fears you need to resolve, and how early in the process to resolve them.

None of the fixes require you to pretend to be American or to undersell your European roots. The engineers from Central Europe who are working for US companies right now, on US compensation, are not exceptional outliers. They just stopped paying the tax.

Written by Jerry Kasem, cofounder of CzechDevUSA. I help senior engineers in Central Europe get seen by US companies, and I help US teams hire them without the markup or the hiring risk. I write about the cross-border hiring wall on LinkedIn: https://www.linkedin.com/company/czechdevusa. The two free tools for developers are in the first comment.

Why US Tech Companies Are Ignoring You (It Is Not Your Code)

Jerry Kasem — Wed, 22 Jul 2026 17:49:29 +0000

The rejection that never arrives

You send the application. You wait. Nothing.

No rejection email, no recruiter message, no automated acknowledgment after the first one. Just silence. And because the silence has no explanation attached to it, you fill the gap yourself. You tell yourself the story that is easiest to believe: they looked at your profile, compared you to someone in Austin or Seattle, and decided you were not good enough.

That story feels logical. It is almost certainly wrong.

What is actually happening on the other side

US tech companies that hire remotely receive many times more applications than they do for on-site roles. A single senior opening at a mid-size product company can pull hundreds of applicants in its first weeks. The recruiter screening that pile is usually not an engineer. They are pattern-matching against a mental model built from the candidates they have seen before, and that model is heavily weighted toward signals they recognize: familiar company names, recognizable university brands, GitHub activity that looks a certain way, a LinkedIn headline written in a specific register.

Your skills are not in question. Your visibility inside that pattern-matching process is.

When a Brno-based backend engineer with eight years of production Go experience and a clean open-source record gets ignored, it is almost never because the hiring manager would not want them. It is because the application never made it to the hiring manager.

The filter is not talent, it is legibility

Legibility is the word that matters here. US hiring systems are optimized to recognize a narrow set of signals, and most of them were designed with a domestic candidate in mind. That does not make the system fair. It does make it understandable, and more importantly, it makes it fixable.

Legibility problems have concrete solutions:

Your LinkedIn profile is not written for a US audience. European engineers tend to write job titles and summaries in a compressed, modest register. US profiles, especially in tech, lead with scope and impact. "Developed internal tooling" becomes invisible. "Built a distributed caching layer that cut p99 latency by 40% across 12 microservices" gets attention.

Your GitHub is active but not narrated. Recruiters and senior engineers who do look at GitHub are not reading your code in the first pass. They are reading your README files, your commit message discipline, your pinned repositories. A strong project with a weak README is invisible.

Your application materials do not name the timezone explicitly. US hiring managers are often genuinely uncertain whether a Central European engineer can overlap with a US-based team. If your cover letter or profile does not address this directly, they default to assuming it is a problem, even when CET or CEST gives you solid overlap with East Coast mornings.

You are applying cold when warm beats cold by a large margin. A message to an engineering manager on LinkedIn that references their actual technical choices, their open-source work, or a specific problem their job posting implies, gets read. A cold application through a portal often does not.

The part that should make you angry, then practical

None of what I just described has anything to do with whether you can build good software. Engineers in Prague, Bratislava, Warsaw, and Budapest are shipping production systems that serve millions of users. The technical gap between a strong Central European senior engineer and a strong US senior engineer is, in most cases, not a gap at all.

The gap is that one of them has spent years inside a hiring ecosystem that trained them on its own signals, and the other has not. That is not a permanent condition.

Visibility is learnable. Legibility is adjustable. The profile rewrite takes a weekend. The GitHub narration takes an afternoon. The timezone framing takes two sentences.

Silence is not a verdict on your ability. It is feedback about a presentation layer you were never taught to optimize, because where you trained and worked, you did not need to. Now you do.

The engineers who break through to US remote roles are not always the most technically impressive ones in the room. They are the ones who understood that the filter exists and decided to become legible to it.

A US CTO and a Prague Engineer Both Want the Same Hire. Here's the Wall Between Them.

Jerry Kasem — Wed, 22 Jul 2026 13:00:05 +0000

I asked nine US engineering leaders why they would not hire a senior developer from Central Europe. Not one of them mentioned skill.

These are CTOs in San Francisco, Austin, and New York, with senior roles open for months. The question was simple: there is an engineer in Prague who can do this job, why not him?

Here is what they actually said.

"How do I even pay someone in Czechia?"

"Who owns the code if there is no US contract?"

"What is my recourse if it goes wrong and they are five thousand miles away?"

"I am not going to become an expert in Slovak tax law to make one hire."

Now here is the part that should stop you if you are the engineer.

Those are the exact same fears you have, from the other side of the table.

The mirror

I have talked to a lot of developers in Prague, Brno, Bratislava, and Košice this year. When I ask what is stopping them from taking a US remote role, almost nobody says their English or their skill. They say:

"I don't know how to set up the B2B structure."

"I'm scared of the contract, it's US law, I have no idea what I'm signing."

"I wouldn't know how to price myself without a benchmark."

"What if they don't pay? I have no recourse from here."

Read the two lists side by side. The CTO in Austin is afraid of paying. The engineer in Brno is afraid of getting paid. The CTO is afraid of the contract. So is the engineer. Same wall, both sides standing at it, each assuming the problem is on the other side.

Both of them are ready. Both of them want the deal. It does not happen, because the space between them is five thousand miles of paperwork and perceived risk that neither side knows how to close, and there is no one standing in the middle to close it.

None of that is a skill problem. The code was never the question.

What actually closes it

The good news is that every item on both lists is mechanical, and mechanical things have known answers.

Payment. A developer abroad invoices a US company as an independent contractor. The company pays an invoice, the same as it pays any vendor. Wise or a similar service moves the money in USD. No US entity is required on the engineer's side to start.

The tax fear on the company side. A foreign contractor files a W-8BEN once. It tells the US company there is no US tax to withhold and no filing burden lands on them. It is one form, and it turns "I'd have to learn Slovak tax law" into "I've paid a hundred vendors like this."

The contract. A short, plain contractor agreement covers the five things that actually matter: scope, rate, payment terms, IP assignment, and termination. IP assignment is the clause that answers the CTO's "who owns the code" and it is standard, not exotic.

The rate. The engineer's fear of pricing blind and the company's fear of overpaying are the same missing number. It is not a Prague salary and it is not a full US salary. It is the US contractor replacement rate, minus the overhead the company does not carry, and both sides relax the moment that number is on the table with a reason behind it.

Recourse and trust. Milestones and a first small paid engagement de-risk the first month for both sides far better than any promise. Nobody has to bet the whole relationship on a stranger.

The point

The engineer in Brno is ready. The CTO in Austin is ready. The thing between them is not talent and it is not language. It is a bridge that neither of them was ever taught to build, made of a handful of forms and one honest number.

That is the part I do. I sit in the middle and make a developer abroad as easy and safe to hire as the one down the street.

If you are the engineer, two things worth doing right now: see which US remote roles are actually hiring your stack, and get the map for how the paperwork and positioning really work so the silence stops being a mystery.

What US Engineering Leads Actually Check on GitHub Once Your CV Has Their Attention

Jerry Kasem — Fri, 03 Jul 2026 13:00:07 +0000

After the CV passes and the first conversation goes well, most leads will look at your GitHub or portfolio before they move to a deeper technical discussion or an offer. They are not looking for a polished profile with hundreds of stars. They are answering a narrower set of questions about how you actually work.

They want evidence that you can own something end to end. A repository where the commit history shows you making decisions, handling tradeoffs, and shipping changes without constant back and forth tells them more than a list of technologies on a CV. They notice when the README or the issues show clear thinking about the problem being solved, rather than a pile of code with no context. They look for signs that you document what matters and leave enough behind for someone else to pick up the work later.

What tends to get discounted is activity that looks like maintenance or minor contributions with no clear ownership. A long list of small pull requests across many repositories can read as someone who executes tasks well inside someone else's system. That is useful, but it does not tell the lead whether you can drive work forward when the requirements are incomplete or the direction is still forming.

Leads also pay attention to how you handle feedback and iteration. Public issues or pull request threads where you explain your reasoning, answer questions, and adjust without getting defensive give a preview of how code review and collaboration would actually go with you. When there is no visible discussion or decision history at all, it is harder for them to picture working with you asynchronously.

The strongest profiles usually show a few projects where the scope was meaningful and the outcome is visible. They do not need to be open source projects with thousands of users. They need to show that you can take something from unclear to shipped, and that other people can understand what you did and why.

If your GitHub or portfolio is not generating the follow up interest you expect after good conversations, the gap is often visible earlier, in how your CV presents the work you have actually done. Running it through the free US Remote Roles tool at https://roles.czechdevusa.com shows where the story of your experience is landing clearly and where it still leaves too much for the reader to guess.

How US Companies Actually Contract With Developers Outside the US

Jerry Kasem — Wed, 01 Jul 2026 13:00:06 +0000

Once interest exists, the conversation eventually moves to how the work would actually get paid for and contracted. This stage trips up a lot of strong candidates, because the mechanics are different from what most developers outside the US are used to with local clients or agencies.

US companies that bring on contractors directly usually want the simplest possible setup on their side. That often means a straightforward agreement where you invoice them, they pay on net terms, and there is minimal extra paperwork or tax withholding. What creates hesitation is anything that signals extra legal or finance work. Needing to route payments through a local entity, complex tax forms, or asking the company to set up new compliance processes tends to slow things down or kill the opportunity quietly.

The candidates who move through this stage cleanly usually signal early that they are already set up to work this way. They can speak plainly about how they currently invoice other clients, what payment terms they are used to, and whether they have worked directly with US companies before. They do not hand the contracting discussion off to someone else or push it to later. They treat it as part of the work.

Payment method and timing is another practical detail. Some developers push for upfront payments or shorter terms because they have been burned by slow payers. That instinct is understandable, but to the company it often reads as higher risk. Teams that hire regularly have standard processes, and they prefer contractors who fit inside those processes without creating exceptions. The ones who get the work can usually say they are comfortable with the company's normal terms and have made similar arrangements work before.

The real filter here is rarely the rate. It is whether the company believes bringing you on will create less administrative drag than the value you deliver. When the contracting conversation feels simple and low risk, everything else moves faster. When it looks like it will need extra legal review or special handling, the opportunity often fades, even when the technical fit was strong.

If you are reaching the contracting stage and then watching deals slow down or disappear, the root is often in how your earlier materials and conversations framed the practical side of working together. The free US Remote Roles tool at https://roles.czechdevusa.com highlights the signals that shape these later discussions before they turn into blockers.

What Actually Happens in the First Call With a US Team After Your CV Passes

Jerry Kasem — Mon, 29 Jun 2026 13:00:07 +0000

You finally get the response. The CV cleared whatever filter it was up against, and now there is a calendar invite for a thirty or forty five minute call. Most developers treat this as the technical screen and prepare accordingly. They load up on system design questions, leetcode style problems, or deep dives into the stack listed in the job post.

What actually happens in that first call is often lighter on code and heavier on whether the person on the other side can picture working with you week after week. The engineering lead or hiring manager is trying to answer a few practical questions the CV could not fully settle. Can this person explain their decisions without needing constant context? Do they push back on unclear requirements in a way that moves the conversation forward instead of creating friction? Do they already understand how remote contractor work tends to flow, or will every interaction need extra translation?

The candidates who lose ground here rarely fail on raw technical ability. They lose it on rhythm and assumptions. Some over-prepare the technical side and under-prepare the part where they need to show how they handle ambiguity. Others treat every question as an interview question that demands a polished answer, when what the lead wanted was a working conversation. The call ends with a quiet sense that this person will need more hand-holding than the role allows.

Timezone and async signals are another place people slip. When a candidate spends the call reassuring the other person that they can work US hours or that they are always available for meetings, it often lands as uncertainty. The reassurance backfires. Teams that hire contractors remotely have already accepted some timezone spread. What they want to hear is how you have made async work in the past, what you leave behind when you log off, and how you keep momentum without daily syncs.

The calls that move forward feel like two people working a problem together. The candidate is not sitting there being tested, they are figuring out whether the project and the working style actually fit. They ask clarifying questions that show they understand the real constraints of the role. They give examples of work where they had to make decisions with incomplete information. They treat the call as a two way read, not a gate to clear.

If the conversations after your CV are not producing the next step as often as you expect, the cause usually traces back to how your materials set up what kind of collaborator you are. Running your CV through the free US Remote Roles tool at https://roles.czechdevusa.com surfaces the signals that shape those later conversations, before you spend time on calls that go nowhere.

How to Stop Explaining Your Non-US Experience and Start Using It as Proof

Jerry Kasem — Fri, 26 Jun 2026 01:07:05 +0000

A lot of strong developers outside the US hit a point where they feel they have to apologize for their background. They add disclaimers about time zones, they soften how they describe their work in case it sounds too foreign, and they try to come across more like the candidates a US company is already hiring.

It usually backfires. The moment you start defending your experience, you turn something solid into something that looks like it needs defending.

US remote teams are not really looking for people who can pass as local. What they want is someone who can deliver without adding process on their end, and the developers who win are usually the ones who treat a non-US background as direct evidence of the traits remote work rewards.

Working across different regulations, with different tooling limits, or through language and time barriers tends to force higher ownership and clearer communication out of you, whether you wanted it or not. That is not a soft skill. It shows up in how you write a project update, how you handle a vague requirement, and whether you keep momentum when the next sync is eight hours away.

The mistake a lot of CVs make is burying that under generic phrasing. Instead of showing that you owned delivery when context was thin, the bullet stays at "collaborated with international teams." Instead of naming the actual call you made when nobody was around to make it for you, the line stays vague, and the reader quietly assumes the work was simpler or more supported than it really was.

The stronger move is to make the constraint visible and then show what you did inside it. A project that shipped despite limited access to a tool or a stakeholder becomes proof of resourcefulness. A system you kept running across time zones becomes proof you can work async. Details like that answer the real worry without you ever having to write "I can work US hours" or "I am easy to manage."

Companies that hire contractors directly have already decided they want the overhead gone. They are not trying to slot you into an existing onsite routine. They are looking for someone who has already worked out how to create value with less hand holding, and your background can show that plainly the moment the CV stops hiding the differences and starts showing what those differences produced.

If you want to see how your current CV frames your experience, and where it is raising questions instead of answering them, paste it into the free US Remote Roles tool at https://roles.czechdevusa.com. You get a clear view of which parts are already working as proof and which parts still read as something you are explaining away.

The Exact Lines US Hiring Managers Read First and the Ones They Skip Entirely

Jerry Kasem — Fri, 26 Jun 2026 01:06:09 +0000

You send a CV that feels complete. Every role is there, every technology you have touched is listed, and you kept it to the one or two pages everyone tells you to. Still nothing comes back.

Here is the part most advice skips. US hiring managers and the people who screen for them do not read the whole thing on the first pass. They scan it, looking for a few specific patterns and ignoring the ones that experience has taught them do not predict how someone actually performs on remote work.

In the first fifteen lines they are usually hunting for three things: clear evidence you have shipped real work, some sign you can operate without being managed line by line, and enough clarity on how a US company would actually work with you that legal and finance will not raise a hand.

Almost everything else gets skipped on that first read. Long lists of frameworks, generic claims about being a team player or a strong communicator, bullet points that open with "responsible for" instead of what changed in the product. A line like that gives the reader no reason to say yes. At best it avoids giving them a reason to say no, and that is not enough to win a screen.

The gap that shows up most often is the distance between describing work and showing outcomes under real constraints. A US remote role usually means fewer meetings, less context handed to you, and more ownership. If the CV only shows that you executed tasks inside a bigger team, the reader cannot tell whether you can handle the version of the job where you have to find the important problems yourself.

Anything that makes the reader do extra work also gets discounted. If an achievement only lands once they understand how a particular local company or regulation works, they will not stop to learn it. They move to the next CV that explains its impact without requiring any local knowledge.

The lines that actually hold attention are the ones that answer the questions nobody writes down. Can this person work across time zones without daily hand holding? Have they already dealt with US or international stakeholders directly? Do they understand what it means to invoice cleanly and own delivery without a local manager translating the requirements? Most CVs leave all of that for the reader to infer. The ones that move forward make it obvious inside the first screen.

If you want a precise read on which of your lines are carrying weight and which are being skipped, run your CV through the free US Remote Roles tool at https://roles.czechdevusa.com. It shows you the sections a US reader is likely to lock onto and the ones quietly working against you.

Your CV Was Written for the Wrong Market and US Companies Can Tell in Six Seconds

Jerry Kasem — Fri, 26 Jun 2026 01:06:04 +0000

You keep applying to US remote roles that match your stack and your years of experience, and the applications just disappear. No feedback, no interview, nothing. After enough of that you start to wonder whether the problem is your skills or whether something is going wrong long before anyone opens your GitHub.

Most of the time it has nothing to do with how you write code. The CV is what stops you. Developers outside the US usually write their CVs for the local market or for general international applications, and US hiring managers read with a different set of filters than the ones those CVs were built for.

Local conventions create friction in the first second. A photo, a date of birth, a marital status line, or a long personal summary at the top tells a US reader the document was not prepared for their process. They do not need any of it, and seeing it there often reads as a sign that the candidate has not worked out how US companies actually evaluate people.

Task lists make it worse. When the top half of the page is a description of responsibilities rather than what you shipped and what changed because of it, the reader moves on. US screeners are trained to look for concrete impact on the first pass, and when the impact is missing from the page they tend to assume it was missing from the work too.

Company names that only carry weight locally are another quiet filter. A strong role at a respected firm in your country can land as unknown to someone reading in Seattle or New York. If the CV never says what the company does, what scale it runs at, or what the hard technical problems were, the reader fills the gap with a smaller assumption than the truth.

The legal and invoicing signals matter more than people expect. A mention of sole proprietorship, EU VAT handling, or local payroll structures in the experience section can trigger a quiet note that this person will mean extra work for legal and finance. Companies that hire contractors directly want the opposite read. They want to see that you already invoice US companies cleanly, or that you are set up to, without adding compliance drag on their side.

None of this is about your skill. It is about translation. The CV was written for one audience and is being read by another, and the gap is doing the damage.

If you want to see exactly where your current CV trips these filters for a US reader, see which US remote roles are actually hiring your stack right now at https://roles.czechdevusa.com. Tell it what you build and I will email you live openings from companies that hire from abroad.

Why Strong Developers Outside the US Get Ignored by American Companies (It's Not Your Code)

Jerry Kasem — Wed, 24 Jun 2026 14:57:28 +0000

You can build distributed systems, contribute to open source, and pass any technical screen thrown at you. But your applications to US companies go nowhere. No reply. Maybe a form rejection three weeks later.

That silence is not about your ability. It is about access, and access is fixable.

The actual problem

US hiring teams are not sitting around doubting whether engineers in Warsaw or Bangalore or Lagos can write good code. They are moving fast, drowning in applications, and defaulting to patterns that feel safe. When your profile does not immediately read as low-friction across a border, you get skipped. Not rejected. Skipped. There is a difference.

Remote roles at US tech companies already receive roughly four times the applications of on-site positions. That means a recruiter spending eight seconds on your profile needs to instantly understand: can we hire this person, will time zones work, do they communicate in a way our team will trust? If the answer is not obvious in those eight seconds, you are gone.

The problem is not your skills. It is that your profile was not built to answer those specific questions.

What "reads as a safe hire" actually means

This phrase sounds soft but it is mechanical. US hiring teams, especially at mid-size and larger tech companies, have checklists running in their heads even when they do not realize it.

A few things that quietly kill applications from developers outside the US:

Your location reads as ambiguous. If your profile says a city but not a country, or names a country the recruiter cannot instantly place on a mental map of "we have hired there before," you get hesitation. Hesitation turns into a skip.

Your availability signals are missing. Remote does not mean the same thing to everyone. A US team wants to know: overlap hours, async communication comfort, response norms. If none of that is visible, they assume the worst case.

Your English feels formal in the wrong way. Not incorrect, just stiff. US tech culture in written communication is direct and low-ceremony. Profiles and cover notes that sound translated, even subtly, create a small friction that compounds.

Your work history does not map to US company stages. If you have worked at a 400-person enterprise in Germany, that experience is real and valuable. But if the description does not translate it into terms a US startup or scale-up recognizes, the recruiter cannot place you.

None of these are about being less capable. They are about legibility across a context gap.

The access part

Here is something worth sitting with. GitLab operates across more than 60 countries. Zapier has over 800 people spread across 40. Automattic has more than 2,000 employees in 96 countries. These are not experimental programs. This is how they run.

The infrastructure for hiring you already exists at a meaningful number of US companies. The question is whether you are findable within it and whether your profile does the right work when someone finds you.

Findable means showing up in the right searches on LinkedIn, in GitHub activity that signals consistency not just raw commits, and in communities where US hiring managers actually look. Most developers outside the US are not unfindable because they are obscure. They are unfindable because their signal is optimized for the wrong audience.

What to actually do

Start with your LinkedIn headline and about section. Rewrite them with a US reader in mind, not a local one. Be explicit about remote availability and time zone overlap. Drop the formal summary structure and write the way you would explain your work to a smart colleague over coffee.

Then look at your application behavior. Are you applying to roles that explicitly say remote? Are you filtering for companies with a distributed track record, or are you sending applications into the void at companies that have never hired internationally and have no process to do it?

Target is everything. A strong application to the wrong company is worse than a decent application to a company already set up for you.

Finally, audit your GitHub and any public work for signal quality. Recruiters who care about engineers do look. Consistent contribution patterns, readable READMEs, and a project or two that shows judgment not just execution, these things matter when your resume is otherwise equal to ten other candidates.

The bottom line

The gap between a strong developer outside the US and a job offer from a US company is almost never about skill. It is about the profile not reading right and the targeting being off. Both of those are problems you can fix without moving, without a visa, and without luck.

If you want a structured way to close that gap, the free guide at access.czechdevusa.com/free walks through the specifics.

The US contract you didn't get wasn't a skills problem. It was one missing line.

Jerry Kasem — Tue, 23 Jun 2026 13:30:00 +0000

You are not getting rejected because you are not good enough. You are getting filtered out before a human ever reads your code, by a question your CV never answers.

I talk to senior engineers outside the US every week. Eight, ten, fifteen years in. People who have built distributed systems, carried pagers through real outages, shipped things that move money. And they keep hitting the same wall with US remote roles: apply, silence. Apply, silence. "We went another way."

They assume it is the skills. It is almost never the skills.

The enemy is not the ATS

Everyone loves to blame the applicant tracking system, the keyword robot that supposedly eats your resume before a human sees it. That myth is comfortable because it means the rejection is not about you, it is about a machine. But it is mostly wrong, and it keeps you fighting the wrong thing.

The real filter at a US company looking at a candidate abroad is a single, boring, practical question that runs in the hiring manager's head in the first few seconds:

"Can I even hire this person without it becoming a project?"

A US company does not want to sponsor a visa for a contractor. It does not want to figure out international payroll. It does not want to become an expert in your country's tax law. The moment your CV makes them wonder about any of that, you become the candidate that creates work, and the easy "no" wins. Not because you are weak. Because you are a question mark, and they have ten other resumes that are not.

The story

A backend engineer I know, ten years in, e-commerce at real scale, kept getting ghosted by US companies. Strong CV, real systems, good English. Nothing.

He was already set up to invoice as a business. He had done cross-border work before. From the US side, he was one of the easiest people in the pile to hire. His CV just never said so. So every reader filled the blank with the scary version: sponsorship, payroll, risk, hassle. And moved on.

He added one block near the top of his CV. Three lines. The ghosting stopped inside two weeks. Same engineer, same experience, same projects. One difference: he answered the question before they had to ask it.

The gift: the line that does it

If you contract (or can set up to), put a short, explicit work-authorization block near the top of your CV and your LinkedIn. Something like:

Engagement: Independent contractor (B2B). I invoice US companies directly through my own entity, paid via standard rails (Wise, Payoneer, bill.com). I provide a W-8BEN. No visa sponsorship or work authorization required.

That is it. That single block turns you from "a question I have to investigate" into "a vendor I have paid a hundred times before." It removes the easy no.

Notice what it does:

"Independent contractor (B2B)" tells them this is a clean commercial relationship, not employment.
"invoice directly through my own entity" tells them there is no third-party body shop skimming your rate and locking you in.
"paid via standard rails" tells them getting money to you is solved.
"I provide a W-8BEN" tells them the tax paperwork is handled and you have done this before.
"No sponsorship required" kills the single biggest reflex objection in one phrase.

You are not lying, exaggerating, or keyword-stuffing. You are just stating the thing that was already true and that they were quietly worried about.

Why this matters more than another LeetCode month

Most engineers, when the US market goes quiet on them, grind harder on the things they can already do: more algorithms, more side projects, more certs. That is polishing a car nobody has figured out how to buy yet.

The market for senior engineers who can plug in as a clean contractor is real, and it pays well above local rates for the exact same work, because the US company saves on the employer overhead, not on you. The thing standing between many strong people and that market is not depth. It is that their paper makes them look harder to hire than they are.

Fix the one line first. Then go back to being brilliant.

I wrote a free guide that maps where these US remote contract roles actually live (most never hit a public job board) and how to read like an easy hire from abroad. No cost, no catch: https://forms.fillout.com/t/efhSmqRbkius

And there is a free tool that emails you the US remote roles hiring your stack right now: https://roles.czechdevusa.com

If you want the whole system end-to-end, CV to where the roles hide, to the interview, to setting your rate to the contract, and getting paid clean across a border, that is the US Remote Job Playbook: https://jirikstar.gumroad.com/l/kuqmfp

Tell me in the comments where you are getting stuck. I read every one.