
How to Speak the Developer's Language
September 22, 2020 · SourceCon Digital ·
Speakers
About this video
Sourcing for engineering roles without understanding what engineers actually do leads to wasted funnels, mismatched hires, and candidates who can tell when a recruiter is reciting keywords instead of speaking their language. A survey of developers across multiple countries asked what mattered most when a recruiter reached out, and beyond salary, the highest-ranked factors were technical reputation, responsibilities and career growth, and the specific tech stack and methodologies in use. Those three topics require actual knowledge of the software world to discuss credibly.
Two paths to building that knowledge are laid out in detail:
- The labyrinth — the slow, painful route of learning on the job. It moves through a "tunnel vision" stage of sourcing on keywords alone, a "blind date" stage of matching job titles without understanding what the role actually involves, a beginner stage of relating technologies to each other without grasping depth of experience, and finally a skilled stage where sourcing focuses on what a candidate can actually do with a tool rather than how long they've used it.
- The highway — a faster, more deliberate route built on four stages: getting a high-level view of the business (what the company sells, who its clients are, what senior engineers say about it), understanding roles and responsibilities as they're actually defined inside that specific company (using career ladders, intake meetings, job ads, and conversations with senior technical staff), building a high-level grasp of the tools and methodologies in use and why they were chosen, and finally focusing on skills over tool history — what a candidate can build, configure, or troubleshoot, not just what's listed on a résumé.
Real hiring examples illustrate why keyword and title matching fail: a "senior solution architect" hired for hands-on engineering turned out to have no coding responsibilities in a similar-sounding role elsewhere, and a candidate with a year of Jenkins experience had never actually built a pipeline. A successful hire came from looking past an exact title match entirely, sourcing a web developer with adjacent skills and the right attitude for a test automation role in a hard-to-fill location.
Resources for building this fluency on an ongoing basis include company wikis and engineering ladders, technical blogs and Medium posts, YouTube channels that explain architecture and team structures visually, Twitter threads where developers discuss tools in plain language, and newsletters curated for recruiters trying to keep pace with a fast-moving field.
