Vetting

How we vet experts

Before anyone works on your project, they complete an in-depth AI interview with AI Screenr, our AI recruiter, and a senior Jobrela specialist reviews the evidence. You get experts who have proven what they know, not just listed it on a CV.

AI interview for every expertEvidence behind every scoreA person makes the final decision
The process

Every expert passes an AI interview and a human review

Four steps between a promising CV and an expert on your project.

1

Profile and requirements

We define what the project needs, from must-have skills and their level to knockout criteria and the language level.

A clear profile of the expert you need
2

AI interview

The candidate does a structured voice interview of 15 to 60 minutes with the AI interviewer, at any time that suits them, in their own language.

The same depth for every candidate
3

Scored report

Every answer is scored against a rubric, with evidence quotes from the transcript.

Scores backed by what the candidate said
4

Human decision

A senior Jobrela specialist reviews the report and the transcript and makes the final decision. AI recommends, people decide.

Only proven experts join your project
Sample report

What a Java developer interview report looks like

This is the report our clients receive after every AI interview. The candidate is invented, so no real person's data is shown, but the structure is exactly the same.

Role Java backend developer, Spring Boot microservicesInterview 45 minutes, English, audio and videoQuestions from the client’s role descriptionData illustrative example, invented candidate
72/100
YesHigh assessment confidence (75%)Better than 82% of candidates

Summary

Why this recommendation

The candidate showed solid, hands-on Spring Boot and microservices experience and explained real design decisions with concrete examples. All knockout criteria are met. The recommendation is “Yes” rather than “Strong yes” because Kubernetes production experience, a must-have for this role, was not shown, and answers on concurrency stayed at the level of definitions.

Overview

An experienced backend developer who has built and run Spring Boot services in production, with a good grasp of API design, transactions and resilience patterns. The main gaps are hands-on Kubernetes operations and depth in Java concurrency. A strong fit for the role if the team can support the Kubernetes side during onboarding.

Knockout criteria and must-haves

Knockout criteria

Right to work in the EU

The candidate is an EU citizen and needs no work permit.

"I’m a Czech citizen, so no permit needed."

Availability

Can start within the required four weeks.

"My notice period is one month, I could start at the beginning of December."

At least 4 years of Java backend experience

Has about six years of professional Java backend development.

"About six years now, mostly Spring Boot services for e-commerce and payments."

Must-have competencies

Spring Boot (advanced)

80 %

Built and maintained several Spring Boot services in production and explained configuration and testing choices in detail.

"We moved all services to Spring Boot 3 last year, the biggest change was the Jakarta namespace and native observability."

REST API design and microservices (intermediate)

75 %

Described versioning, idempotency and service boundaries from own experience.

"Every payment request carries an idempotency key, so a retry never charges twice."

SQL and JPA/Hibernate (intermediate)

70 %

Knows how to find and fix N+1 queries and when to drop down to native SQL.

"The N+1 problem showed up in the order history, we fixed it with an entity graph."

Kubernetes in production (intermediate)

60 %

Only deployed with a prepared Helm chart; no experience with troubleshooting or scaling workloads.

"The platform team owned the cluster, we just changed the values file."

Scores in ten areas

Score breakdown
Communication clarityStrong evidence
80 %7/10(weight 0.08)

Explained technical decisions clearly and in a logical order, with occasional long detours.

"We split the monolith along the payment and order boundaries first, because those two teams kept blocking each other."

Relevance of answersStrong evidence
80 %8/10(weight 0.08)

Answers stayed on the question and were tied to the candidate’s own projects.

"In our case the retry happened in the gateway, so the service itself had to be idempotent."

Technical knowledgeStrong evidence
75 %8/10(weight 0.18)

Strong practical knowledge of Spring Boot, JPA and REST API design; good understanding of transactions and resilience patterns.

"We used a circuit breaker around the card provider, and a dead-letter queue for anything that still failed after three retries."

Missing: Hands-on Kubernetes operations beyond deploying with a ready-made Helm chart.
Problem solvingModerate evidence
70 %7/10(weight 0.14)

Walked through a production incident step by step, from symptoms to root cause and fix.

"The connection pool was exhausted, so first I looked at which queries held connections the longest."

Fit for the roleStrong evidence
75 %8/10(weight 0.12)

Has built exactly the kind of services the role needs and has worked in similar team setups.

Confidence and presenceModerate evidence
70 %7/10(weight 0.05)

Calm and confident, and openly said where their knowledge ends.

"Honestly, I have not tuned that myself, the platform team did."

Behavioural fitModerate evidence
60 %6/10(weight 0.08)

Gave one good example of mentoring a junior developer, but little about handling disagreement in the team.

Missing: An example of resolving a technical disagreement.
Completeness of answersModerate evidence
60 %6/10(weight 0.10)

