How to find a software engineer.

Software engineering has the weakest relationship between job title and actual work of any field a recruiter sources. The same person is a Software Engineer at one company, a Member of Technical Staff at another, and a Python Developer at a third, and none of those titles tells you what they can build.

The compensating advantage is unique to this field: engineers leave a public, verifiable record of their work. Commits, published packages, conference talks, and technical writing all show what someone has actually done, and almost nobody sources against them. That trade — abandon titles, search evidence — is the whole strategy.

Job titles worth searching

Grouped by what the person actually does, because searching all64 at once produces a result set you cannot triage. Decide which group you need first — that decision does more for the search than any string below.

Where engineers actually are

The public work trail is what makes this role different. GitHub profiles carry both real code and a free-text location field, which is close to the filtered search LinkedIn used to permit and which almost no recruiter uses. Package registries — npm, PyPI, crates.io — go further, listing authors of code that other projects genuinely depend on.

Conference speaker lists and technical blogs identify the senior end of the market. An engineer who has given a talk or written up how they solved something has demonstrated both depth and the ability to explain it, which is much of what an interview is trying to establish. This population is small and rarely contacted.

One caveat worth knowing: Stack Overflow activity has fallen sharply since AI coding assistants became standard, so a thin recent answer history means very little now. Treat it as uninformative rather than as a negative signal, and weight GitHub and published work more heavily than community reputation metrics.

Boolean search strings

Written to be pasted as-is. Each one is built around an intent rather than a platform, since the useful question is what you are trying to find, not which site you happen to be on.

site:github.com ("{language}" OR "{framework}") location:"{city}" -jobs -awesome -tutorial

("staff engineer" OR "principal engineer" OR "senior staff") -"engineering manager" -jobs -hiring "{city}"

("speaker" OR "talk" OR "presented") ("{technology}") (conference OR meetup OR "tech talk") 2024..2026 -jobs

site:github.com ("maintainer" OR "core team" OR "committer") "{project}" -jobs

(site:npmjs.com OR site:pypi.org OR site:crates.io) "{keyword}" author

(site:dev.to OR site:hashnode.com OR site:medium.com) "{technology}" ("I built" OR "how we" OR "lessons from") -jobs

site:linkedin.com/in/ ("software engineer" OR "staff engineer") ("{language}" OR "{framework}") "{city}"

site:linkedin.com/advice/ intext:"Staff Engineer"

site:stackoverflow.com/users "{city}" ("{language}" OR "{framework}")

Mistakes that cost the most time

1. Reading 'Senior' as a level

   Senior is the most inflated title in the industry. At a small company it can mean three years of experience; at a large one it is a substantial bar reached after seven or more. The informative terms are the ladder ones — Staff, Senior Staff, Principal — which are used consistently where they exist. Calibrate against the company, not the word.

2. Assuming manager outranks engineer

   At most large technology companies the individual-contributor ladder runs parallel to management, and a Staff or Principal Engineer typically has broader scope than a first-line Engineering Manager. Recruiters who treat manager titles as automatically more senior routinely mis-level candidates and lose them by pitching down.

3. Searching titles instead of evidence

   Software engineering is the one family that leaves a rich public work trail — commits, packages, talks, posts. Filtering by job title in this field discards that advantage and lands you in the most competitive part of the market. Search what someone has built and the competition drops away.

4. Treating stacks as interchangeable

   A frontend engineer is not a backend engineer with different syntax, and an iOS engineer does not become an Android engineer over a weekend. Framework proximity matters too: React to Vue is a short step, React to Angular much longer. Requiring an exact framework match is usually over-filtering, but ignoring the stack entirely wastes everyone's time.

5. Cold-messaging maintainers without reading their work

   Open source maintainers are the highest-signal candidates available and the most contemptuous of generic outreach, because they receive a great deal of it. A message referencing the specific project and a real problem it solves gets a reply; a templated one confirms you did not look.

6. Ignoring the location field on GitHub

   GitHub profiles carry a free-text location that most engineers fill in and few recruiters search. It is one of the few places where a technical work trail and a location signal sit on the same page, which makes it the closest thing to the filtered search LinkedIn used to allow.

Common questions

What job titles should I search for when hiring a software engineer?

More than 'Software Engineer', which many engineers do not use. 'Software Developer' is the same role and is more common in Europe, so searching only one halves your results in some markets. Beyond the generic terms, engineers frequently title themselves by stack (Frontend, Backend, Full Stack), by language (Java Developer, Python Developer, .NET Developer), or by platform (iOS Engineer, Android Developer). At larger companies you will also find internal terms like Member of Technical Staff or SDE. Which group you search depends on whether the role needs a specific stack or general engineering ability.

What is the difference between Senior, Staff, and Principal Engineer?

They are levels on the individual-contributor ladder, and only the latter two are used consistently. Senior has inflated to the point of being nearly uninformative — it can mean three years at a small company or seven-plus at a large one. Staff sits above Senior and typically implies influence beyond a single team; Senior Staff and Principal extend that to organisation-wide scope. Importantly, this ladder runs parallel to management, so a Staff or Principal Engineer often has broader scope than a first-line Engineering Manager. Treating manager titles as automatically more senior is a common and costly mis-levelling.

How do I find software engineers on GitHub?

GitHub is the strongest sourcing source for this role because profiles combine actual code with a free-text location field, which lets you filter on evidence rather than self-description. A search like site:github.com with a language or framework plus a location term returns engineers who have demonstrably written that code. Exclude 'awesome' and 'tutorial' to strip out the curated list repositories that otherwise dominate results. Package registries such as npm, PyPI, and crates.io work similarly, listing authors of code that other people actually depend on.

Does LinkedIn X-ray search still work for finding developers?

Not in its classic form. LinkedIn removed titles and locations from what search engines can index, so site:linkedin.com/in with a title and city no longer returns a usable filtered list. The workable substitute is searching LinkedIn's advice articles, which are still indexed and carry named contributors with their job titles. For engineers specifically this matters less than it does elsewhere, because the public work trail — GitHub, package registries, conference talks, technical writing — is richer than anything LinkedIn offered, and considerably less contested.

How should I approach open source maintainers and senior engineers?

With evidence that you looked at their work. Maintainers and well-known engineers receive a high volume of generic outreach and discard it reflexively, so a templated message actively signals that you did not read anything they wrote. Reference the specific project, the problem it solves, and why your role connects to it. This population is rarely actively looking, which means the approach has to offer something concrete — technical problem, scope, team — rather than an invitation to a conversation about opportunities.