DEV Community: Jerry Kasem

Your GitHub Profile Is Not Getting You Hired (Here's What Actually Does)

Jerry Kasem — Fri, 21 Aug 2026 13:01:18 +0000

Hard truth: nobody at a real US tech company is scrolling through your commit history to decide if you're worth interviewing.

I know that stings. You spent years building side projects, keeping your contribution graph green, writing clean commit messages nobody reads. Now you're applying to remote roles at companies headquartered thousands of miles away, hoping that green grid speaks for you.

It doesn't. Not the way you think.

Let me explain why, and what actually moves the needle when a hiring manager in Austin or Berlin is deciding whether to bring you in.

The GitHub myth

Somewhere along the way, developers started treating GitHub like a resume. Keep it active, show diversity of projects, pin a slick README, and recruiters will find you.

Here's the problem: most hiring managers don't have time to read your code before the first call. They're triaging dozens of applications for one remote role, because remote postings pull roughly 4x the applicants of an equivalent on-site job. Nobody is doing deep code review on candidate 37.

Your GitHub might get a glance. It rarely gets a read.

What they're actually screening for

When a US company hires remote, especially across time zones, they're not primarily worried about whether you can code. If you've gotten this far in your career, they assume you can. What they're worried about is whether you can operate without supervision, communicate clearly in writing, and make decisions when nobody is watching your screen.

That shows up in completely different signals than a contribution graph:

Can you explain a technical tradeoff in three sentences, in writing, without a meeting?
Have you owned something end to end, not just shipped a feature someone else scoped?
Do your past roles show you closing loops, not just opening PRs?

None of that lives in your commit history. It lives in how you talk about your work.

The real filter is async communication

Distributed companies live or die on written communication. Think about how GitLab operates across more than 60 countries, with almost no shared offices and no synchronous default. That only works if people can write clearly, document decisions, and communicate progress without someone physically checking in.

That is the skill being screened for, even when the job posting says "5+ years React." The stack question is often a formality. The real question underneath it is: can this person function on a team where the default is silence, not standup?

So what should you actually optimize?

Not your GitHub. Not another side project nobody will look at. Instead:

Your written summary of impact. Not "built a microservice," but "reduced checkout latency by 40%, traced it to a caching bug I found and fixed." Specifics prove ownership.
Evidence of decisions, not just code. Interview answers that show you weighing tradeoffs matter more than a portfolio piece.
Clarity under ambiguity. Can you describe a time you had to make a call with incomplete information, and explain your reasoning in writing?

These are things a recruiter can actually evaluate in a resume, a cover note, or a thirty minute call. They cannot evaluate your code style from a glance at a repo.

The uncomfortable part

This means the work you've been doing to "look active" on GitHub is largely wasted effort if your goal is getting hired by a US remote team. Code quality still matters eventually. It just isn't the first filter, and it is almost never the deciding one.

The developers who get hired into these roles aren't the ones with the greenest graphs. They're the ones who can articulate, clearly and specifically, what they did and why it mattered, in language a non-technical recruiter can still follow.

If you want to spend your energy well, spend less time polishing repos nobody will open, and more time getting sharp about telling the story of your impact. That's the actual audition.

The Three Things US Engineering Leaders Get Wrong About Hiring Contractors Abroad

Jerry Kasem — Wed, 19 Aug 2026 13:00:06 +0000

Most engineering leaders who consider hiring contract engineers in Central Europe or elsewhere overseas assume the biggest risk is language, time zone, or vague 'cultural fit.' It almost never is. After watching enough of these engagements succeed or quietly stall, the pattern is nearly always one of three managerial mistakes made on the US side, not a skills gap on the contractor side.

Mistake one: optimizing for overlap hours instead of handoff quality

Leaders often screen candidates by asking how many hours they can be online during Pacific or Eastern time. That's the wrong question. A senior engineer working six time zones away who writes a clear, complete end-of-day handoff will move your roadmap faster than someone who's 'always available' but leaves ambiguous status updates. Async communication is a skill you can test for directly. Ask a candidate to write a sample handoff note for a half-finished task during the interview. You'll learn more from that one exercise than from a scheduling spreadsheet.

Mistake two: hiring for rate instead of depth

Treating contractor hiring as a pure cost-arbitrage exercise is understandable and it almost always backfires. A cheaper rate that requires more specification, more review cycles, and more rework isn't actually cheaper. It's slower, and it burns the scarcest resource on your team: engineering leadership attention. The contractors worth hiring price closer to a strong US mid-to-senior engineer, and they earn that rate by needing less oversight, not more.

Mistake three: managing contractors like employees

This is the one that quietly kills the best engagements. A leader hires a senior contractor specifically because that person can own a problem end to end, then puts them into daily standups, status check-ins, and approval gates built for junior full-time staff. That's a mismatch. Senior contractors do their best work with a clear scope, a defined outcome, and the autonomy to find the path themselves. Micromanaging a senior hire doesn't make delivery safer. It slows it down and often pushes the best people toward the next contract instead of yours.

What good actually looks like

The teams that get distributed contracting right share a few habits. They write specs, not tickets. They define outcomes, not hours. They review work at milestones, not in daily standups. Organizations operating at real scale across many countries, GitLab spans more than 60, Zapier runs 800-plus people across 40, Automattic has 2,000-plus across 96, didn't get there by micromanaging time zones. They got there by building processes that assume competence and verify outcomes, instead of assuming the opposite and verifying hours.

The real fix is a mindset shift, not a geography filter

None of these three mistakes are actually about geography. A US-based senior contractor managed the same way would hit the same friction. What changes with an overseas hire is that the mistakes become visible faster, because there's no hallway conversation to paper over a vague spec or a missed handoff. That visibility is useful. It forces the kind of clear, outcome-based management that makes every engineer on a team more effective, remote or not.

If you're evaluating a contract engineer from abroad, the real diligence question isn't 'can they work my hours.' It's 'can I write a spec clear enough that the time zone stops mattering.' Most leaders haven't tested that about their own process yet. It's worth doing before the job goes live.

The System Design Interview Isn't About Systems

Jerry Kasem — Fri, 14 Aug 2026 13:01:39 +0000

You Didn't Fail Because of CAP Theorem

Most candidates walk out of a system design round convinced they lost on technical merit. They forgot to mention idempotency keys, or they picked SQL when the interviewer wanted NoSQL, or they ran out of time before drawing the caching layer.

That is rarely what happened.

A US engineering manager running a system design interview is not grading your architecture. They already know you can design a URL shortener or a rate limiter, that's why you got the interview. What they are actually measuring is something narrower: can this person make a decision under ambiguity, say it out loud, and defend it without a manager standing over their shoulder.

That distinction matters once you understand who is actually running the interview and why.

The real test: can you work without supervision

In a US tech company, especially a remote-first one, nobody is sitting next to you to catch your mistakes early. Your manager might be nine time zones away. Your tech lead might review your design doc twelve hours after you wrote it. By the time anyone weighs in, you've already committed code, opened a PR, maybe shipped.

So the system design round is a proxy. It answers one question: if I hand this person a vague problem with no clear spec, will they freeze, will they guess silently and hope it's right, or will they narrate their reasoning and surface assumptions before a mistake gets expensive?

That's not a technical skill. It's a communication habit. It's exactly what breaks candidates who are strong engineers but come from teams where the senior person decides and everyone else implements.

What actually gets scored

Watch what interviewers write down. It's rarely "used Redis correctly." It's things like:

Asked clarifying questions before designing anything
Stated assumptions explicitly ("I'm assuming write-heavy, low read latency")
Named tradeoffs out loud instead of picking silently
Changed direction when challenged, without getting defensive
Left room for the interviewer to disagree

Every one of those is a proxy for how you'll behave in a Slack thread at 11pm their time when nobody can jump on a call to sort it out live.

Why this hits non-US candidates disproportionately

If you trained in a system where senior engineers make the call and juniors execute, "thinking out loud" can feel like showing weakness. You've been taught hesitation looks unqualified. So you rehearse an answer, deliver it smoothly, and get dinged for sounding like you memorized a template instead of reasoning live.

US hiring managers read confident silence as risk, not competence. They're not looking for the person with the most polished diagram. They're looking for the person they'd trust to make the wrong call transparently rather than the right call secretly.

What to actually practice

Stop rehearsing designs. Start rehearsing narration. Practice saying "I don't have enough information yet, so here's what I'm assuming" before drawing a single box. Practice picking an imperfect option out loud and explaining why it's good enough for now. Practice being challenged mid-answer and changing course without apologizing for being wrong.

This matters even more at fully distributed companies. Organizations like GitLab, which runs engineering across more than 60 countries, cannot function if decisions require real-time supervision. Their entire model depends on people who reason transparently and asynchronously, and their interviews are built to filter for exactly that.

The system design round was never really about systems. It's a rehearsal for the actual job: making judgment calls, in public, without a safety net.

The Interview Question That Quietly Sinks Excellent European Engineers

Jerry Kasem — Wed, 12 Aug 2026 13:01:19 +0000

You didn't fail the coding round. You failed a sentence.

Here's a scenario I hear constantly from senior engineers in Prague, Berlin, Warsaw, and Lisbon: strong system design round, clean code, great references. Then a rejection with vague feedback like "not the right fit" or "we didn't feel confident in the leadership signal."

Nine times out of ten, the actual moment that killed the offer wasn't technical at all. It was a single behavioral question, usually some version of:

"Tell me about a time you disagreed with your manager or a teammate. What happened?"

This question looks harmless. It's not testing your Kubernetes knowledge or your understanding of consistency models. It's testing something US companies care about deeply and rarely say out loud: can you make an individual decision, own it publicly, and survive the friction of being wrong or being right in front of other people.

Why the answer goes sideways

Most European engineering cultures train you, correctly, to value consensus, humility, and collective credit. Good instincts for a team. Terrible instincts for this specific fifteen minutes.

So when the question lands, the honest, well-socialized answer sounds like:

"We had different opinions, so we discussed it as a team and eventually aligned on an approach that worked well for everyone."

Technically true. Diplomatically safe. And to a US hiring panel, almost content-free. There's no "I." There's no decision. There's no risk taken, no moment where you stood alone with a position and had to defend it. The interviewer isn't grading whether the team got along. They're grading whether you, specifically, can be trusted to make a call when nobody is around to build consensus for you.

What the panel is actually listening for

US companies, especially remote-first ones where nobody is watching you work in real time, use this question as a proxy for something they can't test with a whiteboard: independent judgment under ambiguity. They want to hear:

What exactly did you believe, specifically, that differed from someone else's view
What you did about it (pushed back, escalated, prototyped a counterexample, whatever)
What the actual outcome was, including if you were wrong

Notice none of that requires arrogance. It requires ownership. "I thought X, so I did Y, and here's what happened" reads as competent and safe to a US interviewer in a way that "we aligned as a team" never will, even though the underlying story might be identical.

The fix is almost embarrassingly simple

Take any story you'd normally tell in consensus language and rewrite it in first person, with a concrete stance and a concrete action. Not "we decided to roll back the deployment." Instead: "I flagged that the migration would break backward compatibility, disagreed with the timeline the lead wanted, and pushed to delay the rollout by two days. I was right about the compatibility issue, wrong about how much buffer we actually needed."

That second version isn't more boastful. It's just legible to the person grading it.

Why this matters more than it used to

Remote roles now pull in roughly four times the applications of equivalent on-site positions, which means panels are pattern-matching faster and with less patience for ambiguous signals. A story that reads as vague costs you more than it did five years ago, simply because there are more candidates telling clearer ones.

This isn't a language problem. Plenty of engineers with excellent English fail this question. It's a framing problem, and it's fixable the moment you notice it's happening.

The technical bar was never the hard part for you. This sentence was.

The Timezone Gap Isn't a Bug, It's a Forcing Function

Jerry Kasem — Fri, 07 Aug 2026 13:00:53 +0000

Here's a hard truth most engineering leaders don't say out loud: your team's speed depends way too much on people being in the same room at the same time.

You don't notice this until someone joins who isn't. A senior engineer in Prague, six or nine hours ahead of your US team, will expose every place where your process was actually just "ask Dave, he remembers."

The instinct is to treat this as a problem to manage. Standups get awkward. Someone has to stay late or log in early. Slack threads pile up overnight. It feels like friction.

But watch what actually happens over the following few months.

Decisions get written down. When you can't grab someone in the hallway to settle a design question, you write it in a doc or a ticket instead. That doc doesn't disappear when the meeting ends. It becomes the record. Six months later, nobody has to reconstruct "why did we do it this way" from memory.

PR descriptions get better. A reviewer working nine hours later than the author can't ask a quick clarifying question and get an instant answer. So the author starts explaining context up front: what changed, why, what was considered and rejected. That habit doesn't stay confined to the async engineer's PRs. It spreads.

Meetings get smaller and sharper. You can't schedule five people across a 9-hour spread for a 30-minute sync without real cost. So teams start asking: does this need a meeting, or does it need a doc? Most of the time it's a doc.

Bottlenecks around specific people become visible. If your architecture decisions only happen when one particular engineer is awake and in a good mood, that's not resilience, that's a single point of failure with a keyboard. A distributed team forces you to notice this and fix it, because otherwise nothing ships on the days that person is asleep.

None of this is really about timezones. It's about whether your team's knowledge lives in people's heads or in artifacts other people can read. Timezone spread just makes the gap impossible to ignore, because the workaround (walk over and ask) isn't available anymore.

Companies that have scaled distributed engineering hard already know this. GitLab operates across more than 60 countries. That's not possible if institutional knowledge only exists in synchronous conversations. It's only possible if the default mode of working is written, asynchronous, and reviewable by someone who wasn't in the room.

The uncomfortable part for a lot of US teams is that this same discipline would make them faster even without a single overseas hire. Distributed timezones don't create the need for better documentation and clearer decision records. They just make it impossible to keep pretending you don't need them.

So if you're evaluating whether a senior engineer nine timezones away is worth the coordination cost, that's a fair question to ask. But the more useful question might be: what is your team's process currently relying on that only works because everyone happens to be awake at the same time? Because that dependency was always a risk. The timezone gap just makes you deal with it now instead of later, during an outage, when the one person who understands that system is on vacation.

The engineers who thrive in this setup aren't the ones who happen to tolerate odd hours. They're the ones who were already good at writing clearly, documenting decisions, and working without needing constant real-time confirmation. That skill set is valuable on any team, in any timezone. Distributed work just makes it non-optional.

Your Engineering Budget Isn't Too Small. You're Shopping in the Wrong Market.

Jerry Kasem — Wed, 05 Aug 2026 13:01:19 +0000

The budget fight you keep losing

Every quarter it's the same conversation. You need another senior engineer. Finance wants headcount frozen or contractor rates capped. You end up with a choice that feels forced: pay full US market rate for a senior contractor, or drop down to junior talent and hope code review catches what experience would have prevented.

That choice is fake. It exists because you're comparing candidates inside one geography instead of comparing markets.

The bar isn't the variable. The market is.

Contract engineers in Czech Republic, Poland, or Slovakia solve the same distributed systems problems, ship the same Terraform, debug the same flaky CI pipelines as engineers in Austin or Seattle. Same CS fundamentals, often the same open source contributions on their GitHub. What differs is cost of living, not competence.

A senior backend engineer with eight or more years of production experience in Prague costs less to contract than a mid level engineer in San Francisco. Not because the Prague engineer is less skilled. Because rent, healthcare, and daily expenses in Prague don't require a Bay Area paycheck to feel comfortable.

Distributed hiring stopped being an experiment

This isn't a workaround anymore, it's how competitive engineering orgs already operate. GitLab runs engineering across more than 60 countries. That's not a risk they tolerate, it's a hiring strategy they built deliberately, because the talent pool outside any single city or country is deeper and the working hour overlap with EU and US teams is workable.

Central Europe specifically sits in a useful overlap window, roughly four to six hours ahead of US Eastern. A morning stand up in Prague can still land in the afternoon for a New York team. Compare that to a twelve hour gap with talent in other low cost regions, where async communication becomes the default instead of a choice.

Where the fear actually comes from

The hesitation usually isn't really about skill. It's leftover scar tissue from outsourcing horror stories: ticket factories, communication gaps, code dumped over a wall with no context. That model is real and it does fail. But contracting a senior engineer directly, with a real interview process, real code review, real presence in your Slack during your hours, is a different thing entirely. Conflating the two is how good budget decisions get blocked by bad past experiences that have nothing to do with the person actually in front of you.

What actually changes when you widen the market

You're not lowering your bar when you hire a senior contractor from Central Europe. You're removing an artificial ceiling on how far your existing rate goes. The same dollar amount that gets you a mid level engineer in a US metro can get you someone senior enough to own an incident, mentor two juniors, and ship without hand holding.

The question worth asking in your next budget review isn't whether you can afford another senior engineer. It's why you're only pricing that question against one labor market.

The Six-Month Req: What an Empty Senior Seat Actually Costs You

Jerry Kasem — Mon, 03 Aug 2026 22:35:00 +0000

Open the budget spreadsheet. Somewhere there's a tidy line for 'recruiter fees avoided' next to a senior engineering seat that's been empty for six months. That number looks great in a board deck. It also hides almost everything that's actually costing you money.

Here's what nobody puts on a slide: the team already absorbed the gap. Two mid-levels are quietly doing the work of a senior who isn't there yet. Code review slows down because the person who used to catch the tricky edge cases three times a week is a hypothetical candidate somewhere in your ATS, not a person on your team. Architecture decisions that needed a senior sanity check get made anyway, because the roadmap doesn't wait for headcount.

Six months is long enough for that gap to become structural. Technical debt that a senior would have flagged in week one instead compounds for two quarters. On-call rotation gets thinner and the people left in it start quietly checking LinkedIn. Your best remaining senior, the one carrying two roles' worth of context, becomes a flight risk right when you can least afford to lose them.

Then there's the interview fatigue on your own team. Every panel, every take-home review, every 'let's regroup on the pipeline' meeting is time your senior engineers aren't shipping. Six months of that isn't neutral, it's a second, invisible headcount cost stacked on top of the one you're trying to fill.

Most engineering leaders respond to a stalled req by turning up the volume: more job boards, more sourcing, faster screens. That treats the symptom. The actual constraint is usually geography. If your search is bounded to one metro or one time zone, you're fishing in a pond that every other company in that metro is also fishing in, for the exact same profile, at the exact same time.

The market data backs this up in a way that's easy to ignore until you look at it directly: remote roles now pull roughly 4x the applications of equivalent on-site roles. That's not a vanity stat, it's a direct signal about where the depth of the candidate pool actually is. If you're still running a senior IC search as local-only, you're not choosing between a big pool and a small one, you're choosing a shallow one and hoping it's deep enough.

Widening the search doesn't mean lowering the bar. It means treating 'where the candidate lives' as a separate variable from 'can this person do the job.' Contract-to-hire senior engineers based in Central Europe, for example, often come with EU-grade engineering rigor, English fluency built through years of client-facing work, and enough overlap with US time zones to run real-time standups, without the six-month vacancy tax eating your roadmap alive.

The question worth asking isn't 'how do we fill this req faster with the same pipeline.' It's 'what is this seat actually costing us every month it stays empty, and is our search radius the reason it's still empty.' Most leaders can answer the first question. Very few have actually run the math on the second.

Your Senior Req Has Been Open Four Months. A Fourth Sourcing Channel Won't Fix It.

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

Four months ago you opened a req for a senior engineer. Since then you've added a second agency, turned on a job board you'd never used, and told your recruiter to "cast a wider net." The pipeline looks busier. The role is still open.

Here's the uncomfortable diagnosis: this was never a volume problem. It's a pool problem, and no amount of extra sourcing fixes a pool that's the wrong shape.

Why more channels don't help

Every sourcing channel you're likely using, LinkedIn Recruiter, referrals, a new agency, a job board, is searching the same finite set of people: senior engineers in your metro area or willing to relocate to it. That set doesn't grow when you add a channel. You're just running more queries against the same small population, most of whom are already employed, already mid-interview somewhere else, or simply not interested in uprooting their life for your offer.

Add up the constraints on a truly senior hire: 8+ years, strong system design judgment, the ability to make calls without hand-holding, and willingness to move for a comp package that competes with what they already have. In most US metros, that's a tiny slice of people. You are not short on sourcing effort. You are short on candidates who exist in the pool you've drawn.

The part nobody says out loud

A fourth channel gives you the feeling of progress: more resumes, more screens, more activity on the dashboard. But activity isn't the same as expanding the actual number of qualified, available people. If the pool is capped at 200 people in a 50-mile radius, three more channels are just 200 people searched three more ways.

Meanwhile the skill you actually need, deep technical judgment at the senior level, has never been geographically bound. The engineer who can own your system design decisions doesn't need to live near your office to do that well. Companies that have internalized this aren't running a novel experiment: GitLab operates across 60+ countries and has built senior engineering functions entirely on that premise.

What actually moves the needle

If your req has been open past 90 days, the honest question isn't "which channel haven't we tried." It's "which pool are we drawing from, and is it big enough to contain the person we need." For most companies still hiring locally-first for senior roles, the answer is no, and it was no on day one.

This isn't an argument for lowering your bar. It's an argument for widening the map you're searching. Senior engineers who can operate independently, communicate async, and own outcomes exist well outside your commuting radius, and often outside your borders entirely. Central European engineering markets in particular have produced deep benches of exactly this profile: strong CS fundamentals, English-fluent, used to distributed team structures, and priced sanely relative to a market where remote senior roles now carry a median comp around $142K.

Four months of silence on a req isn't bad luck or a weak recruiter. It's a signal. The pool you're searching was never going to contain enough of the right people, no matter how many times you search it. The fix isn't another channel. It's a different map.

Your Senior Engineering Req Has Been Open Four Months. Sourcing Isn't the Problem.

Jerry Kasem — Thu, 30 Jul 2026 20:45:25 +0000

If you've had a senior engineering role open for months and the candidates from Prague, Warsaw, or Bucharest look sharp on paper but the process keeps stalling, or the hire doesn't stick past month three, it's tempting to blame sourcing. It's not sourcing.

Remote roles draw roughly four times the applications of onsite ones. You have candidates. What you don't have is a plan for the four things that quietly break when a US company brings on a senior contractor in Europe. None of them show up in a resume review. All four show up in month two or three, right when you can least afford it.

1. IP assignment left implicit

US contracts often assume 'work made for hire' transfers ownership automatically. That doctrine doesn't travel well. In much of Central Europe, IP and moral rights law requires an explicit, written assignment referencing the contractor's home jurisdiction, not just a line borrowed from a US template. If your contract says 'all deliverables belong to Client' and stops there, you may not have clean title to the code your contractor wrote. Fix it before the first commit: name the governing law, name the assignment explicitly, get it signed before day one, not during offboarding.

2. Misclassification risk

The instinct is to treat a senior contractor like a de facto employee: daily standups at fixed hours, company laptop, exclusivity, folded into the same onboarding as your W2 staff. That pattern is exactly what triggers misclassification and permanent establishment risk, on both the US side and the contractor's local side. A contractor engaged like an employee starts looking like an employee to a tax authority. Scope the work as deliverables and outcomes, not hours and presence. Skip exclusivity clauses. Keep the engagement structurally different from your FTE onboarding, even when the day-to-day work looks identical.

3. Timezone overlap oversold

'Six hours of overlap' sounds great on a sourcing call. In practice, once you subtract actual working patterns, focus blocks, and the fact that nobody wants a 7 or 8pm standup twice a week, real synchronous overlap is often two to three hours. That's fine, if you planned for it. It's a problem if your team assumed six hours of live pairing and got two. Before the offer goes out, map actual calendar hours against your team's real meeting cadence, not theoretical CET-to-EST math, and decide upfront which interactions genuinely need to be synchronous.

4. No structured trial

Seniority gets used as an excuse to skip the ramp-up plan: 'they're senior, they'll figure it out.' That's how you end up finding out about a fit problem at month six instead of week six. Structure a real 30-60-90 day trial with specific technical and collaboration milestones, written down, reviewed on schedule. This isn't about distrust. It's the same discipline you'd apply to a senior FTE hire, just made explicit because there's no shared office to surface problems informally.

The actual fix is upstream

None of these four are hard problems. They're just decisions that are easy to leave implicit when the contract feels like a formality and the hire feels urgent. The pattern holds across stalled or failed senior EU contractor hires: the problem was rarely the engineer. It was that IP assignment, classification, overlap, and trial structure got treated as details to sort out later instead of terms to settle before the offer went out.

If your req has been open a long time, the fix isn't a new sourcing channel. It's going back to those four decisions and making them explicit, in writing, before you make another offer.

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.