Most answers were complete; some technical answers stopped at the definition without trade-offs.

Missing: Trade-offs between concurrency approaches.
English language proficiencyStrong evidence
80 %8/10(weight 0.07)

Fluent professional English, comfortable discussing technical topics in depth.

Depth on prepared questionsModerate evidence
65 %6/10(weight 0.10)

Strong on Spring Boot and API resilience, thinner on concurrency and transaction propagation.

Missing: Deeper answers on the Java memory model and transaction propagation.

Prepared technical questions

Question coverage

B1. What are the main differences between Spring Boot and the traditional Spring Framework?

83% topics covered5/6 knowledge areas
Covered
Auto-configurationOpinionated starter dependenciesEmbedded serverExternalised configuration and profilesActuator and monitoring
Not covered
How to override or exclude an auto-configuration
Strengths

+ Explained auto-configuration with a concrete example from a real migration.

Weaknesses

- Did not mention how to exclude an auto-configuration that gets in the way.

B2. What does the volatile keyword do, and when would you use it?

40% topics covered2/5 knowledge areas
Covered
Visibility of changes between threadsTypical use for a status flag
Not covered
Happens-before relationshipWhy volatile does not make compound operations atomicAlternatives such as AtomicInteger and locks
Strengths

+ Gave a correct, practical example with a shutdown flag.

Weaknesses

- Could not explain why count++ on a volatile field is still not thread-safe.

B3. How would you design a payment API that stays correct when clients retry and downstream services fail?

80% topics covered4/5 knowledge areas
Covered
Idempotency keysRetries with backoffCircuit breakerDead-letter queue for failed messages
Not covered
Outbox pattern for consistent events
Strengths

+ Answered from a real production system, with numbers and trade-offs.

Weaknesses

- Did not cover how events stay consistent with the database.

B4. What are common pitfalls with @Transactional in Spring?

50% topics covered2/4 knowledge areas
Covered
Self-invocation bypasses the proxyRollback only for unchecked exceptions by default
Not covered
Propagation levels such as REQUIRES_NEWTransactions on private methods
Strengths

+ Knew the self-invocation problem from experience.

Weaknesses

- Unsure about propagation levels.

Gaps

Hands-on Kubernetes operations and deeper Java concurrency.

Missing evidence
  • Hands-on Kubernetes troubleshooting and scaling.
  • Trade-offs between concurrency approaches and the Java memory model.
  • Transaction propagation levels and when to use them.
  • An example of resolving a technical disagreement in the team.

Suggested next step

Invite to a technical interview with the team lead. Focus on a short Kubernetes troubleshooting scenario and a concurrency exercise, for example a thread-safe cache.

Sample comparison

How ten Java developer candidates compare

Every candidate for a role answers the same questions, so you can rank them, compare them area by area and see the strengths and risks of the best three. Invented candidates, real structure.

Role Java backend developer, Spring Boot microservicesCandidates 10Criteria 10, the same for everyoneData illustrative example, invented candidates

Ranking

You decide the criteria. These ten are the default, but you can add, remove or reweight any of them. Each cell is coloured by its score; a star marks a value well above the group, a triangle one well below it. Coverage shows how much of the prepared questions the interview actually got through.

Scroll the table sideways.
CandidateScoreRecommendation
Communication clarity
Relevance of answers
Technical knowledge
Problem solving
Fit for the role
Confidence and presence
Behavioural fit
Completeness of answers
English language proficiency
Depth on prepared questions
KnockoutsCoverageDate
Anna Kowalska
kowalska@example.com
74Yes8.08.07.08.07.06.08.0★7.09.0★6.0✓ 370 %15 Oct 2026
Lukas Berger
berger@example.com
72Yes7.08.08.07.08.07.06.06.08.06.0✓ 374 %14 Oct 2026
Tomas Hruby
hruby@example.com
70Yes6.07.09.0★8.07.06.05.07.06.08.0★✓ 388 %13 Oct 2026
Marek Szabo
szabo@example.com
58Yes6.06.06.05.06.06.06.06.07.05.0✓ 362 %16 Oct 2026
Elena Petrova
petrova@example.com
52Maybe7.06.05.05.05.06.07.05.08.04.0✓ 355 %12 Oct 2026
Jakub Dvorak
dvorak@example.com
47Maybe5.06.05.04.05.05.05.04.06.04.0✓ 348 %17 Oct 2026
Peter Weiss
weiss@example.com
44No6.05.06.05.04.05.04.04.07.05.0✕ 1✓ 260 %13 Oct 2026
Ivana Horvat
horvat@example.com
38No5.05.03.0▼4.04.04.06.03.07.02.0▼✓ 335 %16 Oct 2026
Martin Lang
lang@example.com
31No4.04.03.03.03.0▼4.04.03.05.02.0✕ 1✓ 230 %12 Oct 2026
David Novak
novak@example.com
12No3.02.0▼1.0▼1.0▼1.0▼2.02.01.0▼4.00.0▼✕ 2✓ 110 %15 Oct 2026

