How to assess senior software engineers: competence, evidence and a fair process

To assess a senior software engineer well, test the work, not the CV. Define the competences the role needs, ask every candidate the same structured questions, scored against written criteria, and watch them do a realistic piece of the job: write and test code, design a system, review someone else's change. Decades of research show that structured interviews and job-specific tests predict performance far better than unstructured conversations, while years of experience predicts it barely at all.

This guide is for CTOs, heads of engineering and founders who hire senior engineers, whether as employees or through a partner. It covers what competence means, what the evidence says, a five-stage process you can run in a week, what to avoid, what changes in German-speaking teams, and how to keep the standard once someone has started.

#What competence means beyond years of experience

"Senior" on a CV usually means a number of years. In a team it means something else: the person you can give an ambiguous problem and trust to come back with a working, tested, maintainable answer, having asked the right questions on the way. Eight competences describe that person. Write down which of them matter most for your role before you read a single CV, because that list becomes your interview plan and your scorecard.

Notice what is missing: years with a framework, a list of certifications, a degree. They can be useful context, but none of them tells you whether the person can do the job you are hiring for. A narrow years requirement ("seven years of Kotlin") also screens out strong engineers who learned the language last year on top of a decade of solid backend work.

#What the research says about hiring methods

The most cited summary of hiring research is Schmidt and Hunter (1998), which pooled 85 years of studies on how well selection methods predict job performance. In 2022, Sackett, Zhang, Berry and Lievens revisited those estimates in the Journal of Applied Psychology. They concluded that the earlier corrections had overstated validity, lowered most estimates by .10 to .20, and found that structured interviews now rank first.

Three lessons follow for hiring engineers. First, structure roughly doubles the value of an interview: the same hour, with the same questions for everyone and answers scored against written criteria, correlates about twice as strongly with later performance as a free conversation. Second, the strongest predictors are all job-specific: interviews about the actual work, tests of the knowledge the job needs, samples of the work itself. Sackett and colleagues point this out directly. Third, years of experience is close to useless as a predictor on its own, which is why it should not be the filter at the top of your funnel.

#A fair assessment process for senior engineers

The process below covers the eight competences with five stages and takes a candidate roughly four to six hours in total, spread over about a week. Each stage has a clear purpose, a fixed set of questions or tasks, and a scorecard filled in by the interviewer before they talk to anyone else.

1. Structured interview (60 minutes)

Ask every candidate the same five or six questions about real past work, with follow-ups planned in advance. "Tell me about a production incident you owned from alert to fix. What did you change afterwards?" tests ownership. "Describe a technical decision you argued against and lost. What happened?" tests communication and judgement. Score each answer on a 1 to 4 scale with written anchors for what a 2 and a 4 sound like, so two interviewers mean the same thing by "strong".

2. Realistic work sample or pairing session (90 to 120 minutes)

Give the candidate a small, self-contained task from your real domain: add a feature to a prepared repository, fix a failing test, extend an API endpoint. Run it live as a pairing session with one of your engineers, in the candidate's own editor if they prefer. You see how they read unfamiliar code, ask questions, test and explain. The candidate sees how your team works, which is part of a fair process too.

3. System design discussion (60 minutes)

Pick a system close to what the person will build: a booking service, an invoice pipeline, a notification system. Start with requirements and let the candidate ask about load, data and failure. Good seniors talk about trade-offs, data models, what happens when a dependency is down, and how they would ship a first version and evolve it. Score the reasoning, not whether they draw your architecture.

4. Code review exercise (45 minutes)

Show a realistic pull request of 150 to 300 lines with planted problems: a missing authorisation check, an untested edge case, a confusing name, a query inside a loop. Ask the candidate to review it as they would for a colleague. This one exercise shows code quality, testing, security awareness and tone. Reviewers who find the access control bug and phrase their comments kindly are rare and valuable.

5. References (two calls of 20 minutes)

Speak to two people the candidate names, ideally a former lead and a peer, with the candidate's agreement. Ask the same structured questions each time: what did they own, how did they handle a disagreement, would you work with them again and in what role. References rarely change a decision on their own, but they can confirm or challenge a concern from the other stages.

#Scoring and the hiring decision

