5 tips to evaluate software configuration management skills

A bad release almost never starts with bad code. It starts with nobody being sure which version of the code is actually running.

That is the job configuration management does, and it is why the skill is so easy to mis-hire for. A candidate can rattle off Git commands all afternoon and still have no idea how to reconstruct exactly what shipped last Tuesday.

The short answer to the question in the title: you test five things, in order. Version control and release habits. Change tracking and control. Build and deployment pipelines. Documentation and audit trails. And what the candidate does when a release goes wrong. Each one has a probe you can run in under an hour, and they are all below, along with the tools a candidate should know and the process they should be able to describe without notes.

This page is written for the engineering hiring manager who owns the req, and the technical recruiter screening ahead of them.

TL;DR

• Configuration management is the discipline of knowing, at any moment, exactly what is in a system and how it got there. Version control is one part of it, not the whole thing.
• Tool names are the weakest signal you can collect. Nearly every candidate knows Git. Far fewer can explain what they deliberately keep out of a repository, and why.
• The strongest probes are reconstruction probes: ask a candidate to describe how they would rebuild last month's production environment from the repository alone.
• Google's DORA research ties thorough version control to continuous delivery, and gives you hard numbers to interview against: three or fewer active branches, merged to trunk at least daily.
• Configuration management is a security control, not just an engineering nicety. NIST publishes a whole guide on the security side of it.
• Test the reasoning with a work sample, then confirm it in conversation. A resume cannot show you either.

What is software configuration management?

Software configuration management is the practice of identifying every part of a system, controlling how those parts change, recording the current state, and verifying that the record matches reality. Four jobs. That definition is worth keeping in front of you during an interview, because candidates who only do the first two are common, and the gap shows up later as a release nobody can explain.

Version control is where most of the confusion sits. Git tracks the history of your files. Configuration management is the broader question of whether the thing you deployed can be described, reproduced, and audited. A team can have immaculate Git history and still not know which database schema version is live.

Keep the distinction straight in your own scorecard and you will hear it instantly when a candidate blurs it.

Why is configuration management important?

Because it is what makes a system recoverable. When something breaks at 2 a.m., the question is never "who wrote this" but "what changed and how do we get back". Teams that cannot answer quickly spend the outage guessing.

There is a security dimension too, and it is more formal than most hiring teams realize. NIST Special Publication 800-128, the guide to security-focused configuration management, treats configuration control as the foundation that security controls sit on, on the grounds that you cannot secure a system whose state you cannot describe. If a candidate has worked anywhere near regulated software, they should recognize that idea even if they have never read the document.

The market context is worth knowing before you set a bar for the role. The U.S. Bureau of Labor Statistics projects employment of software developers, quality assurance analysts and testers to grow 10% from 2025 to 2035, against 3% for all occupations, with median pay of $135,980 for developers. You are hiring in a tight, well-paid market. A sloppy screen is expensive twice over.

How the software configuration management process works

The classical process has four functions, set out in standards such as ISO 10007, and a strong candidate can name them in their own words even if they never use the textbook labels.

1. Identification. Deciding what counts as a configuration item and giving it a version. Code, yes, but also schema scripts, infrastructure definitions and build scripts.
2. Control. Governing how a change gets proposed, reviewed and accepted. Pull requests are the visible part; the real question is who can approve what.
3. Status accounting. Being able to state the current version of everything, and what changed between two points in time.
4. Audit. Checking that what the records claim is deployed matches what is actually deployed. This is the function teams skip, and it is the one that catches drift.

On the question of scope, Google's DORA program is specific about what belongs under version control: application code and dependencies, database schema and reference-data scripts, environment provisioning and container definitions, test scripts, deployment and migration scripts, infrastructure-as-code files, and now AI artifacts such as prompts and agent configuration files. DORA's research on version control finds that using it thoroughly across all of that predicts continuous delivery, and that it works as a safety net for teams adopting AI tooling, where generated code arrives faster and less predictably.

That last item is a useful 2026 screening question in its own right. Ask a candidate whether prompts and agent configs belong in the repo. The reasoning they give tells you whether they think about configuration management as a principle or as a list of tools they once used.

Best software configuration management tools to know

Candidates will reach for tool names first, so it helps to know how the categories actually divide. The U.S. Department of Labor's O*NET occupational profile for software developers splits them into file-versioning software (Git, Apache Subversion, Mercurial) and configuration management software (Chef, Puppet, Terraform, Perforce Helix), and flags Git and Terraform as in-demand technologies.

That split matters in an interview. Someone can be fluent in the first column and untested in the second.

Do not score this as a quiz. A candidate who has used Puppet rather than Chef is not weaker; a candidate who cannot say what either category is for probably is.

How do you evaluate configuration management skills?

Here are the five tips, each with the probe that makes it real.

1. Test version control and release management depth