The top three in one chart

Two to four candidates can be shown at once across all ten areas. Their totals are close, but their strengths are very different.

ClarityRelevanceTechnicalknowledgeProblemsolvingRolefitConfidenceBehaviouralfitCompletenessEnglishDepth
Lukas BergerAnna KowalskaTomas Hruby

The top three side by side

Exactly what the hiring manager sees on the comparison screen, strengths, risks, the candidate's own words and how much of each prepared question they covered.

Anna Kowalska

74/10070% coverage
Strengths
  • Clear, structured explanations of design decisions.
  • Strong teamwork and mentoring examples.
Risks
  • Less depth on JVM internals.
  • Limited experience with high-traffic systems.
Quotes

"I always write the API contract first and review it with the frontend team before any code."

Question coverage
B1 Spring Boot83 %
B2 volatile40 %
B3 payment API80 %
B4 @Transactional75 %
Suggested next step

Technical interview with a focus on performance and JVM tuning.

Lukas Berger

72/10074% coverage
Strengths
  • Hands-on Spring Boot and microservices in production.
  • Real experience with resilience patterns.
Risks
  • No Kubernetes operations experience.
  • Concurrency answers stay at definitions.
Quotes

"Every payment request carries an idempotency key, so a retry never charges twice."

Question coverage
B1 Spring Boot83 %
B2 volatile40 %
B3 payment API80 %
B4 @Transactional50 %
Suggested next step

Technical interview with a Kubernetes troubleshooting scenario.

Tomas Hruby

70/10088% coverage
Strengths
  • Deepest technical knowledge in the group, including concurrency.
  • Covered almost every prepared topic.
Risks
  • Short answers on teamwork and collaboration.
  • English is functional but slower.
Quotes

"count++ is read, add and write, so volatile alone does not make it safe, you need an AtomicInteger or a lock."

Question coverage
B1 Spring Boot100 %
B2 volatile100 %
B3 payment API80 %
B4 @Transactional75 %
Suggested next step

Meet the team to check collaboration and communication fit.

Why we compare this way

  • •The same questions for everyone means the numbers can be compared. In free-form interviews you compare impressions, not people.
  • •Nobody drops out because of one bad answer. The chart shows exactly where each candidate is strong and where they lose points.
  • •A candidate with a lower total can still be the best fit for your team, which is why you get all the numbers, not just a ranking.
  • •Candidates interviewed weeks apart can still be compared fairly.
What the interview checks

Six things we check in every expert

Knockout criteria

Clear yes or no requirements, such as availability or certifications.

Must-have skills

Each with the level the project needs, from basic to expert.

Deep technical questions

Follow-ups that probe 3 to 6 knowledge areas per question.

Real scenarios

Case studies, system design, coding discussion and behavioural questions.

Language level

An optional assessment on the CEFR scale, from A1 to C2, for the working language.

Full transcript

Every answer in writing, and a recording when the candidate agrees to one.

Why it matters

What it means for your project

Consistent

Every candidate gets the same depth and the same rubric.

Evidence instead of CV claims

Every score points to what the candidate actually said.

Faster

Experts are interviewed in parallel and at any hour, so your team can start sooner.

Fair and transparent

Fair to candidates, too

Good experts have options. A respectful, transparent interview is part of why they choose to work with us.

Consent first

Candidates agree before the interview and know that their answers are processed by AI.

People make the decision

No decision is made by AI alone. A person reviews every recommendation, as GDPR Article 22 requires.

Room to say no

Candidates can skip a question. It is recorded as skipped, not held against them.

FAQ

Questions about expert vetting

Every expert completes an in-depth AI interview with AI Screenr, built from the project's requirements. A senior Jobrela specialist then reviews the scored report and the transcript and makes the final decision.

No. The AI interviewer asks the questions and scores the answers against a rubric, but a person reviews every recommendation and makes the decision, as GDPR Article 22 requires.

Knockout criteria, must-have skills and their level, deep technical knowledge, real-world scenarios, communication and, if needed, the level of the working language on the CEFR scale.

Between 15 and 60 minutes, depending on the role. Candidates do it whenever it suits them, in their own language.

A scored report with evidence quotes from the transcript, the knockout and must-have results, scores in ten areas and a suggested next step, plus a comparison of all candidates for the role.

Every candidate gets the same questions and the same rubric, agrees to the interview beforehand and can skip a question without it counting against them.

Want experts who have proven what they know?

Tell us what your project needs, and we will introduce experts who passed the interview.

Learn more about AI Screenr →