Outcome-Based Hiring Requirements

technical hiring guide moving beyond hard requirements a comprehensive guide for recruiters and hiring managers executive summary this guide demonstrates why overly specific and rigid job requirements limit your talent pool, create unintended bias, and cause you to miss exceptional candidates by shifting from laundry lists of prerequisites to outcome based requirements, you'll attract more diverse, qualified candidates while still ensuring they can deliver results research shows women apply when they meet 56% of requirements, while men apply when meeting a similar threshold, but women apply to 20% fewer jobs than men overall additionally, a 2023 harvard business review analysis found that 88% of mid level jobs required a bachelor's degree, yet only 16% of workers in those roles actually had one the problem with hard requirements why "10 years required" excludes great candidates when you write "10 years of experience required," you're creating an artificial barrier that screens out candidates with 8 or 9 years who may be perfectly qualified for your role these candidates self select out of the process before you ever see their resume you lose people who've accomplished in 7 years what others take 12 years to achieve, and you miss career changers who bring valuable cross industry perspectives overly specific job specs contribute to narrowing the potential candidate pool significantly consider the difference between these two approaches the first states "10+ years of python development required," which immediately excludes anyone with fewer than ten years, regardless of their actual capability a better approach describes "extensive experience building and maintaining production python applications," which allows candidates to self assess based on actual capability rather than arbitrary timelines the most effective approach focuses on outcomes "demonstrated ability to architect scalable backend systems that serve millions of users " this final version tells candidates what they need to be able to accomplish, leaving room for various paths to have developed that capability the gender gap in application rates when job descriptions contain vague guidance, only 6% of qualified women applied for expert level jobs, compared with 22% of qualified men however, when researchers provided clear guidance on required qualifications with specific thresholds, 29% of women from the applicant pool applied this matters enormously because women are 16% more likely to be hired once they apply, meaning they're often more qualified than their male counterparts women account for about 42% of the workforce, yet the share of women in senior leadership positions is 32%, and at the c suite level, female representation drops to 25% you're losing top talent before they even enter your pipeline the "laundry list" problem job descriptions with 15 20 requirements create multiple problems simultaneously first, no one actually meets all the criteria—you're describing a unicorn that doesn't exist second, the sheer volume creates cognitive overload where candidates can't identify which requirements truly matter third, some job descriptions include excessive criteria that significantly shrink the available talent pool finally, different demographic groups respond differently to lengthy requirement lists, amplifying existing biases in your hiring process consider this example of a problematic job posting requirements 10+ years java experience, 8+ years spring framework, 7+ years microservices architecture, 5+ years kubernetes, expert in aws, azure, and gcp, experience with python, go, and rust, machine learning background, phd in computer science preferred, published research papers, open source contributions, technical leadership of 20+ person teams, experience in fintech, healthcare, and e commerce, fluent in english, spanish, and mandarin this posting describes someone who doesn't exist even if they did, they'd be overqualified and bored in most roles the candidate who has spent 10+ years deep in java probably hasn't also mastered three other programming languages to an expert level someone with a phd and published research papers has likely been in academia rather than leading 20 person teams in multiple industries the solution outcome based requirements what are outcome based requirements? instead of listing credentials and years of experience, describe what the person needs to accomplish and the problems they need to solve the principle is simple focus on the destination, not the specific path taken to get there this approach respects that there are many valid routes to developing capability, and it allows candidates to self assess based on what they can actually do rather than the specific technologies they've used or the number of years listed on their resume how to write outcome based requirements for each requirement you're tempted to write, ask yourself three questions first, why do we need this—what problem does this solve? second, what outcomes does this enable—what will the person accomplish? third, what evidence would demonstrate capability—how will we know they can do it? the structure should describe what needs to be accomplished, paint a picture of what success looks like with measurable indicators of achievement, and outline the key activities and responsibilities the person will handle day to day real world examples example 1 backend engineer the credential based approach lists requirements like "8+ years of python experience required, 5+ years with django required, bachelor's degree in computer science required, experience with postgresql required, knowledge of redis required, aws certification preferred " this tells candidates what boxes to check but says nothing about what they'll actually do or achieve an outcome based approach transforms this completely start by describing what they'll be responsible for designing and building apis that reliably handle 100k+ requests per minute, optimizing database queries to maintain sub 100ms response times under load, architecting systems that scale horizontally as user demand grows, and collaborating with frontend teams to create seamless user experiences then paint a picture of what success looks like systems they build maintain 99 9% uptime api endpoints they design are intuitive for other developers to use their code is well documented and easy for teammates to maintain they can debug production issues quickly and implement preventive solutions finally, provide technical context without making it a barrier "our stack includes python, django, postgresql, redis, and aws you don't need to be an expert in all of these, but you should be comfortable learning what you don't know and applying similar concepts you've used in other technologies " example 2 frontend engineer the problematic version demands "7+ years react experience required, 5+ years typescript required, expert in css, sass, and styled components, experience with next js, gatsby, and remix, webpack configuration expertise, accessibility (wcag 2 1) certification, design background required, portfolio with 10+ projects " this is exhausting to read and impossible to fully satisfy the better approach focuses on outcomes the engineer will be responsible for building responsive, accessible interfaces that work flawlessly across devices, creating reusable component libraries that help the team ship features faster, optimizing page load times and runtime performance for excellent user experience, and collaborating with designers to transform mockups into pixel perfect implementations success means the interfaces they build are intuitive and accessible to all users their components are documented and widely adopted by the team pages they optimize load in under 2 seconds on 3g connections they catch and fix accessibility issues before they reach production the technical context acknowledges reality "we primarily use react and typescript experience with these specific tools is valuable, but if you've built complex uis with vue, angular, or other modern frameworks and are excited to work with react, we want to talk with you " example 3 devops/platform engineer instead of requiring "10+ years devops experience required, expert in kubernetes required, terraform certification required, experience with jenkins, circleci, and github actions, aws solutions architect certification required, experience with prometheus, grafana, and elk stack, scripting in bash, python, and go, on call experience required," describe the actual work this person will be responsible for reducing deployment friction so engineers can ship code confidently and frequently, building observability systems that help teams quickly diagnose and resolve issues, designing infrastructure that scales automatically with demand, and creating self service tools that empower developers while maintaining security success looks like deployment time decreasing from hours to minutes, teams being able to debug production issues using the monitoring you've built, infrastructure costs optimizing automatically based on usage patterns, and new engineers being able to deploy their first change within their first week acknowledge your technical context while remaining open "we use kubernetes, terraform, and aws if you've solved similar problems with different tools (docker swarm, cloudformation, azure, etc ), we're interested in your problem solving approach and willingness to work with our stack " example 4 data engineer the credential heavy approach demands "8+ years data engineering experience required, master's degree in computer science or related field required, expert in spark, hadoop, and flink required, 5+ years sql experience required, python and scala proficiency required, experience with airflow, dagster, and prefect, aws certified data analytics required, experience with snowflake, redshift, and bigquery " this screens out people who can do the job but haven't touched every tool in your specific ecosystem focus instead on what needs to happen this person will build data pipelines that reliably process billions of events daily, design data models that make it easy for analysts to answer business questions, optimize queries and storage to reduce compute costs while improving performance, and ensure data quality so downstream teams can trust the numbers they see success means pipelines they build process data accurately with minimal failures data models they design reduce query times from minutes to seconds their documentation enables analysts to find and use data independently they identify and fix data quality issues before they affect business decisions provide context about your stack "our data infrastructure includes spark, airflow, and snowflake experience with these specific technologies is helpful, but if you've built reliable, large scale data systems with other tools, we value that experience we care more about your approach to solving data challenges than specific technology expertise " example 5 engineering manager the traditional requirements read like "12+ years of software engineering experience required, 5+ years managing teams of 10+ engineers required, mba or advanced degree required, experience managing distributed teams across 3+ time zones, technical expertise in java, python, and javascript required, experience with agile, scrum, and kanban required, budget management experience of $5m+ required, experience in enterprise b2b saas required " this describes a very specific career path that excludes many capable leaders reframe around responsibilities building and leading a team that consistently delivers high quality software on schedule, creating an environment where engineers grow their skills and advance their careers, making technical tradeoffs that balance short term needs with long term maintainability, and partnering with product and design to define roadmaps that serve user needs success means the team ships features that users love and that work reliably at scale engineers on the team develop new skills and take on increasing responsibility the manager removes blockers so the team can focus on high impact work team members are engaged, productive, and choose to stay with the company describe helpful background broadly "strong technical foundation (you've written production code and understand engineering tradeoffs), experience coaching others to grow their skills, and a track record of building high performing teams if you've led teams in different contexts (startup, scale up, enterprise) or domains (product, infrastructure, data), that breadth of experience is valuable " the "core vs nice to have" framework how to structure requirements break your requirements into three tiers that help candidates understand what matters most while being honest about what you're willing to teach tier 1 core capabilities (must have) these are the 3 5 things someone absolutely must be able to do to succeed in the role frame them as outcomes, not credentials for example, core capabilities for a backend engineer might include building apis that handle production traffic reliably and efficiently, debugging complex issues in distributed systems, and writing maintainable code that teammates can easily understand and modify notice that none of these specify years of experience or particular technologies—they describe fundamental capabilities tier 2 helpful context (good to have) these are things that accelerate someone's impact but can be learned on the job frame them as experience that helps rather than absolute requirements for the same backend engineer role, helpful background might include experience with your tech stack (python, django, postgresql, redis), understanding of message queues and event driven architectures, and familiarity with cloud infrastructure (aws, gcp, or azure) notice the parenthetical acknowledgment that aws, gcp, or azure are equivalent for your purposes—you care about cloud experience, not certification in your specific provider tier 3 growth areas (can learn) these are things you're explicitly willing to teach or that the person can learn on the job being upfront about this is valuable because it tells candidates they won't be expected to know everything on day one for example, they'll have the opportunity to learn your specific deployment and observability tools, domain knowledge about your industry, and team processes and coding standards complete example full job posting senior backend engineer about the role we're looking for an experienced backend engineer to help us scale our platform to support millions of users you'll work on our core api that powers both our web and mobile applications, building features that directly impact user experience what you'll be doing your day to day work will involve designing and implementing apis that serve millions of requests daily, optimizing database queries and caching strategies for performance, and collaborating with frontend engineers to create seamless user experiences you'll also spend time debugging production issues and improving system reliability, as well as participating in code reviews and technical design discussions with the team what success looks like within your first three months, you'll be shipping features independently with minimal code review iterations you'll have improved the performance of at least one key endpoint, and you'll understand our architecture well enough to navigate the codebase confidently by six months, you'll be designing new apis and data models that teammates use as examples of good work you'll have mentored newer engineers and improved team practices you'll be identifying and solving problems before they become incidents within twelve months, you'll be a go to person for system design questions in your area you'll have led projects that meaningfully improved performance or reliability you'll be helping shape technical direction and team processes core capabilities you don't need to check every box, but you should have experience building and maintaining production apis serving significant traffic you should be able to write clean, maintainable code that teammates can easily work with you need skills in debugging complex issues in distributed systems, and you should be comfortable collaborating with cross functional teams helpful background these things will accelerate your impact but aren't required experience with python and django is valuable since we use these, but strong skills with ruby on rails, node js and express, or similar frameworks translate well understanding of postgresql or similar relational databases helps you ramp up faster familiarity with redis, message queues, or event driven systems means you'll recognize patterns we use experience with cloud platforms like aws, gcp, or azure gives you context for our infrastructure decisions you'll have the opportunity to learn we don't expect you to know everything on day one you'll learn our specific deployment and monitoring tools as you go you'll develop domain expertise in our industry through working with the team you'll pick up team practices around testing, code review, and documentation as part of your onboarding interview process we'll start with an initial conversation lasting about 30 minutes where we'll discuss your background and what you're looking for in your next role then we'll have a technical interview lasting about an hour where we'll work through a real problem similar to what you'd solve here next comes a system design discussion, also about an hour, where we'll design a system together and talk through tradeoffs after that, you'll have team fit conversations across 2 3 sessions where you'll meet potential teammates and can ask us anything we move quickly on offer decisions, typically within a week of final interviews we value diverse perspectives and encourage people from all backgrounds to apply, even if your experience doesn't match every point above if you've solved similar problems in different contexts, we want to hear about it addressing common concerns "but we really do need specific experience" the most common pushback sounds like this "we don't have time to train someone we need someone who knows kubernetes " this concern feels valid but rests on a faulty assumption skills with specific tools are often easier to teach than problem solving ability linkedin's 2023 future of recruiting report found that companies using skills first hiring expanded their talent pools by up to 20x someone who's mastered docker swarm can likely learn kubernetes in a matter of weeks, not months or years instead of requiring "5+ years of kubernetes experience required," try "experience orchestrating containers in production we use kubernetes, but if you've used other orchestration tools and are ready to learn our stack, we want to talk with you " this acknowledges your technology while remaining open to equivalent experience "we need a senior person who can hit the ground running" another common concern "this is a senior role they should already know our tech stack " but senior people became senior precisely because they excel at learning new tools quickly domain knowledge and architectural thinking matter far more than tool expertise mckinsey's 2024 "the state of organisations" report showed that employers with a broader skills based search strategy are 40% more likely to fill specialist roles fast the key is to focus on demonstrated ability to master new technologies rather than current knowledge of your specific stack a senior engineer who's worked deeply with postgresql will pick up mysql or mongodb quickly someone who's built large scale systems with aws will understand the concepts needed to work with gcp or azure "how do we filter candidates without specific requirements?" the concern here is practical "if we don't list requirements, we'll be flooded with unqualified applicants " but outcome based descriptions actually attract more qualified candidates while deterring those who can't do the work research shows that 91% of employers said soft skills are more important now than five years ago your interview process should assess capability, not screen for credentials a better approach involves describing the problems candidates will solve clearly, setting expectations about technical level through concrete examples, using your interview process to assess problem solving ability, and evaluating work samples or take home exercises this filters for capability rather than credentials how to make this change in your organization step 1 audit your current job descriptions begin by going through your existing job postings with fresh eyes count how many "required" items you list for each role then do something illuminating look at what percentage of your current successful employees actually met all these requirements when you hired them you'll likely find that many of your best performers wouldn't have passed your own filters finally, ask whether you're describing credentials or capabilities—are you listing what someone has done, or what they can do? step 2 identify core outcomes for each role in your organization, take time to define what problems this person will solve, what they will build or create, and how you'll measure their success this requires moving past the immediate "we need a java developer" impulse to think about why you need that capability what will they accomplish with java? what problems will they solve? this step often reveals that you're actually flexible on the specific technology as long as someone can achieve the outcomes step 3 rewrite using the framework now convert each requirement systematically take every credential requirement and ask what outcome it enables transform years of experience into demonstrated capability change specific technologies into problem solving approaches for example, "5 years of react" becomes "proven ability to build complex, performant user interfaces using modern component based frameworks " step 4 train your hiring team changing job descriptions is only the first step you need to ensure everyone involved in hiring understands why you made this change, how to assess candidates without credential checklists, what questions to ask to evaluate capability, and how to recognize transferable skills this often requires unlearning years of habit interviewers need permission to value someone's vue js experience when hiring for a react role, recognizing that the frameworks share core concepts and a skilled engineer can make the transition step 5 measure and iterate track your progress across multiple dimensions monitor application rates by demographic groups to see if you're attracting more diverse candidates assess the quality of candidates entering your pipeline—are you seeing people with relevant problem solving experience who might have been filtered out before? measure time to fill positions—outcome based descriptions often accelerate hiring by expanding your candidate pool track diversity of candidates interviewed and hired, and follow the performance of people hired under new criteria to ensure your new approach actually predicts success interview questions that assess capability since you're not using credentials as a filter, your interview process becomes even more important you need questions that reveal capability rather than checking boxes assessing problem solving ability instead of asking "how many years of experience do you have with x?" ask questions that reveal how someone thinks through challenges ask them to tell you about a complex technical problem they solved and what made it challenging walk through with them how they'd approach debugging a specific type of issue relevant to your work have them describe a system they designed, focusing on what tradeoffs they made and why these questions reveal problem solving process, not just familiarity with tools assessing learning agility since you're open to people learning your specific stack, you need to know they can learn quickly ask them to tell you about a time they had to learn a new technology quickly and how they approached it find out what technical topic they've taught themselves recently—this reveals whether they're actively curious and capable of self directed learning have them describe a project where they used tools they weren't familiar with and what their process was someone who's learned three frameworks can learn a fourth; someone who's never learned anything new will struggle regardless of what they know today assessing collaboration technical capability matters, but so does working effectively with others ask candidates to tell you about a time they disagreed with a technical decision and how they handled it find out how they make their code easy for teammates to understand and maintain have them describe how they've helped a teammate grow their technical skills these questions reveal whether someone will strengthen your team culture or create friction assessing impact ultimately, you're hiring someone to deliver results ask what's the most significant system improvement they've made and what the measurable impact was have them tell you about a time they made a technical decision that saved time or money ask them to describe a project where they had to balance technical excellence with business constraints these questions reveal whether someone focuses on impact or just on interesting technical challenges measuring success after implementing these changes, you need to track whether they're working application metrics tell you whether you're attracting more candidates look at whether your application rate is increasing per job posting, whether you're seeing more applications from underrepresented groups, and whether you're getting candidates with relevant problem solving experience even if their specific tool experience differs from your stack hiring metrics reveal whether you're actually filling roles better track whether you're filling roles faster, whether more candidates are accepting your offers, and whether new hires are performing well in their first 90 days and beyond retention metrics tell the longer term story monitor 90 day retention to see if new hires are staying, check performance ratings to ensure they're meeting expectations, and assess team satisfaction to gauge whether teams are happy with new hires if you're hiring people faster but they're leaving within six months, something isn't working key takeaways hard requirements exclude great candidates who could excel in the role but don't meet arbitrary thresholds a candidate with nine years of experience isn't meaningfully different from one with ten years, yet a hard requirement screens them out before anyone can assess their actual capability women are particularly impacted by overly specific requirements, applying to fewer roles even when qualified by making your requirements more outcome based and less credential focused, you create space for more women to see themselves in your roles and apply outcome based requirements work better because they focus on what someone needs to accomplish, not the specific path they took to develop that capability this respects that there are many routes to excellence and allows candidates with non traditional backgrounds to self assess accurately skills transfer across technologies and domains more easily than we typically assume someone who's mastered one modern frontend framework can learn another someone who's built reliable systems in one cloud provider can adapt to another what matters is the underlying capability, not the surface level tools your interview process matters more when you cast a wider net, so use it to assess problem solving ability, learning agility, collaboration skills, and focus on impact don't just ask about what tools someone has used—ask how they solve problems and learn new things finally, measure the impact of your changes to continuously improve your approach track not just whether you're filling roles, but whether you're attracting more diverse candidates, whether new hires are succeeding, and whether your changes are actually predictive of on the job performance additional resources recommended reading research by katherine coffman at harvard business school provides deep insights into application behavior across demographic groups the linkedin gender insights report offers current data on hiring patterns and outcomes the testgorilla state of skills based hiring report tracks how companies are moving away from credential based hiring and what results they're seeing tools to help job description bias analyzers like textio and ongig can flag problematic language in your postings before they go live skills assessment platforms such as codesignal and hackerrank for technical skills, or testgorilla for broader competencies, help you evaluate actual capability during the interview process structured interview guides ensure consistent evaluation across candidates, reducing bias and improving hiring decisions what to do next choose one role to pilot this approach rather than trying to overhaul everything at once rewrite that job description using the frameworks in this guide, paying particular attention to converting credentials into outcomes train your interview team on assessing capabilities versus credentials, ensuring everyone understands the why behind the change track metrics before and after so you can demonstrate impact then share results with stakeholders and iterate based on what you learn remember that the goal is not to lower your standards, but to evaluate what actually matters for success in the role by focusing on outcomes and demonstrated capabilities rather than credentials and arbitrary thresholds, you'll find better candidates while building a more diverse, innovative team