What is a competency based interview?

A competency is a skill that shows up in behaviour. Analytical thinking is a competency, holding a university degree is not; that one is a fact. The distinction is practical: a fact is read off a document, a competency can only be read from a situation where someone used it. That is what a competency based interview does: it does not ask about the trait, it asks how the candidate went through a situation that demanded it.

The method is not an alternative to the structured interview, it is a subset of it. A structured interview says measure every candidate with the same setup; a competency based interview says let the thing that setup measures be a competency. One builds the container, the other says what goes inside it.

In GoTeam that distinction has a concrete home. When you write a competency that cannot be verified from a CV on the posting form, the row moves into an amber frame and reads underneath that this criterion cannot be verified from the CV or the application form and can be evaluated in the interview. A competency falling to the interview is not an interpretation, it is a call the product makes.

• A competency shows up in behaviour, so its question is not can you do it but when did you do it.
• A criterion that cannot be verified from the CV produces no rubric item; the percentage you set aside for that row has no counterpart in the CV score.
• Interview evidence and CV evidence sit side by side and are never added. One measures what the candidate told you, the other what they documented.

Every criterion row passes through a deterministic classifier before it is saved. The classifier first tries to sort the row into factual categories such as experience, education, language or grade average. The free form skill statements it cannot sort are flagged by looking at three patterns: cognitive competency, soft skill, working arrangement.

Those three patterns fall into the unverifiable class and are shown together with their reason. The same classifier runs in three places: the triage during scoring, the check at save time and the inline indicator on the posting form. Coming from one source is not a tidiness preference, it is a correctness condition. Written separately, the form would show one thing while scoring did another.

The five rows below can sit side by side on the same posting. The statements in the left column come from the patterns the product itself carries, they are not invented examples.

The criterion weights have to add up to exactly 100 and every criterion is given a weight. This is where the order of importance among competencies is set. But a criterion that cannot be verified produces no rubric item; the finding is shown to you and the row stays where it is.

The consequence: the percentage you gave to the communication skills row never reaches the CV score. The score is still read out of 100, and that row carries none of its share into it. If you genuinely want to measure a competency, its place is not the criteria list, it is a question in the interview.

The question pool knows three categories and there is no fourth: Technical, Behavioural, Culture Fit. The core of a competency based interview is the Behavioural category. The generation brief for that category writes out the definition of the method almost word for word: measure past behaviour, ask with the tell me about a time you went through pattern, and ask for a lived example rather than a hypothetical scenario.

Picking a category does not make a question good on its own. In the generation request, question quality stands as a separate block of requirements and insists that every question is anchored somewhere: to a specific criterion of the position, or to a specific claim in the candidate's CV. Generic questions of the tell me about yourself kind are banned. Priority goes to topics that appear in the criteria but have weak evidence in the profile.

Whenever a competency based interview is described, there is talk of an expected answer column. In the panel that maps to the hint field sitting next to the question. It is one sentence long and tells the interviewer what a good answer has to contain. It has to be concrete: something like they should say which tool they chose and why, and the result they measured. In the pool row it appears behind a good answer label.

The hint is never read out to the candidate, it belongs to the interviewer. That is exactly what makes it work: the definition of a good answer is written before the conversation, which closes the door on bending the measure to fit the answer after hearing it.

A competency based interview is often described as a certificate of impartiality. GoTeam makes no such claim. What is written in the code is narrow and concrete: the four bans below stand item by item in the generation request, and the ban on personal traits is repeated on the grading side as well.

• Generic questions are banned. Every question has to rest on a specific criterion or a specific claim in the CV.
• Questions that close with a yes or a no are banned. The rule is written that way so the candidate has to explain.
• Questions that join two topics with an and are banned. One question, one topic.
• Questions about the candidate's personal life, age, marital status, health, faith and political views are banned. Even if that information comes up in an answer, it never enters the call.

The question pool hangs off the interview record; there is no shared question bank at company level. The wording can differ when the same competency is put to two candidates, because the question is tied to a claim in that candidate's CV. What stays fixed is the category set, the round structure, the position criteria and the decision scale.

The generation request goes out together with the list of existing questions, and producing the same question, or one that means the same thing, is forbidden; a second generation does not inflate the pool. The replace existing option clears only the rows the AI produced and leaves the questions you wrote by hand alone.

In grading, the model produces no score; the only thing it can return is one of four call words, and the arithmetic is the job of the code. For this page the real question is what the strong call is tied to: the answer has to both address the question and carry concrete grounding. The four things that count as grounding are written down, and that is what competency evidence means in this product.

Adequate is the answer that says the right things without giving any grounding. That difference is the whole point of the method: I believe in teamwork and on that project I resolved this disagreement in this way both address the same question, but only the second shows a competency being used.

Next to every call the model also writes back which position criterion it looked at, and the field stays empty when there is no matching criterion. The link between a competency and a question is recorded that way. The data handed to the grading model is narrow: the position title, at most 30 criteria, the questions, the recruiter hints and the answers. Contact details, the CV score and the application status are not given; a grader that sees an existing call starts agreeing with it.

What follows is not about the method itself, it is about where a competency gets written in the product. All four are expensive because they fail quietly.

• Writing a competency into the criteria list and expecting it to show up in the score. An amber flagged row produces no rubric item; the place for a competency is the interview.
• Marking an unmeasurable competency as required and taking it for an elimination gate. A gate item has to be measurable.
• Adding the answer score to the CV fit score, or reading both with the same bands. The two kinds of evidence sit side by side and are never reduced to one number.
• Assuming an analysis run is free. One question generation costs 1 credit and one answer analysis 1 credit; the re-scoring rule on the CV side does not apply here. An empty round sends no request and spends nothing, and a spent credit is refunded when the provider fails.