Competency-Based Hiring: A Practical Framework Guide

Ask three engineers what a Senior Software Engineer looks like, and you may get three answers: years of experience, architecture ownership, or independence. Put those interviewers on one panel and they can assess the same candidate against different expectations. Competency-based hiring makes those expectations explicit before interviews begin. The useful artifact is a shared matrix that describes evidence you can observe, rather than adjectives everyone interprets privately.

TL;DR: Define a small set of competencies for a role, write observable expectations at each level, and choose interview questions that reveal those expectations. Use the worked Software Engineer matrix below as a starting point, then calibrate it against your team's actual work.

---

Why Competency-Based Hiring Needs More Than a Job Description

A job description tells candidates what they will do. A competency framework tells interviewers what evidence to look for. “Own the backend architecture” names a responsibility; it does not explain what separates a Junior answer from a Senior one.

Start with work the new hire will encounter. For each responsibility, ask what an interviewer could hear, read, or see that would justify a positive assessment. Replace “strong communicator” with an example of a clear decision note, or “good debugger” with a description of how someone tests a suspected cause.

• Role first. A backend engineer and a customer success manager need different evidence, even when both roles value communication.
• Level second. Change the expected scope, independence, and impact as responsibility grows.
• Evidence throughout. Write criteria that another interviewer can challenge using the candidate's answer or work sample.

Key takeaway: Your framework should help a panel explain its judgment. Treat it as an input to interviews, not a justification written after a favorite candidate emerges.

---

Building Your Competency-Based Hiring Matrix

Use competencies as rows and levels as columns for one job role. Begin with a manageable set of distinct responsibilities. The example uses five: Code quality, Debugging, System design, Communication, and Delivery ownership. These are proposed criteria for a fictional engineering team, not a universal definition of seniority.

Give each row a boundary. Code quality concerns the implementation being changed; Debugging concerns finding the cause of a fault. System design concerns service boundaries and dependencies. Communication concerns making a decision understandable, while Delivery ownership concerns organizing work and responding to delivery risk.

• Separate overlapping evidence. A clear incident explanation may support Communication, but the tested explanation of the fault supports Debugging. Record what each row establishes rather than awarding the same impression twice.
• Keep one central judgment per row. If “technical depth” bundles code quality, debugging, and architecture, disagreement becomes difficult to diagnose.
• Check relevance. Remove a row when you cannot name work in this role that needs it, or an interview activity that can reveal it.

Write Guidelines You Can Actually Assess

“Communicates effectively” offers little guidance. “Writes a decision note comparing options, states a recommendation, and answers questions from affected colleagues” gives the interviewer an observable activity and a possible follow-up.

For each cell, describe the action, its scope, and the evidence it leaves. Avoid using years of experience as a substitute for demonstrated ability. Progression should change responsibility: from a scoped task, to an independent feature, to a decision spanning teams.

Tip: Draft cells from concrete examples your team can discuss. Ask two interviewers to assess the same sample answer independently; disagreement identifies wording that needs clarification.

---

A Worked Software Engineer Competency Matrix

Here is the complete example across Junior, Mid, and Senior. Each compact table represents one row of the same matrix, so the full expectations remain readable without squeezing three long sentences side by side. Every intersection has a guideline; none is left blank.

Code quality

Level	Observable expectation
Junior	Implements a small change with clear names and tests for stated inputs and edge cases, using review feedback.
Mid	Refactors a module without changing its behavior, adds regression tests, and explains the maintenance trade-offs in review.
Senior	Defines code boundaries for a multi-team change, compares migration options, and proposes checks that protect existing consumers.

Debugging

Level	Observable expectation
Junior	Reproduces a reported fault, gathers relevant logs, and explains the failing step before asking for help.
Mid	Forms competing explanations for a production fault, tests them against evidence, and verifies the fix with a regression check.
Senior	Traces a fault across service boundaries, coordinates containment, and proposes monitoring that would expose the same failure earlier.

System design

Level	Observable expectation
Junior	Explains how a request moves through an existing service and identifies where validation and data storage occur.
Mid	Designs a service change, compares storage and interface options, and describes failure handling for its dependencies.
Senior	Designs a change spanning teams, makes capacity and reliability assumptions explicit, and outlines rollout and rollback decisions.

Communication

Level	Observable expectation
Junior	Describes completed work and a blocker with enough context for a teammate to suggest a next step.
Mid	Writes a decision note comparing options, states a recommendation, and answers questions from affected colleagues.
Senior	Explains a disputed technical decision to different audiences, records their constraints, and documents the agreed trade-off and remaining risk.