Most bad hires are not caused by bad interviews but by a bad decision meeting, where the loudest or most senior voice sets the outcome. Three habits prevent that. Interviewers submit their scorecard before the debrief and do not discuss the candidate beforehand. The debrief walks through the competences one by one, with evidence ("missed the authorisation check, found it after a hint"), not adjectives ("seemed sharp"). And the hiring manager decides against the bar written down before the search, not against the other candidates in the same week.

Hold the bar even when you are in a hurry. A vacancy open for one more month costs less than a senior engineer who has to be managed out after six. If nobody meets the bar, the right next step is to check whether the bar fits the role, not to lower it for the next candidate.

#What to avoid

• Puzzle and brainteaser questions. "How many windows are there in New York?" says little about engineering. Google's then head of people operations called brainteasers "a complete waste of time" (ABC News, 2013), and Highhouse, Nye and Zhang (2018) describe them as lacking evidence for validity and unsettling to applicants.
• Long unpaid take-home assignments. A take-home of more than two or three hours selects for free time, not skill, and senior engineers with jobs and families often decline. Keep take-homes short and scoped, or pay for longer work, or replace them with a live pairing session.
• Algorithm trivia unrelated to the job. Reversing a binary tree on a whiteboard tests interview practice. Unless the role really involves that kind of work, test the problems the person will actually solve.
• Unstructured "culture fit" chats. A pleasant conversation without set questions is the weakest kind of interview and the easiest place for bias. Assess collaboration and values with structured questions like everything else.
• A slow process. Strong seniors usually have several options. Keep the whole process within about two weeks and tell candidates at the start what each stage involves.

#Language, collaboration and fairness in DACH teams

Many engineering teams in Germany, Austria and Switzerland work in English while the business around them speaks German. Decide which language each part of the role really needs, and describe it with the Common European Framework of Reference (CEFR) levels rather than "fluent". An engineer working in an English-speaking squad may need German only for everyday conversation; one who runs workshops with German-speaking users or reads German specifications needs far more. Test the language in the stage where it matters, for example by running the system design discussion in German.

Working habits matter as much as language. DACH teams often expect decisions to be written down, agreed and then kept, and direct feedback in code review is normal. Ask in the structured interview how the candidate handles a reviewer who disagrees, and how they document a decision.

A structured process is also your best protection in Germany. Under the General Equal Treatment Act (AGG), if a rejected applicant shows facts suggesting discrimination on a protected ground, the employer has to prove there was none (§ 22 AGG). Written questions, scorecards and evidence-based decisions make that possible. Claims must be raised in writing within two months of receiving the rejection, and compensation for a candidate who would not have been hired anyway is capped at three months' pay (§ 15 AGG).

Two local habits concern references. Employees in Germany are entitled to a written reference when they leave (Arbeitszeugnis), which by law must be clear and must not contain coded statements (§ 109 GewO); in practice its stock phrases are still read as a grading scale, so treat it as context, not evidence. And contact referees only with the candidate's agreement, preferably people they have named, because you are collecting personal data about them.

#Keeping the bar after day one

The interview sets a floor; the team's daily habits set the real standard. A strong engineer in a team without review, tests or documentation will slowly write code like everyone else. Four habits keep the standard where you hired it.

• Code review on every change. Google's public guidance says a reviewer should approve a change once it definitely improves the overall code health, even if it is not perfect, and that comments which help someone learn are always welcome. That balance keeps review fast and makes it a teaching tool.
• Pairing in the first weeks. Pair a new engineer with someone experienced on real tickets. It transfers the unwritten knowledge of a codebase faster than any document and shows you early whether the hire works out.
• Tests as part of done. A change without tests for the behaviour it adds is not finished. Automated checks in the pipeline make that a team rule instead of a personal argument.
• Documentation that is kept current. A short architecture overview, decision records for choices that are expensive to reverse, and runbooks for production. New engineers should update them as part of onboarding, which is also the best test of whether they are any good.

Review the hire honestly after the first month and again after the third, against the same competences you assessed. If something is not working, say so early: it is fairer to the engineer and to the team.

#Checklist for hiring a senior engineer

#How we choose engineers at Bespoke IT

At Bespoke IT the engineers who build our own products review every profile we put forward, rather than a recruiter matching CV keywords. Before anything is signed, you meet the engineer in a working session on your own problem, and if the fit is not right, we bring in the next engineer. They work in your repository, your tools and your rituals. See how our talent service works, price a team or tell us who you need. If you are weighing a larger junior team against a smaller senior one, our article on why a senior development team looks at the trade-offs.