Competency-Based Interviewing: Question Design, a 1–5 Scoring Rubric, and Linking to Training Needs from an L&D Perspective

An interview question, when written correctly, captures not “what do you know?” but how you behaved under which conditions; when written poorly, it measures only how well someone talks. For L&D, this distinction isn’t a minor detail: the raw material of your training plan becomes either real behavioral evidence or a polished narrative.

My goal is to take “competency-based interviewing” off HR’s shelf and turn it into learning data. Because there’s a strange inconsistency on stage: the same company asks candidates for behavioral evidence; once they become employees, it suddenly assigns training based on evidence-free assumptions. I still can’t fully model this transition. Does the human mind change the moment it walks through the door?

Below, I’ll design questions with the STAR technique, build a 1–5 rubric with behavioral indicators, and then connect interview outputs to a competency gap → personalized learning journey flow. I won’t forget GDPR and HSE either; because what you call “data,” if not handled correctly, will one day knock on your door as an audit.

“Evidence is not proof; it is the available body of facts.” [Carl Sagan, The Demon-Haunted World, 1995]
What you collect in an interview is exactly that: not absolute truth, but behavioral traces sufficient to make a decision.

1) The real purpose of competency-based interviewing: reading “potential” through evidence

Competency-based interviewing (behavioral interviewing) focuses not on a candidate’s “good intentions,” but on the behavior they demonstrated in a similar situation. Because working life is measured by behavior, not intent: a customer objects, a team falls apart, an HSE rule is violated, a GDPR email goes to the wrong person… and in that moment, your reflexes speak.

There are two critical L&D implications here:

• Competency ≠ a list of training topics. Competency is a pattern of behavior that shows up in context.
• Interviewing ≠ only a selection tool. If designed well, it’s the baseline measurement for a personalized development plan starting from the moment of hire.

At this point, a sentence Saadet (who truly deserves to be called a “We’ll Handle It” Specialist) hears from customers sticks with me: “We selected the candidate, then we opened the same training plan for everyone.” We look for differences when selecting, then ignore them when developing. An interesting contradiction.

2) Turning a competency into “behavioral indicators”: what to do before writing questions

Before you start writing STAR questions, you need to reduce the competency from an abstract one-line label to observable indicators. Otherwise, a phrase like “communication competency” turns into something different in everyone’s head.

Here’s a simple template:

• Competency name: (e.g., objection handling)
• Contexts: (customer, internal stakeholder, crisis, pricing, SLA, etc.)
• Behavioral indicators (positive): what do they do?
• Red flags (negative): what do they do / not do?
• Type of evidence: what examples count as realistic evidence? (metric, output, feedback, event flow)

Example (short):

• Competency: GDPR awareness (application)
• Positive indicators:
  • Applies data minimization (doesn’t ask for unnecessary data)
  • Escalates in suspicious situations
  • Verifies access authorization
• Red flags:
  • Shares personal data via an inappropriate channel saying “nothing will happen”
  • Suggests an off-the-record workaround to speed up the process

Let me make a small correction here: when I said “type of evidence,” I may have sounded like I meant only metrics; I didn’t. Sometimes the best evidence is the chronology of an incident: “I saw this → I assumed this → I did this → I reported it here.”

3) Designing questions with the STAR technique: templates and the “good question” test

The STAR (Situation–Task–Action–Result) technique forces a candidate’s narrative into four parts: Situation, Task, Action, Result. I say “forces” because people naturally like to decorate the story with “I actually…” STAR reduces the decoration.

STAR question templates

The templates below speed you up when writing a question bank. Each serves a different purpose.

Template A — Critical incident (real lived experience)

• “Tell me about a time you experienced a difficult situation related to … . What was the situation? What was expected of you? What did you do? What was the result?”

Template B — Conflict and alignment

• “Give an example of a time you disagreed with a stakeholder. What data did you rely on to move forward? How did you manage the communication? What changed as a result?”

Template C — Mistake and learning (my favorite)

• “Tell me about a time you made the wrong decision. What signal did you miss in that moment? What did you do differently afterward?”

Template D — Ethical/compliance pressure (works very well for GDPR/HSE)

• “Give an example of a time you had to follow a rule while under process pressure. What was the pressure? What did you do? Who did you consult? What was the outcome?”

Template E — Uncertainty

• “Tell me about a time you had to make a decision with incomplete information. How did you gather information and manage risk?”

Quick checklist for a “good question”

Before publishing a STAR question (yes, I treat interview questions as something you “publish”), I run these 5 tests:

• Does it measure a single competency? (Don’t cram two competencies into one question.)
• Is the context clear? (role, stakeholder, goal)
• Does it force Action? (They shouldn’t be able to dodge the “What did you do?” part.)
• Is the Result measurable? (output, metric, behavior change)
• Is it resistant to canned answers? (Does it demand detail rather than generic phrases?)

One user observation here: interviewers sometimes treat “they explained it beautifully” as a score. But a beautiful narrative is not a competency; it may be the competency of storytelling. That’s valuable for some roles, but not for every role.

4) Sample question bank: 12 questions written to generate data for L&D

I wrote the bank below to produce “scorable behavior.” Next to each question, I note the competency it targets.

1. Prioritization / time management
   “When multiple urgent tasks came in, tell me about an example from the last 6 months. How did you prioritize, what did you postpone, and what was the result?”