Delivery ownership

Level	Observable expectation
Junior	Breaks a scoped task into steps, reports a missed assumption promptly, and confirms completion against agreed acceptance criteria.
Mid	Plans a feature with dependencies, flags delivery risks early, and renegotiates scope when evidence changes the estimate.
Senior	Sequences a multi-team delivery, assigns dependency owners, and defines release checkpoints with explicit criteria for delaying the launch.

The distinctions concern responsibility rather than vocabulary. A Junior debugger can explain a reproducible failing step; a Mid engineer can test competing causes; a Senior engineer can coordinate containment across services. A candidate should describe what they actually did, including help received, rather than repeat the cell's wording.

• Adapt the scope. Replace “multi-team” when that responsibility does not exist in your organization. A title alone does not justify copying that expectation.
• Keep the bar explicit. Decide which cells are required for the opening before meeting candidates. Do not silently move the target to another column during a debrief.

Key takeaway: This example supplies a complete starting point. Calibrate its expectations to the work you are hiring someone to do before treating it as your hiring bar.

---

Put the Matrix Into an Interview Plan

A matrix needs questions that can reveal its criteria. Assign each interview activity a primary competency and decide what evidence would support the target level. Ask follow-ups that clarify the candidate's own contribution, constraints, and outcome.

For the Mid Debugging guideline, ask about a fault with more than one plausible explanation. Follow up with “What evidence ruled an explanation out?” and “How did you verify the fix?” Those questions test the process described in the cell without requiring a particular employer, technology, or job title.

• Plan coverage. Give each important row an interview activity and an interviewer responsible for collecting evidence.
• Keep criteria at hand. Share the written guidelines with interviewers before the session and refer to them while assessing answers.
• Record specifics. Note what the candidate demonstrated, what remains uncertain, and which follow-up would resolve it. Missing evidence is different from demonstrated inability.

Score independently before the debrief. Then discuss the evidence behind disagreements: “They compared two causes but did not explain how they verified the fix” is a more useful starting point than “They didn't feel Senior.”

Tip: Use How to Score Candidates Fairly for rating guidance and Calibrating the Hiring Bar for Senior Roles to plan a shared calibration discussion.

---

Build and Edit the Example in Intervy

Intervy provides a competency matrix for each job role. The matrix is available on every plan, including Free; your organization role still controls whether you can view or change the framework. Ask an administrator for the relevant access if the editing controls are unavailable.

Open Job Framework, select New Job Role, and enter Software Engineer. Select Junior, Mid, and Senior, then save. Intervy's default levels also include Lead and Expert, but this example uses only the three selected levels. Create or rename organization levels as needed; creating a level does not automatically add it to every role's matrix.

• Add the rows. Open the role and select Add First Competency, then Add Competency for each remaining row. Use the names from the example.
• Add the expectations. In table view, select a cell at the desired competency and level. This opens the Edit Guideline dialog; enter the expectation in Guideline, then select Save.

The screenshot shows the worked example in the editor. Select a saved cell to revise its text in the dialog. For example, the Senior Code quality cell describes boundaries, migration options, and checks for existing consumers.

You can switch between table and card views. With permission to update competencies, you can also reorder rows by dragging them. The dialog offers a not-applicable option for a competency that genuinely does not apply at a level; this complete example does not use it.

Tip: Open and save the Software Engineer competency JSON reference to keep a copy of this example. It contains the same role, levels, competency names, and guidelines as the tables. It is reference data for manual adaptation, not a file you can import into Intervy or a sample question set.

---

Keep the Hiring Bar Useful as the Role Changes

Review the matrix between hiring cohorts, especially cells that caused repeated disagreement. Keep a dated copy of the criteria used for a cohort and record changes in your team's hiring notes. Apply revised expectations to future interviews, so the panel can explain which criteria it used for each decision.

Avoid turning the framework into an exhaustive checklist. More rows require more evidence, and a short interview cannot explore every responsibility deeply. When coverage is thin, reduce the scope or plan another relevant activity rather than infer competence from a confident answer.

• Replace vague language. Rewrite cells that could describe any role at any level.
• Preserve level differences. If every column says the same thing, revisit the expected scope and autonomy.
• Challenge duplicate rows. Merge or separate criteria when interviewers cannot explain which judgment belongs where.
• Review the process too. A useful guideline still needs an appropriate question and enough opportunity for the candidate to answer.

Key takeaway: Start with a complete, understandable definition of the work, test it with your interviewers, and refine it deliberately. Explore Intervy's competency-based hiring features when you are ready to put that shared framework into practice with a structured interview tool.