TL;DR
Screen for problem-solving, data literacy, schema thinking and reproducibility rather than tool names, and don't default to the most experienced candidate you can afford. Someone two to three years in with the right instincts is often the better hire.
65% of organisations report a GIS analyst shortage. Only 10% of advertised roles are entry-level.
Those two numbers describe a market that’s eating itself: high demand, thin supply, and most of the hiring pressure sitting at the mid-to-senior level, where everyone is competing for the same small group of people.
It gets worse at both ends of the pipeline. Geospatial job openings are growing at 11–12% a year through 2030, while graduate supply is rising at roughly 2% over the same period (WGIC Industry-Academia Committee, via WGIC’s Horizons podcast, 2025). At the other end, industry estimates put upwards of 40% of currently licensed surveyors retiring within five years (Stephanie Mishot, Trimble, WGIC Horizons Podcast, 2025). Organisations are trying to build a junior pipeline and absorb the institutional knowledge of a generation that’s leaving, at the same time.
Most GIS hiring right now handles this badly. Not because employers aren’t trying, but because the job descriptions they’re using were written for a different version of the role, and the interview process hasn’t caught up.
We heard a version of the same argument in person at GeoBusiness last month. Aaron Addison of the World Geospatial Industry Council made the case that employers want geospatial people who also bring AI, cloud computing, and business acumen, skills that barely feature in a traditional GIS syllabus. Graduates are being trained for a version of the industry that’s already moved on. Which means the shortage isn’t just a numbers problem, it’s a mismatch between what’s being taught, what’s being asked for, and what’s actually needed on the ground.
The job description problem
Most GIS job descriptions read like they were written in 2015: ArcGIS, QGIS, attention to detail, map production. None of that is wrong, but it doesn’t reflect what the work actually involves in 2026. It attracts candidates in the wrong part of the skill distribution, or candidates who’ve learned to pattern-match a job description without the capability behind it.
The market has since moved to Python, GeoPandas and cloud-native workflows as the default filter, which makes sense; these are the skills that matter now. But the pool of people who can write a clean geospatial pipeline, handle large vector datasets, and reason confidently about coordinate reference systems and topology is narrow, and narrower again once you add domain knowledge on top (energy, property, planning, heritage). Everyone is fishing in the same small pond, and the people in it mostly have other offers.
A before-and-after job description
The gap between old and new is easiest to see side by side.
A typical 2015-era listing reads: “Proficient in ArcGIS and QGIS. Strong attention to detail. Experience producing maps for reports and presentations. Familiarity with GPS data collection.” Every line is about tool operation, and none of it says anything about how the candidate thinks.
A listing that actually screens for 2026 capability reads differently: “Comfortable writing Python to automate a repeated spatial workflow. Able to design a database schema for a new dataset from scratch, not just query one that already exists. Experience working with messy, incomplete, or inconsistently projected data, and a track record of sorting it out. Confident explaining a spatial finding to someone with no GIS background. Some exposure to cloud-native geospatial tools (cloud-optimised formats, serverless processing) is a plus, not a requirement.”
Notice what changed: the second version says almost nothing about specific software, and everything about how the person approaches a problem. That is deliberate. Tool names are a lagging indicator; the underlying capability is what determines whether someone is still useful in eighteen months, once the tool stack has moved again.
What to actually screen for
None of that disqualifies the candidates chasing these roles, it just means the screening has to go deeper than the tool stack. What actually separates a useful hire from an expensive one:
Problem-solving approach, not tool stack. Ask how they’d approach a dataset they’ve never seen before, and what questions they’d ask first. The answer says more about how they think than a list of software names ever will.
Data literacy over software literacy. Do they understand what the data represents, not just how to load it? Can they tell when a result looks wrong?
Schema thinking. Can they design a sensible data structure from scratch, or do they only know how to query one someone else built? This is a reliable proxy for whether their work will still make sense to someone else in twelve months.
Tolerance for dirty data. Most real-world GIS work starts with data that’s incomplete, inconsistently attributed, or in the wrong projection. Ask about a time they inherited a dataset in bad shape, and what they did about it.
Communication. Can they explain a spatial finding to someone who’s never heard of a shapefile? The analysis is worth nothing if the client can’t act on it.
Reproducibility habits. Scripts, version control, documented workflows. Not a software engineer’s rigour, but some evidence the work can be repeated by someone other than them.
AI literacy with discernment. Can they use AI tools to accelerate the work, then interrogate the output rather than just relay it? Stephanie Mishot of Trimble put it well on the WGIC Horizons Podcast: the skill is “using the tool but understanding the results, internalising them and then using that to make a decision going forward.” The failure mode is a candidate who can generate a report with AI but can’t hold a conversation about what it says.
Structuring the interview to actually test for this
A CV and a portfolio review get you part of the way, but the qualities that matter most (problem-solving approach, schema thinking, tolerance for dirty data) only show up when you watch someone work, not when you read what they say they can do.
A take-home exercise using a genuinely messy, real-world-shaped dataset is more useful than a whiteboard question. Give the candidate a dataset with a missing coordinate reference system, inconsistent attribute naming, and a handful of obviously wrong values, and ask them to prepare it for analysis and explain their decisions. There is no single correct answer. What matters is whether they notice the problems unprompted, and whether their explanation of what they did and why holds up under a follow-up question.
A live, screen-shared walkthrough of that exercise (rather than just reviewing the output afterwards) reveals more than the finished work alone. Watching someone reason through an unfamiliar dataset in real time, including the moments where they get stuck and how they recover, tells you far more about how they will handle the next messy dataset than a polished final deliverable does.
Finally, ask them to critique their own work. “What would you do differently with more time?” is a simple question, but the answer separates candidates who understand the limitations of what they built from candidates who are simply relieved to be finished.
The experience trap
Most hiring managers reach for the most experienced candidate they can afford. Given the pressure at the senior end, that logic seems sound. It often produces the wrong hire anyway.
A ten-year specialist can be expensive, opinionated about tools, and uninterested in the variety of work a growing team tends to offer. It’s more useful to ask a different question: can this person move from entry to mid, and eventually take on the senior responsibility that’s about to become vacant? That shifts the criteria from credentials to trajectory.
The best candidate for a growing team is often someone two or three years in, with genuine foundations, the right instincts, and room to develop. Onboarding takes a bit longer. What you get back usually justifies it.
Setting up a less experienced hire to succeed
Hiring someone two or three years into their career instead of a ten-year specialist only pays off if the first few months are structured well. Left to sink or swim on a complex, high-stakes dataset from day one, even a strong junior hire will struggle, and the organisation will conclude the wrong thing about their capability rather than about the onboarding.
The first month is best spent on real work, not training exercises, but on lower-stakes datasets where a mistake costs time rather than a client relationship or a planning submission. Pairing them with a more senior person, even part-time or through a consultant brought in for exactly this purpose, gives them somewhere to take the questions that will not have obvious answers yet.
By the second or third month, they should be handling a full piece of work independently, with a defined check-in point rather than open-ended supervision. The goal is not to remove all support, but to shift it from constant to scheduled, so both sides can see the trajectory clearly. Organisations that skip this structure and expect immediate senior-level output from a less experienced hire are usually the same ones who conclude, six months later, that they should have paid more for someone senior. The actual lesson is usually that the onboarding needed more thought, not that the hiring decision was wrong.
If you can’t find who you’re looking for
The shortage is real. If the candidate you’re describing doesn’t seem to exist in your market at the budget you have, it’s worth asking whether the work actually warrants a permanent hire.
Eilish Tinsley wrote a decision framework for exactly that question: when to hire and when to bring in outside help instead. Worth reading before you post the role.
If you’re in the middle of a GIS hire and want to compare notes, get in touch through our Knowledge Hub or book a consultation.