Start with branching, because it exposes how a candidate's team actually worked. DORA's findings on trunk-based development give you numbers to interview against: higher-performing teams keep three or fewer active branches, merge to trunk at least once a day, have branches that live hours rather than weeks, and run without code freezes or integration phases.

Ask what their branch lifetime looked like and why. A candidate who says branches lived for weeks and explains the cost they paid for it is telling you more than one who recites trunk-based development as a best practice they have never run.

2. Test change tracking and configuration control

Give them a scenario. A config value was changed in production nine days ago, and nobody is sure by whom. Walk me through finding out.

Good answers move toward the record: version history, deployment logs, an audit trail, a diff between two known states. Weak answers stay at the level of asking around. The difference is whether the candidate treats the system of record as the source of truth or as paperwork.

3. Test build and deployment pipelines

The question that separates depth from exposure: how does a deployed artifact trace back to a commit? Candidates who have genuinely owned a pipeline talk about build numbers, tags, immutable artifacts and promotion between environments. Candidates who have only consumed one talk about clicking the deploy button.

Follow up by asking what they would do if the same commit produced different builds on two runs. Reproducibility is the concept you are fishing for.

4. Test documentation and audit trails

This is the function teams skip, so it is the one worth probing hardest. Ask how they would prove to an auditor which version was live on a given date. Then ask who, on their last team, would have been able to answer that without them.

The second question is the useful one. Configuration management that lives in one person's head is a risk the hiring manager inherits.

5. Test behavior when a release goes wrong

Skills show up under pressure. Ask for the last rollback they were part of, what the first five minutes looked like, and what they changed afterwards. Listen for whether the fix was a process change or a heroic effort.

And listen for blame. Someone who describes a rollback entirely as other people's mistakes will do the same on your team.

Pro Tip: run the reconstruction probe before any tool question. "Rebuild last month's production environment using only what is in the repository, and tell me where you would get stuck." The places a candidate expects to get stuck are an honest map of how their last team really worked.

Configuration management assessment: what to include

A structured assessment beats an unstructured conversation, mostly because it is consistent across candidates. The Testlify Competency-to-Evidence Matrix is the method we use for this: do not start with a test, start with the role. Map the role to the competencies that matter, connect each competency to evidence you can actually collect, and only then pick the assessment method. Every competency has to produce evidence, which is what stops a scorecard quietly becoming a list of opinions.

For a configuration management role that usually means four or five competencies: version control reasoning, change control, pipeline and reproducibility knowledge, documentation discipline, and collaboration under incident pressure. Evidence for the technical ones comes from a work sample. Evidence for the last one comes from a structured conversation, scored the same way for everyone.

In practice, a work sample carries most of the load. Testlify's coding questions support multi-file projects in an embedded VS Code editor, with up to 20 test cases that can be visible or hidden and scored per case, which suits a task like "fix this broken build configuration" far better than a syntax quiz. The practical, hands-on question type accepts a file upload or a URL, so you can ask for a repository and read the commit history as evidence rather than relying on a self-report. Weighted and section-level scoring then let you say out loud that change control counts for more than tool familiarity on this req.

One honest tradeoff worth knowing before you build it. Question banks can serve a fixed set to every candidate or draw randomly from a pool, and smaller pools raise the chance two candidates see the same items. Tighter anti-cheat, more authoring work. Pick deliberately rather than by default.

A worked example. Say a 40-person engineering team is hiring two release engineers and screening roughly 60 applicants. Scoring a 45-minute work sample before the first call means the shortlist arrives already ranked on change-control reasoning, so the hiring manager's interview time goes to the five candidates who cleared the bar instead of the first five who applied. The ranking is the point, not the time saved.

If you are building the wider technical screen around this, the same logic applies to designing coding assessments generally, and there is a fuller walkthrough of evaluating and hiring software engineers that covers the surrounding loop.

Where do hiring teams get this wrong?

Four failure modes, in rough order of how often they show up.

• Scoring tool names. Git is close to universal among working developers, so "knows Git" separates nobody. The signal is in what they keep out of the repo and why.
• Treating it as a junior concern. Configuration management discipline is a senior judgement skill. It gets screened like a tooling checkbox and then missed at the level where it matters.
• Asking for a portfolio repository and not reading it. If you request a repo, read the commit history. That history is the evidence. Asking and ignoring is worse than not asking.
• One assessment for every engineering role. A platform engineer and a mobile developer need different configuration management depth. A single generic test produces false negatives on both.

And the honest limit of all of this: no assessment tells you how someone behaves during a real outage at 2 a.m. A work sample tells you whether they can reason about state and change. The rest you learn from references and from the first quarter. Anyone selling you certainty about the 2 a.m. question is overselling.

Hire for configuration management with evidence

Build the matrix, score the work sample, keep the conversation structured. If you want to see what that looks like inside an assessment, you can book a demo, browse the test library for engineering and programming skills, or look at how coding tests are put together. Testlify also connects to 100+ ATS platforms, so the screening layer sits in front of whatever system of record your team already runs.

FAQs