2. Stakeholder management
   “When an internal customer’s expectations conflicted with process requirements, what did you do? Give an example.”

3. Problem solving
   “Tell me about a situation where you traced a recurring error to its root cause and solved it. What data did you collect?”

4. Receiving feedback / growth mindset
   “Tell me about a time you received difficult feedback. What was your first reaction, and what did you do next?”

5. Persuasion / objection handling
   “Give an example of a time you changed your mind when the other party said ‘no,’ or you persuaded the other party. What argument worked?”

6. Quality focus
   “Tell me about a time you raised the standard instead of leaving a task as ‘good enough.’ What was the cost?”

7. HSE awareness (application)
   “Do you have an example of a time you stopped work—or recommended stopping it—because you saw an HSE risk? What happened?”
   (In HSE, the reflex to “stop work” sometimes clashes with culture; I want to hear that clash.)

8. GDPR awareness (application)
   “When a request involving personal data came in, how did you verify the legitimacy of the request? Tell me an example.”

9. Decision-making under uncertainty
   “Tell me about a time you had to take ownership of a task without a clear target. How did you define the target?”

10. Teamwork
    “Give an example of a time you took on an invisible task within the team. Why did you do it?”

11. Conflict resolution
    “Tell me about an example where you resolved tension before it escalated. Which sentence was the turning point?”

12. Customer focus
    “Do you have an example where you realized what the customer said and what they needed were different? What did you do?”

What makes this bank “hard to memorize” is that the questions demand a specific incident. A specific incident is the fuel for the rubric.

5) The 1–5 scoring rubric: behavioral indicators + red flags

A rubric takes interviewing out of “gut feel” and turns it into comparable data. I usually use 1–5; because 1–3 is too coarse, and 1–7 is too fine for interview time.

Below is a sample rubric. Competency: HSE awareness (application). You can use the same skeleton for GDPR, customer management, and problem solving.

Two principles when writing the rubric:

1. Each score must move up via a “behavior difference.”
   “Explained it better” is not a level difference.

2. Red flags are a separate column.
   Because some behaviors make the total score meaningless. In GDPR, for example: something like “I sent the data via WhatsApp” is a risk signal even if they’re very strong elsewhere.

Mini protocol for using the rubric (for the interviewer)

• While the candidate speaks, take notes under STAR headings: S / T / A / R
• Score at the very end (early scoring produces “confirmation bias”)
• If there’s no “concrete evidence,” don’t give 4–5 (protect yourself, protect the data)

Also: a rubric is not a guarantee of “objectivity,” but it does produce consistency. These two are often confused when it comes to people.

6) Linking interview data to learning analytics: competency gap → personalized journey

Now to the real issue: interview data, in most companies, stays in a PDF. That PDF gets archived, never to be opened again. But from an L&D perspective, the interview is the new employee’s first competency map.

Here’s the data flow I recommend:

1. Competency → Rubric score (1–5)
2. Rubric score → risk level / priority
3. Priority → learning action (onboarding module, mentoring, practice, assessment)
4. Action → measurement (short test, checkpoint, behavioral observation)
5. Measurement → journey update

Let me put this into a table; because the human brain runs away less when it sees a flow as a table:

A “personalized journey” here doesn’t necessarily mean hundreds of pieces of content. Sometimes the only difference is this: within the same training, you give some people more practice, some more rule reminders, and some more advanced cases.

At Nextrain, these kinds of distinctions can be automated with AI Rules: onboarding/mentoring/learning assignments for those who fall below a certain score, for example. I won’t claim here whether I collect “interview scores” directly inside the platform; because the data source varies by company. But the rule logic is clear: IF (risk) THEN (journey).

And there’s this: in Nextrain, training flows and interactions are tracked at the event level (view, click, answer, time). This helps you test the hypothesis you started with in the interview (“this person is weak in objection handling”) during training: where exactly did they struggle, on which question, how many times did they go back?

7) Automation draft: an “interview → onboarding” bridge with AI Rules (example)

The draft below is concrete enough for an L&D team to use, but general enough to adapt company by company. I think of this as “writing rules”: the art of translating human intent into a system.

RULE 1 — HSE critical gap
IF (HSE rubric score <= 2)
THEN (assign HSE onboarding package) + (assign checkpoint test after 7 days) + (send summary to manager)

RULE 2 — GDPR risk
IF (GDPR rubric score <= 2)
THEN (assign GDPR awareness training) + (add real-time test/checkpoint) + (re-assess within 14 days)

RULE 3 — Objection handling development area
IF (Objection handling rubric score == 3)
THEN (basic journey + practice scenario)
IF (checkpoint score < 60%)
THEN (retraining with AI Gates)
ELSE (move to advanced case)

The nice part of this flow is: the interview doesn’t produce a label, it produces a trigger. And L&D’s job is to connect the trigger to the right action.

GDPR note: interview data may fall under personal data. A “behavior example” may include third-party data. That’s why retention, access, and masking policies must be clear. On the Nextrain side, there is an architectural approach where Akira does not see personal data (hash/mask/strip); but the internal process still matters: who sees it, how long it’s retained, and for what purpose.

Notes

1. Carl Sagan, The Demon-Haunted World: Science as a Candle in the Dark (1995).