→ Start with the work the person needs to do Agree which skills someone needs when they join and which ones your team can teach. Ask candidates to demonstrate those abilities through relevant examples or a practical task, then use the same criteria to compare their answers.
Before advertising an engineering role, agree on what the person needs to handle. If they will own a backend service, how will you check that they can investigate failures, test changes and explain their decisions?
That is where skills-based hiring starts. Define the work, ask candidates for relevant evidence and agree how the team will judge it. A degree or previous job title can inform that conversation, but neither answers those questions on its own.
When hiring across Europe, use the same role requirements to assess candidates with different qualifications and career paths. Be clear about what they need to know when they join and what your team has time to teach.
Removing degree requirements is only the first step
Changing a job advert achieves little if recruiters still filter for familiar universities or hiring managers favour candidates from a handful of companies.
Research from Harvard Business School and the Burning Glass Institute found that many employers who removed degree requirements did not sustain meaningful changes in whom they hired. The report highlights the gap between changing recruitment language and changing recruitment decisions. Read the research on skills-based hiring in practice.
Check the whole process. Which applications does your screening software reject? What evidence earns an interview? What makes someone pass the technical assessment? Interviewers should be able to explain each decision through requirements they agreed before meeting candidates.
Our article on proof-first hiring and evaluating skills beyond degrees explores the broader approach. Here, the focus is how to apply it to an open technical role.
Start with the work the person will own
Before writing a list of technologies, ask the hiring manager what the new colleague needs to accomplish during their first three months.
“Strong backend engineer” leaves too much room for interpretation. “Take ownership of an API, investigate failed requests and release changes safely” gives the team something to assess.
Consider this illustrative role brief for a backend engineer joining an established product team:
| Work the person will own | Evidence to look for during hiring | Knowledge the team can teach |
|---|---|---|
| Investigate failed API requests | Forms useful hypotheses, reads logs and checks assumptions | The company’s monitoring tools and service history |
| Deliver a small backend change | Explains code decisions, tests relevant behaviour and considers failure cases | Internal code conventions and deployment steps |
| Maintain data integrity | Reasons about validation, transactions and duplicate requests | The product’s data model and business rules |
| Coordinate changes with colleagues | Explains dependencies, raises blockers and documents decisions | Team routines and internal documentation |
The distinction depends on your team. A role that requires immediate responsibility for a specialist system may need direct experience. A team with mentoring capacity may accept experience with a comparable tool.
Agree that boundary before sourcing begins. Otherwise, a “nice to have” can quietly become a rejection reason halfway through the process. We cover other problems that start with an unclear brief in our guide to engineering hiring mistakes.
Write requirements candidates can demonstrate
Turn broad requirements into descriptions of useful work. For example:
You have built or maintained backend services and can explain how you tested changes, investigated failures and handled dependencies. You can discuss a project where you owned a meaningful part of the work.
Then name any technology experience the role requires and explain which tools the team will help someone learn.
When recruiting across European countries, give candidates enough context to judge the opportunity. State the working language, employment location, office expectations and any on-call responsibilities. Keep those practical requirements separate from technical assessment criteria.
During screening, ask what the candidate actually owned. A familiar job title can cover very different responsibilities in two companies.
Accept different forms of evidence: a detailed project discussion, a permitted and anonymised work example, a relevant course project or a practical exercise. A public GitHub profile should not be the only route to demonstrating engineering ability. Candidates may have done their strongest work inside private repositories.
Build a short assessment around a real task
Choose an exercise that resembles the work you need someone to do. The US Office of Personnel Management’s guidance on work samples and simulations makes a useful distinction: assess abilities candidates need on entry, while recognising that some activities require training after they join.
For the backend role above, a possible exercise would be:
A background job occasionally processes the same customer request twice. Review a small code sample and a set of fictional logs. Explain what you would investigate, propose a change and describe how you would test it.
Give the candidate enough context to reason through the problem. Explain what the service should do, what the logs contain and which details they can ask about.
A 45–60 minute session could suit this example. Treat that as a design choice, then pilot it with someone who understands the role. Reduce the scope if setup consumes most of the time.
Before the session, tell candidates:
- What the exercise covers and how long it should take.
- Which abilities the interviewers will assess.
- Whether they may use documentation, search or AI tools.
- How to request an adjustment or discuss an alternative format.
- When they can expect a decision or feedback.
If you allow AI tools, ask candidates to explain and verify the output they use. Keep the rules consistent and provide comparable access where a tool forms part of the assessment.
Use fictional or sanitised material. Keep exercises separate from work the business intends to use commercially, and discuss payment before asking for a substantial project.
An assessment also asks candidates to invest time in your company. Track withdrawals and feedback so you can spot unnecessary friction. Our guide to using candidate experience data explains how to examine those stages.
Agree how you will score the evidence
An exercise needs a clear scoring guide. Otherwise, one interviewer may reward speed while another rewards detailed explanation.
Structured interviews use predetermined questions and common rating standards to make comparisons more consistent. The Office of Personnel Management’s structured interview guidance describes this approach.
For the background-job exercise, the team might assess investigation, testing, data handling and communication separately. The following example shows a possible scale for investigation:
| Rating | Evidence during the exercise |
|---|---|
| 1 — Needs substantial support | Proposes changes without checking the supplied evidence and cannot explain how to test the likely cause, even with prompting. |
| 2 — Developing | Identifies a plausible cause but needs prompts to connect it to the logs or design a useful check. |
| 3 — Meets the role requirement | Uses the evidence to explain a plausible cause, proposes a focused check and describes what would confirm or reject it. |
| 4 — Strong evidence | Meets the requirement, considers a credible alternative explanation and proposes a test that distinguishes between the two. |
This is an illustrative scale. Your technical team should adapt it to the role and trial it before using it to make hiring decisions.
Have interviewers record their evidence and ratings independently before the debrief. If they disagree, return to what the candidate said or did.
Record “not assessed” separately from a low score. If the exercise never tested a requirement, you have missing evidence. Also decide which requirements every hire must meet; a strong overall average should not conceal a gap in an essential ability.
Make trainable gaps part of the onboarding plan
Skills-based hiring can reveal candidates who meet the core requirements but need help with a specific tool or domain. Whether you can hire them depends partly on the support your team can provide.
For example, an engineer might demonstrate sound deployment principles while lacking experience with your CI/CD platform. An onboarding plan could name the colleague who will support them, reserve learning time and include a supervised pipeline change as a progress check.
“They seem like a fast learner” is too vague to carry that decision. Ask for an example of learning an unfamiliar system, then identify the actual gap, the available support and the work the person must eventually handle independently.
If nobody has time to teach a skill the role needs immediately, revisit the hiring requirement. A training plan needs an owner and time in the team’s schedule.
For broader development programmes, see our guide to employee upskilling in European companies.
Check whether the process helps you hire well
Review both recruitment decisions and the work new colleagues do after joining. Useful questions include:
- Are you interviewing suitable people whom your previous screening rules would have excluded?
- Where do candidates withdraw, and what reasons do they give?
- Can interviewers explain their scores using specific evidence?
- Do new hires meet the role outcomes you agreed at the start?
- Which assessment results prove useful when planning onboarding?
Compare similar roles and levels where possible. Pay, location, manager support and the difficulty of the vacancy can all affect the result. A shorter hiring process alone does not establish that an assessment works.
Review the exercise with new hires once they understand the job. Ask which parts reflected their work and which parts tested something they rarely use. Use that feedback to improve the next hiring round.
FAQ
Employers often use the terms interchangeably. Skills-based hiring usually emphasises demonstrated abilities, while competency-based hiring may group skills, knowledge and behaviours into broader requirements. Define what each requirement means for your role so recruiters and interviewers assess the same things.
Review each requirement on its merits. Ask what knowledge or capability it represents and whether candidates can demonstrate that in another way. Where a role requires a particular professional qualification or authorisation, check the applicable requirements before changing the advert.
Yes. Assess the foundations the junior role needs, such as reasoning through a small problem, reading code and responding to feedback. Course projects and guided exercises can provide evidence. Match expectations to the support the team will provide after hiring.
No. Recruiters and interviewers still make choices about criteria, exercises and scoring. Clear standards make those decisions easier to examine. Review rejection reasons, interviewer disagreements and candidate feedback to identify requirements or practices that need attention.
No. Choose an assessment that provides relevant evidence with a reasonable time commitment. A live debugging session or a structured discussion of previous work may suit the role. If you offer different formats, keep the assessed abilities and scoring standards comparable.
Build the hiring brief around the work
If your shortlist keeps coming back with the right keywords but little evidence of the skills you need, start with the brief.
Share the role, the work the person will own and where the search is getting stuck. Tech StaQ can help clarify requirements, identify relevant candidates and align screening with the hiring team’s expectations.
If you need ongoing support with hiring, explore our embedded recruitment and RPO service.