Hire Terraform developers

Terraform declares infrastructure as code across providers, and hiring for it means testing how someone handles state and blast radius rather than syntax.

What Terraform actually is

Terraform is a tool for defining infrastructure declaratively and applying those definitions through provider plugins that talk to cloud platforms and other services. You describe the resources you want, it works out the difference against what exists, and it makes the changes. Its licence changed from fully open source to a business source licence, which prompted the creation of a community fork, and that fork is now a genuine consideration for some organisations.

The value is that infrastructure becomes reviewable, reproducible and versioned like application code. A change can be proposed, read, discussed and approved before anything happens, and the current state of an environment can be understood by reading a repository rather than by clicking through a console. For anything beyond a trivial estate, this is the difference between infrastructure you understand and infrastructure you hope about.

The complication, and the thing to interview for, is state. Terraform keeps a record of what it believes it created, and that file is the single most dangerous artefact in the system. If it is lost, corrupted, or does not match reality, the next apply can destroy things. Everything that separates a careful Terraform engineer from a dangerous one comes back to how they treat state.

The part that separates seniors from mid-levels

State is the foundation. It must live remotely so a team can share it, it must be locked so two people cannot apply at once, and it must be backed up. Drift, where reality no longer matches state because somebody changed something by hand, is a constant operational reality rather than an edge case. Engineers who have dealt with a corrupted state file, or who have used targeted imports and state manipulation to recover, have knowledge that only comes from having been in trouble.

Blast radius is the second concept and it drives how a codebase should be structured. A single configuration covering an entire estate means every change plans against everything and a mistake can affect everything. Splitting by environment and by lifecycle, so that the network layer and the application layer have separate state, limits what any one apply can touch. This is an architecture decision rather than a style preference, and it is very hard to change later.

Reading a plan carefully is the third discipline, and it sounds trivial until you watch someone do it badly. A plan that shows a resource being destroyed and recreated rather than updated in place is the difference between a configuration change and an outage. Some attributes force replacement and it is not always obvious which. An engineer who reads every plan line before applying, and who can explain why a change forces replacement, is describing the habit that prevents most Terraform incidents.

Where Terraform is used

The label “Terraform developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Cloud infrastructure management

The primary use, defining accounts, networking, compute, databases and permissions across providers.

Multi-environment consistency

Ensuring development, staging and production differ only in ways that are declared and visible.

Compliance and audit

Regulated environments where every infrastructure change must be reviewed and evidenced.

Platform provisioning

Creating the clusters, networks and accounts that product teams deploy into.

Multi-cloud and hybrid

One tool and one workflow across several providers, which is a genuine advantage of the model.

Non-infrastructure providers

Managing services such as identity providers, DNS, monitoring and code hosts through the same workflow.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which Terraform versions are still supported

Terraform and its community fork both release frequently, and provider versions matter as much as the tool version, so pinning and a committed lock file are part of what currency means here.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 2 are still maintained and 6 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for Terraform alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

Remote state with locking

Shared state in object storage or a managed backend. Non-negotiable for team use.

Modules

Reusable components. Useful in moderation and a common source of over-abstraction.

Terragrunt or native stacks

Managing many configurations and reducing repetition across environments.

tflint and tfsec or Checkov

Linting and security scanning, run before anything reaches review.

A pipeline with plan on review

Plans posted on pull requests and applies gated behind approval.

Provider plugins

The cloud and service integrations. Version pinning here matters as much as anywhere.

A secret manager

Credentials referenced rather than written into configuration or state.

Infracost or similar

Showing the cost impact of a change at review time rather than at month end.

Related skills that frequently appear on the same specification: Go, Microsoft Azure, AWS, DevOps, Kubernetes.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

State management

The most dangerous part of the tool and the clearest test of real experience.

• Strong answer: Remote state with locking, separated by environment and lifecycle, backed up, and has recovered from a state problem.
• Warning sign: Local state files, or has never thought about two people applying simultaneously.

Reading a plan

The habit that prevents most Terraform outages.

• Strong answer: Reads every line, watches for forced replacement, and has stopped an apply because the plan was wrong.
• Warning sign: Applies without reading, or does not know what forces a resource to be recreated.

Blast radius and code structure

An architectural decision that is very hard to change once an estate depends on it.

• Strong answer: Splits state by environment and lifecycle, and can explain the trade-off against the convenience of one configuration.
• Warning sign: One configuration for the entire estate with no separation.

Handling drift

Manual changes happen, and how someone responds to them says a lot.

• Strong answer: Detects drift regularly, reconciles deliberately, and knows when to import rather than recreate.
• Warning sign: Has never encountered drift, which usually means nobody is checking.

Secrets in configuration and state

State files contain resource attributes, including sensitive ones.

