Loading
Visitar URL original
Jobs by skill
Browse open remote developer roles by stack. Apply directly, or create a profile and get matched to roles that fit.
React is the default for product interfaces, so the pool is huge and the quality range is just as wide. The hard part is not finding someone who knows React. It is finding someone who knows when not to reach for it, and how to keep a large component tree from turning into a maintenance problem.
Next.js developers work at the seam between frontend and backend, which is exactly where projects tend to get stuck. The App Router and the caching model changed enough recently that experience from two years ago does not carry over cleanly, so a fresh portfolio matters more here than in most stacks.
Python covers web backends, data pipelines, and the glue around machine learning, so the title alone tells you almost nothing. Pin down which job you are hiring for first, because a strong data engineer and a strong API engineer rarely live in the same person.
Node.js is the natural choice for a team that wants one language across the whole stack. The risk is hiring someone who writes frontend-flavored backend code, which holds up fine until it meets real concurrency or a long-running job and then falls over.
TypeScript is table stakes now, so the real question is depth. A weak TypeScript developer types everything as any and moves on. A strong one uses the type system to make broken states impossible to represent, which removes whole categories of bug before they ship.
AI engineering is the newest and noisiest category, full of people who have run a tutorial and far fewer who have shipped something that holds up. The distance between a convincing demo and a reliable production feature is where almost all of the cost and risk sits.
Go is the language of infrastructure, so the strongest part of the pool sits in backend services, networking, and the cloud native world (Kubernetes, Docker, and everything built around them). The syntax is small and easy to pick up, which cuts both ways: plenty of people list Go after shipping one microservice, and surface familiarity looks a lot like depth on a resume. The real risk is concurrency. Goroutines and channels make it trivial to write code that passes tests and then leaks or races under load, and spotting who actually understands that is the whole game.
Rust has a small, self-selected pool, so the average candidate is stronger than most languages, but that cuts both ways. A lot of people who list Rust like the language more than any problem they have solved with it, and enthusiasm is not the same as having shipped and maintained a service in production. The real risk is not skill, it is fit: teams reach for Rust when a boring backend language would have done the job, then pay for it in hiring time and slow iteration. Decide whether you actually need Rust (real performance or memory constraints, systems work, WASM) before you filter for it.
Java has one of the deepest talent pools in backend, but it is also the most stratified. Ten years of Java can mean a modern Spring Boot service with records and virtual threads, or a legacy application server monolith the person mostly configured rather than wrote. The real risk is mistaking tenure for depth, since the ecosystem rewards people who can operate heavy frameworks without ever understanding what the JVM is doing underneath. Pin down which era and which stack the experience is actually in before you get excited about the years on the resume.
PHP still runs a large share of the web, so the pool is enormous, but it splits hard down the middle. On one side are people whose experience is mostly WordPress themes and legacy PHP 5 maintenance. On the other are engineers writing typed, tested Laravel or Symfony against modern PHP 8. Those two skills share a language and almost nothing else, so the real risk is hiring the first when the job needs the second.
Django has a deep, mature pool, but most of it clusters at the tutorial end: people who scaffolded a CRUD app, leaned on the admin, and never had to make the ORM behave under load. The engineers you actually want are the ones who have run Django REST Framework in production and know where it gets slow. The real risk when hiring here is the ORM. It makes the easy things trivial and quietly hides N+1 queries, missing indexes, and migrations that lock a live table until someone profiles the thing in staging.
Vue has a smaller pool than React, but the people in it tend to be productive fast because the framework hides a lot of the wiring. That is also the risk. The version and API split is the thing to pin down first: a lot of resumes say "Vue" but mean Vue 2 with the Options API, and moving that person onto a Vue 3 Composition API and TypeScript codebase is a real ramp, not a formality. Plenty of "Vue" work is actually Nuxt, so check whether the candidate understands what the framework is doing for them or just follows its conventions.
Angular splits the pool in two, and the split matters. AngularJS (the 1.x line) and modern Angular (2+, now signals and standalone components) share a name but not much else, so a decade of "Angular" on a resume can mean an obsolete skill or a current one. The framework is opinionated and heavy, which is why it holds up well in large enterprise apps and rarely shows up in startups, so the strongest candidates come out of banks, telcos, and internal tooling teams. The real risk is hiring someone fluent in old patterns who has not kept up with where the framework went.
Flutter gets you one codebase for iOS and Android that actually looks native on both, so the pool skews toward people who ship consumer apps fast. The gap shows up at the platform edges. A lot of Flutter developers are strong with widgets and Dart but reach for the native layer only when forced, and that is exactly where real apps get hard: background tasks, push notifications, deep links, and any feature that needs a platform channel or a plugin that nobody maintains. The other risk is state management, where teams either under-engineer with raw setState or cargo-cult a Bloc setup they cannot explain.
React Native pulls from the large React pool, which is a trap: writing the JavaScript layer is the easy 70 percent, and plenty of web React developers put it on a resume after one Expo demo. The real job starts at the native boundary, the build toolchains, and the two app stores. Weak candidates ship fine in the simulator and then stall the moment a Gradle build breaks, a native module needs linking, or an iOS release gets rejected. The gap between "runs on my machine" and "shipped and stable on a $120 Android phone" is where the cost lives.
Swift is a narrower pool than web, and it splits in a way that catches people out. Most recent candidates came up on SwiftUI and can build screens fast, but plenty have never touched UIKit, which is still holding up the majority of shipping apps. The real risk is hiring someone who can assemble a demo but has not dealt with the parts that make iOS hard: App Store review, memory and retain cycles, and Apple's concurrency model.
Most Kotlin hiring is really Android hiring, so the pool skews toward mobile engineers who also carry years of legacy Java. That is a strength when you need someone who can navigate an old codebase, and a trap when you assume modern Kotlin idioms come standard. Server-side Kotlin (Ktor, Spring) and Kotlin Multiplatform are much thinner pools, so if that is the job, screen for it directly instead of trusting the keyword. The real risk is hiring someone who writes Java in Kotlin syntax and never touches coroutines, null safety, or the type system in a way that earns the language.
DevOps is a title stretched across very different jobs, from someone who wrote a few GitHub Actions workflows to someone who keeps a Kubernetes cluster alive under real load. The pool looks deep, but a lot of it is people who have only ever worked on top of managed platforms and have never had to reason about the layer underneath. Cloud knowledge also does not transfer as cleanly as resumes suggest: deep AWS experience does not make someone productive on GCP or Azure in week one. The real risk is hiring a capable CI script writer when what you actually need is someone who can own production and be woken up when it breaks.
Data engineering is where a lot of "senior" titles hide people who have only ever written SQL against a warehouse someone else built. The pool that can actually design a pipeline, pick sane storage, and reason about cost is much thinner than the resumes suggest. The real risk is hiring someone fluent in the tools (Airflow, Spark, dbt) who has never owned the ugly parts: late-arriving data, schema drift, and a backfill that has to run without double-counting. Pin down whether you need pipeline plumbing, warehouse modeling, or streaming, because those are three different people more often than not.
Solidity is a small pool with a wide honesty gap. Plenty of people list it after a tutorial or a hackathon, but the ones who have shipped contracts that hold real money, and lived through an audit, are rare and know it. The risk here is not slow features, it is a single bug that drains funds with no undo, so hiring for confidence over caution is the trap. Ask what network and standards they actually deployed to, because ERC-20 on a testnet and a live DeFi protocol on mainnet are different jobs.
Rails still runs a lot of revenue, so the demand is real, but the pool has thinned as newer grads chase JavaScript and Go. That works in your favor and against you: the people who stayed tend to be senior and pragmatic, but juniors are scarce and salaries at the top end are not cheap. The bigger risk is inheriting a large Rails app that has drifted into fat models, callback spaghetti, and a test suite nobody trusts, and hiring someone who only knows how to add more of the same.
The .NET pool is deep in enterprise, finance, healthcare, and Unity game shops, so you will find plenty of people who have shipped real systems. The catch is the split between modern .NET (Core, cross-platform, running on Linux) and the older .NET Framework world of Windows servers and WebForms. A lot of resumes say ".NET" but mean a decade inside one Microsoft shop doing CRUD, and that experience does not always travel. The real risk when hiring is mistaking long tenure for range.
Hiring instead? Hire developers by skill.