Why hiring a software engineer is so confusing for non-technical HR
A software engineer's CV is usually packed with technologies: Java, React, Docker, AWS, Kubernetes. To a non-technical recruiter they all look equally convincing. Yet there is a big gap between someone who has touched a technology and someone who can build a feature with it that real users rely on. The result is that candidates with polished CVs reach the technical stage, strong candidates with plain CVs get overlooked, and the engineering team's time goes to interviews that should never have happened.
The second difficulty is seniority. Job titles are not consistent between companies, so 'senior' in one place can be 'mid-level' in another. The safest approach is to define the concrete needs of the role first: the stack in use, the size of the team, and how independently the person must work. Then judge the CV and the interview answers against those needs, not against the longest list of technologies.
Challenges
A list of technologies does not show depth
A candidate can list twenty technologies on a CV without ever using them on a serious project. HR that screens by keyword ends up passing keyword-heavy CVs and missing the concise ones that have substance.
Portfolios and repositories are hard for HR to read
A GitHub link holds dozens of repositories, many of them tutorial exercises or forks. Without knowing which ones the candidate wrote, HR cannot judge quality and has to ask an engineer, whose time is limited.
Seniority titles vary between companies
Five years at a small startup and five years at a large company produce different experience. If seniority is read only from job title and years worked, salary placement and expectations often miss the mark.
Take-home tests and live coding both carry risk
A take-home test that is too long drives good candidates away, while a stressful live coding session screens out people who are actually strong in their daily work. The wrong format filters candidates the wrong way.
From a pile of CVs to a shortlist
Illustrated flow: CVs come in, are screened against your criteria, and only the most relevant candidates move on to the next stage.
The old way
- Open CVs one by one from email and job portals, then mark matching technologies by hand.
- Ask the engineering team to read through the pile of CVs and decide who is worth contacting.
- Contact candidates one at a time to schedule interviews, before knowing which ones are truly relevant.
With TalentRank
- Set up Custom Hiring Criteria for the role: core stack, seniority level, and the project evidence you want to see.
- Upload all CVs to CV Screening AI to get a ranking and a candidate summary measured against those criteria.
- Collect early data through WhatsApp Prescreening, such as availability to join and a portfolio or GitHub link.
- Run AI Interview with basic technical questions, review the scores and summaries, then schedule the technical interview with the team.
Developer CV screening criteria worth using
Agree on the weight of each criterion with an engineer or tech lead before the job opens. Use this table as a starting point, then adjust it to the stack and seniority of your role. High-priority criteria decide whether a candidate moves forward.
| Criterion | Priority | Good signs in the CV | Worth asking about |
|---|---|---|---|
| Tech stack fit with the job | High | The role's core technologies appear in project descriptions with a clear role, for example building an API in Node.js for an app used by real users, not just a mention in the skills section. | A technology appears only in the skills list, with no project that mentions it. Ask in the interview where and how it was used. |
| Evidence of real projects and repositories | High | There is a running project you can try, or a repository with a steady commit history, a README that explains how to run it, and tidy code structure. | Repositories hold only tutorial output or unchanged forks, with one big commit. Ask the candidate which parts they wrote themselves. |
| Problem-solving ability | High | The experience description contains a problem, the solution options, and the reason for the choice, for example fixing a slow query or cutting page load time with steps the candidate can explain. | Experience is only a list of tasks such as building features and fixing bugs, with no problem context or technical decision. |
| Seniority level fit | High | Scope of responsibility matches the level: juniors handle guided tasks, mid-levels own whole features, seniors shape architecture, mentor teammates, and help set technical priorities. | A senior title with junior-level responsibilities, or the reverse. Judge the scope and impact of the work, not only years of experience and job title. |
| Teamwork and code review experience | Medium | Mentions working with product managers, designers, or QA, using pull requests and code review, and being used to workflows like branching, testing, and deploying with a team. | Every project was done alone with no review from anyone. That is normal for freelancers, but ask how the candidate keeps their code quality up. |
| Written communication and CV clarity | Medium | The CV is short and clear, and each project has one sentence on the product's purpose and one on the candidate's personal contribution. Clear writing usually goes with clear technical communication. | A long CV full of jargon that does not explain the product or the results. It is hard to tell what the candidate actually did on those projects. |
Tech stack fit with the job
HighGood signs in the CV: The role's core technologies appear in project descriptions with a clear role, for example building an API in Node.js for an app used by real users, not just a mention in the skills section.
Worth asking about: A technology appears only in the skills list, with no project that mentions it. Ask in the interview where and how it was used.
Evidence of real projects and repositories
HighGood signs in the CV: There is a running project you can try, or a repository with a steady commit history, a README that explains how to run it, and tidy code structure.
Worth asking about: Repositories hold only tutorial output or unchanged forks, with one big commit. Ask the candidate which parts they wrote themselves.
Problem-solving ability
HighGood signs in the CV: The experience description contains a problem, the solution options, and the reason for the choice, for example fixing a slow query or cutting page load time with steps the candidate can explain.
Worth asking about: Experience is only a list of tasks such as building features and fixing bugs, with no problem context or technical decision.
Seniority level fit
HighGood signs in the CV: Scope of responsibility matches the level: juniors handle guided tasks, mid-levels own whole features, seniors shape architecture, mentor teammates, and help set technical priorities.
Worth asking about: A senior title with junior-level responsibilities, or the reverse. Judge the scope and impact of the work, not only years of experience and job title.
Teamwork and code review experience
MediumGood signs in the CV: Mentions working with product managers, designers, or QA, using pull requests and code review, and being used to workflows like branching, testing, and deploying with a team.
Worth asking about: Every project was done alone with no review from anyone. That is normal for freelancers, but ask how the candidate keeps their code quality up.
Written communication and CV clarity
MediumGood signs in the CV: The CV is short and clear, and each project has one sentence on the product's purpose and one on the candidate's personal contribution. Clear writing usually goes with clear technical communication.
Worth asking about: A long CV full of jargon that does not explain the product or the results. It is hard to tell what the candidate actually did on those projects.
Programmer interview questions that tell candidates apart
The best programmer interview questions ask candidates to talk about their real work, then dig in with follow-ups. Use these three groups for the first interview and save deep technical problems for the session with engineers.
Technical experience and projects
1.Tell me about the last feature you built from start to release. Which parts did you decide yourself?
A good answer: A good answer names concrete decisions and clear boundaries of responsibility. An answer that only says 'we' without a personal role needs more probing.
2.Why did you choose that technology over the alternatives on that project?
A good answer: A candidate who understands names trade-offs such as team size, performance, or business needs, not just 'it is popular' or 'I am used to it'.
3.What is the hardest bug you have found in production, and how did you track it down?
A good answer: A strong answer shows systematic thinking: forming a hypothesis, checking logs, narrowing the cause, then making sure the fix does not break something else.
Problem solving and code review
4.If a page suddenly gets slow as the number of users grows, what do you check first?
A good answer: A good answer starts with measurement, not guessing: checking queries, network, or server load before changing any code.
5.How do you review a pull request from a more junior teammate? What do you comment on and what do you let go?
A good answer: Senior candidates usually separate important issues like logic and security from matters of style preference, and give comments that teach.
6.Which of your own old code do you now consider not good enough? What would you change?
A good answer: Judging your own work honestly shows maturity. A candidate who thinks all of their code was right deserves further questions.
Collaboration and seniority
7.How do you explain a technical constraint to non-technical people such as HR or the business team?
A good answer: A good answer uses analogies and business impact, not technical terms. This matters because engineers almost always work with other teams.
8.When a time estimate turns out wrong, what do you do and who do you tell?
A good answer: A mature candidate reports early and brings options, rather than waiting until the deadline is close. It shows responsibility and honesty.
9.What do you do if you disagree with an architecture decision from the tech lead?
A good answer: A healthy answer includes presenting data and alternatives politely, then carrying out the final decision well, without brooding or quietly resisting.
Common mistakes
- 01
Screening CVs by the number of technologies listed
The CV with the longest technology list is not necessarily the most capable. Assess fit with the role's core stack and proof of use on projects, and ignore extra technologies the job does not need.
- 02
Giving take-home tests that take days
Candidates who already have jobs do not have long stretches for unpaid tests. Limit the task to about two hours, keep it close to real work, and discuss the result with the candidate instead of only scoring it.
- 03
Using algorithm puzzles for every position
Competition-style algorithm problems rarely reflect the daily work of most roles. Pick tasks that resemble real work, such as fixing a faulty function or reading a code snippet and commenting on it.
- 04
Not involving an engineer when drafting the criteria
HR writing criteria alone often uses the wrong terms. Involve one engineer for twenty minutes at the start to settle the core stack, the level, and the non-negotiables.
- 05
Equating years of experience with seniority
Ten years doing the same thing is different from five years of steadily growing responsibility. Ask what changed in the candidate's scope of work from year to year, not just how long they have worked.
Scenario
Company
A mid-sized logistics company that wants to build an in-house product team for a shipment tracking app.
Situation
The company opens one backend engineer position and receives many applications from job portals and LinkedIn. HR has no senior engineer with time to read every CV.
Expected outcome
Engineer time goes to interviews with the most relevant candidates, and the final decision stays with the team.
- 1HR and one engineer set up Custom Hiring Criteria: core stack, mid level, and a requirement for at least one shipped project.
- 2All CVs are uploaded to CV Screening AI, which ranks and summarizes each candidate against those criteria.
- 3Top candidates are contacted through WhatsApp Prescreening to collect availability, expectations, and repository links.
- 4Candidates who pass go through AI Interview, then HR reviews the scores and summaries and the engineer decides who is invited to the technical interview.
What you get
- A candidate ranking against the role criteria you set
- A CV summary per candidate: stack, projects, and scope of experience
- AI Interview answers, scores, and summaries for HR to review
- Early data from WhatsApp, such as availability and portfolio links