• Strong answer: References a secret manager, knows state can contain secrets, and protects state access accordingly.
• Warning sign: Puts credentials in variables files, or does not know secrets can end up in state.

Module design

Over-abstraction is the most common structural problem in mature Terraform codebases.

• Strong answer: Writes modules for genuine reuse, keeps interfaces small, and has simplified an over-engineered one.
• Warning sign: Wraps every resource in a module, producing indirection with no benefit.

The licence change and the fork

A live commercial question rather than a technical one.

• Strong answer: Aware of it, can explain what it affects, and has an opinion appropriate to the organisation's situation.
• Warning sign: Unaware, which suggests limited engagement with the ecosystem.

Warning signs in a Terraform codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

Local state

• What you see: State files on a developer's machine or committed to the repository.
• What it costs: Two people applying produce conflicting changes, and a lost machine means a lost estate record. State in a repository also leaks any secrets it contains.
• The fix: Remote backend with locking from the first day. This is not an optimisation, it is a prerequisite.

One configuration for everything

• What you see: A single state covering networking, databases, clusters and applications.
• What it costs: Every plan is slow and touches everything, and one mistake can affect unrelated systems.
• The fix: Separate by environment and by rate of change. Networking and application infrastructure should not share a state file.

Applying without reading the plan

• What you see: Automatic approval, or a habit of scrolling past the output.
• What it costs: Resources destroyed and recreated when an in-place update was expected, which for a database is an outage and possibly data loss.
• The fix: Require the plan to be reviewed by a person. Treat any forced replacement as something that must be explicitly acknowledged.

Unpinned provider versions

• What you see: No version constraints on providers or modules.
• What it costs: A provider update changes behaviour and an unrelated apply produces unexpected changes.
• The fix: Pin versions and commit the lock file. Upgrade deliberately, with a plan reviewed like any other change.

Over-modularisation

• What you see: A module wrapping each individual resource, with layers of variable passing.
• What it costs: Simple changes require edits in several places, and nobody can see what a configuration actually creates.
• The fix: Use modules for patterns repeated across environments. Write resources directly when they are used once.

Manual changes alongside Terraform

• What you see: Console edits to resources that Terraform manages.
• What it costs: Drift, and the next apply reverting a fix somebody made during an incident.
• The fix: Reconcile emergency changes into code the same day, and restrict console write access on managed resources.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a Terraform engineer.

Junior

Makes changes within an established configuration. Should not apply to production unsupervised.

Mid-level

Owns the infrastructure definition for a service, writes modules, and reads plans carefully.

Senior

Owns the state architecture, the blast radius design, the pipeline and the provider upgrade strategy. Can recover from state problems.

Staff

Owns the standards across teams, the module library, the policy controls, and the decision about the tool and licence direction.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

Greenfield infrastructure definition

• Usual team: One senior engineer.
• What governs it: State architecture and separation decided here determine how safely the estate can be changed for years.

Importing an existing estate

• Usual team: One engineer.
• What governs it: Slower than writing new configuration. Expect to discover resources and settings nobody documented.

Module library

• Usual team: One senior engineer.
• What governs it: Scoped by consumer count. Over-abstraction is the main risk and it is easy to fall into.

Pipeline and policy controls

• Usual team: One engineer.
• What governs it: Plan on review, apply on approval, security scanning. Usually quick and high value.

State restructuring

• Usual team: One senior engineer.
• What governs it: Genuinely risky work involving state manipulation. Needs someone who has done it before.

Migration work you may actually be hiring for

A large share of Terraform work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

Console-managed infrastructure to Terraform

• Why teams do it: Reviewable, reproducible infrastructure and a disaster recovery story that is real.
• What to watch: Import rather than recreate. Start with the foundational layers, and expect the import to reveal configuration nobody documented; that discovery is the value rather than a delay.

A single monolithic configuration to separated state

• Why teams do it: Limiting blast radius and making plans fast enough that people read them.
• What to watch: Moving resources between state files is genuinely risky and needs someone who has done it. Do it one boundary at a time with backups, and never under deadline pressure.

Terraform to the community fork

• Why teams do it: Licence policy, or a preference for foundation governance.
• What to watch: Currently close to a drop-in change for most configurations, and the two will diverge over time. Decide based on organisational policy rather than sentiment, and check provider compatibility for anything unusual you depend on.

Manual applies to a pipeline

• Why teams do it: Review, audit trail and a consistent execution environment instead of whatever was on someone's laptop.
• What to watch: Plan on pull request and apply on merge after approval. The main work is credential management for the pipeline, which should use short-lived federated credentials rather than stored keys.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a Terraform engineer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• How state is currently managed, since local state is the clearest signal of an estate at risk.
• How the configuration is structured and whether blast radius has been considered.
• Which providers are in use, including any non-infrastructure ones.
• Whether applies run through a pipeline or are performed by individuals.
• Whether an existing estate needs importing, which is slower than it sounds.
• Whether the organisation has a position on the licence change and the community fork.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

