Industry Guide HR & Talent
When candidates can generate code instantly, writing code is a weaker signal. Assess what still separates strong engineers: debugging, reviewing AI output, design trade-offs and judgment.
Software engineers now write much of their code with AI assistants and coding agents. That has broken a familiar hiring pattern. A take-home exercise that once showed whether someone could build a small feature now mostly shows whether they can prompt a tool to build it. An algorithm quiz completed without AI shows a skill the job no longer uses in the same way.
Skills-based hiring for developers still works, but the skills worth measuring have shifted. The question is less "Can this person write the code?" and more "Can this person decide what should be built, spot what is wrong with generated code, fix it, and explain the trade-offs?"
This guide shows SaaS companies how to define role outcomes, design realistic work samples where AI use is allowed, assess the skills that now matter most, and score candidates consistently and fairly.
CoderPad's State of Tech Hiring 2026, a global survey of about 650 developers, recruiters and hiring leaders run by a company that sells assessment software, illustrates how unsettled practice is:
Identity and authenticity have also become hiring issues in their own right. When LinkedIn announced its Hiring Assistant 2 on September 29, 2026, it highlighted candidate verification signals and cited a survey finding that 39% of talent acquisition professionals say their top challenge is not knowing whether a candidate or their skills are real.
The practical conclusion: banning AI from assessments tests a way of working your engineers no longer use, while allowing it without changing the assessment tests very little. The answer is to redesign what you assess.
Skills-based hiring starts with what the person must achieve, not with years of experience or a list of frameworks. Write a short role scorecard with the hiring manager:
| Element | Example for a mid-level backend engineer at a B2B SaaS company |
|---|---|
| Six-month outcomes | Owns the billing service's reliability; ships two customer-facing API improvements with tests and documentation |
| Core competencies | Debugging production issues; reviewing code, including AI-generated code; data modeling; API design; written communication |
| Context | Multi-tenant architecture; on-call rotation; small team with high autonomy |
| Tools | AI coding assistants permitted and expected; existing stack named |
| Not required | A specific degree; years with a single framework |
Each competency on the scorecard should map to at least one stage of the assessment. If a competency is not assessed anywhere, it is not really part of the hiring criteria.
Choose exercises that reflect the job as it is now done. Several formats work well together:
| Format | What it reveals | AI policy |
|---|---|---|
| Code review of an AI-generated pull request | Ability to spot bugs, security issues, missing tests and poor design | AI allowed; the point is judgment |
| Debugging exercise in a small realistic codebase | Systematic diagnosis, reading unfamiliar code, verifying fixes | AI allowed; observe how it is used |
| Paired feature extension | Collaboration, scoping, use of tools, testing habits | AI allowed; discuss choices aloud |
| System design discussion | Trade-offs, data modeling, failure modes, cost awareness | Usually conversational, without tools |
| Short written explanation | Communication with non-engineers and future maintainers | AI allowed, but candidates must defend it live |
Keep the total candidate time proportionate. Long unpaid take-home projects disadvantage people with caring responsibilities or existing jobs, and they are easy to outsource to an agent. A live, time-boxed session of 60 to 90 minutes, combined with a design conversation, usually reveals more.
The following exercise is invented for illustration.
Candidates receive a pull request that adds a discount-code feature to a sample subscription billing service. An AI assistant generated it. The code compiles and the happy-path test passes. It also contains four planted issues: discounts can be applied twice through a race condition, a tenant identifier is missing from one database query, error messages leak internal details, and there is no test for expired codes.
The candidate has 45 minutes, with AI tools available, to review the pull request as if for a colleague, then discuss it with an engineer. Strong candidates find most of the issues, rank them by severity, explain how they would verify each fix and comment respectfully. Weaker candidates either accept the code because it passes tests or rewrite it entirely without explaining why.
The exercise tests exactly the skills CoderPad's respondents valued most, and an AI assistant alone will not reliably find the multi-tenant issue without the candidate understanding why it matters.
Use a rubric with behavioral anchors, so interviewers score observed behavior rather than overall impressions:
| Competency | 1: Concern | 3: Meets the bar | 5: Strong |
|---|---|---|---|
| Debugging | Changes code at random; relies on AI suggestions without checking | Forms hypotheses, uses logs and tests to narrow the problem | Finds root cause quickly, explains it and prevents recurrence |
| Reviewing AI output | Accepts output that passes tests | Finds functional bugs and missing tests | Also finds security, tenancy and maintainability issues; prioritizes them |
| System design | Lists technologies without trade-offs | Proposes a workable design and explains main trade-offs | Anticipates scale, failure, cost and data-integrity issues |
| Tool use | Cannot work without AI, or refuses it entirely | Uses AI for speed and checks results | Uses AI deliberately, knows its limits, explains when not to use it |
| Communication | Unclear or defensive | Clear explanations and reasoning | Adapts explanation to audience; invites challenge |
Watching how a candidate uses AI is informative. Some assessment platforms now let evaluators review prompt history, but a live conversation is often enough: ask why they accepted or rejected a suggestion.
Consistency is what makes skills-based hiring fair and defensible.
If you use automated candidate screening or scoring, determine whether it falls within applicable employment-tool rules. For tools covered by New York City Local Law 144, the city requires an independent bias audit within the preceding year, public audit information and specified notices. Covered NYC residents must receive the notice at least 10 business days before use. These requirements concern covered automated employment decision tools, not every AI tool a candidate uses while completing a work sample. Confirm coverage with employment counsel for the roles and locations involved.
The same competencies apply at every level, but the evidence you look for changes:
| Level | Emphasize | Example adjustment |
|---|---|---|
| Early career | Learning speed, debugging fundamentals, honest use of AI | Smaller codebase; ask them to explain every line they accept from an assistant |
| Mid-level | Ownership, code review, testing habits | Planted-issue review plus a short feature extension |
| Senior | System design, trade-offs, mentoring, risk judgment | Design discussion with changing constraints; review of a teammate's pull request with coaching comments |
| Staff or principal | Technical strategy, cross-team influence, cost and reliability | Written design proposal discussed with engineering leaders |
Be careful with early-career candidates. Over-reliance on AI is a real risk, but so is screening out people who learned with these tools. Ask them to reason aloud about what generated code does and how they would test it; the ability to explain is a better signal than whether they typed every line.
Ambiguity about AI use creates unfairness: some candidates hold back while others use every tool available. State the policy in the invitation for each stage:
Clear rules also make cheating less attractive, because the exercise rewards the reasoning a hidden helper cannot easily supply in a live conversation.
Skills-based hiring selects candidates on evidence of what they can do, gathered through realistic work samples and structured interviews scored against a rubric, rather than on degrees, years of experience or keyword matches. For developers, it means assessing the work they will actually do in the role.
For most SaaS engineering roles, yes, with clear rules stated in advance. Banning AI tests a way of working your engineers no longer use. Allowing it shifts the assessment toward reviewing, debugging and explaining code, which are the skills that matter when AI writes the first draft.
Verify identity at key stages, use exercises where candidates must explain and defend their reasoning live, follow a take-home task with a discussion of the choices made, and tell candidates the AI rules up front. Exercises that reward reasoning are hard for a hidden helper to fake.
Pick one open engineering role. Rewrite its description around six-month outcomes, replace one existing exercise with an AI-permitted code review or debugging session, and introduce a shared rubric. Review the results after five or six candidates and adjust.
If you are deciding whether to hire permanently at all, our guide to staff augmentation vs dedicated teams vs direct hiring compares the options. Growix's Talent Acquisition & Recruitment team designs recruiting processes, sourcing and interview structures, and our HR Technology & Automation team configures applicant tracking systems, scorecards and hiring analytics. For publishing compliant salary ranges in those job postings, see pay transparency laws and job postings.
The three models differ less in hourly cost than in who manages the work, how fast people start and what knowledge stays when they leave. A cost model and decision rules.
Agencies fill individual roles; RPO runs your hiring process; an in-house team builds lasting capability. Model all three against your hiring forecast before choosing.
With salary range rules in more states each year, the hard part is not the posting but the pay structure behind it. A workflow from compensation bands to job ads, records and candidate questions.