Terraform work is counted by the US Bureau of Labor Statistics under Network and Computer Systems Administrators. That classification is broader than the technology itself, so treat the figures as the shape of the market a Terraform engineer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 314,340 people in this occupation, with a median annual wage of $99,130.

The spread matters more than the midpoint. The 90th percentile is about 2.5 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a Terraform engineer can sit at $62,640 and $155,050 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for Terraform frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Network and Computer Systems Administrators, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $133,360; Pittsburgh sits at the bottom with $80,440. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. Washington, D.C., Baltimore, Austin, Raleigh, Tampa, Charlotte each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

No experience of state problems. Ask about a state file they had to repair. This is where Terraform causes real damage.

Applying without reading plans. Ask about an apply they stopped. The habit of reading is what prevents outages.

Over-abstraction instinct. Ask about a module they simplified. Restraint matters more here than capability.

Unaware of the licence situation. Relevant for organisations with policies about licensing, and a reasonable proxy for ecosystem engagement.

Hiring Terraform developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of Terraform engineer who will be available.

• New York, NY $119,390 median
• Seattle, WA $104,440 median
• San Jose, CA $133,360 median
• Washington, D.C. $125,430 median
• San Francisco, CA $129,680 median
• Dallas-Fort Worth, TX $103,260 median
• Los Angeles, CA $106,290 median
• Boston, MA $116,770 median
• Chicago, IL $103,170 median
• Atlanta, GA $101,000 median
• Austin, TX $104,520 median
• Phoenix, AZ $93,730 median
• Philadelphia, PA $100,460 median
• Minneapolis-St. Paul, MN $102,790 median
• Denver, CO $105,090 median
• Detroit, MI $96,400 median
• Houston, TX $101,430 median
• Charlotte, NC $89,990 median
• San Diego, CA $105,170 median
• Salt Lake City, UT $99,110 median
• Miami, FL $97,180 median
• Portland, OR $102,950 median
• Baltimore, MD $122,950 median
• Tampa, FL $101,560 median
• Orlando, FL $91,800 median
• Raleigh, NC $103,380 median
• Kansas City, MO $91,980 median
• Pittsburgh, PA $80,440 median

Frequently asked questions

Do we need Terraform if our cloud provider has its own tool?

Provider-native tools are perfectly good when you use one cloud and intend to keep it that way. Terraform's advantages are one workflow across providers, a very large ecosystem including non-infrastructure services such as DNS, identity and monitoring, and a much larger hiring pool. For most organisations the hiring and ecosystem arguments are the decisive ones.

What happened with the Terraform licence?

HashiCorp moved Terraform from an open-source licence to a business source licence, which restricts certain competing commercial uses. A community fork was created under the original terms and is maintained by a foundation. For most organisations simply using the tool, nothing practical changed. For those with policies requiring open-source licences, or building products around it, the fork is worth evaluating.

How dangerous is Terraform really?

Dangerous enough to deserve respect. A misread plan can destroy and recreate a database. A lost or corrupted state file can leave an estate unmanageable. These are not exotic scenarios; they happen to teams that skip remote state, apply without reading, or put everything in one configuration. With those three disciplines in place it is safe, and without them it is genuinely risky.

Should we import our existing infrastructure?

Yes for anything you intend to keep changing, because unmanaged infrastructure is undocumented infrastructure. Be prepared for it to take longer than writing new configuration, and for the process to reveal settings nobody knew existed. Import the foundational layers first, such as networking and permissions, since those are where undocumented configuration hurts most.

How should we structure our Terraform code?

Separate state by environment and by how often things change. Networking, shared services and application infrastructure have different lifecycles and should not share a state file. Modules are for patterns genuinely repeated across environments, not for wrapping individual resources. Getting this wrong is one of the harder things to correct later, because restructuring state is risky work.

Can Terraform manage things other than cloud infrastructure?

Yes, and this is underused. Providers exist for DNS, identity providers, monitoring tools, code hosts and many software-as-a-service products. Bringing those under the same review-and-apply workflow means the configuration of your whole operating environment becomes visible in one place rather than scattered across consoles.

Who should be allowed to apply to production?

Ideally nobody directly, with applies running through a pipeline after an approved plan. That gives you review, an audit trail and a consistent execution environment. Where individuals do apply, it should be a small group with the state backend permissions to match, and console write access to managed resources should be restricted for everyone.

Do our developers need to know Terraform?

Reading it, usually yes, because understanding what infrastructure their service depends on is part of owning it. Writing and applying it is a specialist concern in most organisations. A good middle position is that developers can propose changes and read plans, and a smaller group owns the structure and the approval.