Home Cartographer Interview questions
Cartographer interview questions
The questions people actually get asked for this role, and what each one is really testing.
What to expect
Cartographer interviews blend technical assessment of your GIS and map production skills with questions about accuracy, judgement and how you work with people who depend on your maps. Employers want evidence that you can move between source data, software and the finished product without losing precision.
- Technical GIS and cartography: Questions about projections, datums, scale, symbolisation and how you handle specific software tools such as ArcGIS Pro, QGIS or MapInfo Pro.
- Process and workflow: Walk throughs of how you compile, check and deliver a map from start to finish, including metadata and version control.
- Behavioural: Past examples of catching errors, meeting deadlines, managing competing priorities or working with difficult source data.
- Scenario and judgement: Hypothetical situations involving incomplete data, stakeholder pressure or a map that will guide real world decisions.
- Client and stakeholder communication: How you explain technical mapping choices to planners, engineers, field crews or the public.
Most processes start with a short phone or video screen covering your background and availability. The main interview is usually a panel with a hiring manager and a senior cartographer or GIS lead, lasting about an hour. You may be asked to bring a portfolio or complete a short practical task, such as preparing a small map or describing how you would clean a dataset. Some public sector panels add a separate technical exercise and a values based conversation.
- 1
Walk me through how you would compile a topographic map from survey data, satellite imagery and existing map sources.
Why they ask: This is the core production workflow for a cartographer, so the panel wants to hear a logical, repeatable process rather than a vague description of using GIS.
How to structure your answer: Give a step by step walk through: source review, datum and projection check, data capture and digitising, edge matching, symbolisation, quality check, metadata and delivery. Name the tools you would use at each stage and flag where you would pause to verify.
Example answer
“I start by reviewing every source to understand its currency, datum and scale. If a survey plan is on GDA2020 and an older map is on an earlier datum, I note the transformation before anything else. Then I bring the layers into ArcGIS Pro, digitise or clean features, and match edges between adjoining tiles. I build the symbol set and colour scheme against the project style guide, then run a check pass on scale, projection and topology. Finally I write the metadata, log the version and prepare both print and digital outputs. I keep a short note of any decisions or gaps so the next person can follow the trail.”
- 2
How do you check a map's accuracy, scale and projection before it is released?
Why they ask: Errors in scale or projection can mislead planners, field crews or emergency services, so the panel is testing whether accuracy checking is a habit rather than an afterthought.
How to structure your answer: Describe your checking routine in order: source comparison, scale bar and grid verification, projection and datum confirmation, label and symbol review, and a final visual check against a known reference. Mention how you record the check and who signs off.
Example answer
“I work from the source outward. First I compare a sample of features against the original survey or imagery to confirm positions. Then I check the scale bar and grid against the intended output size, and confirm the coordinate reference system matches the project brief. I review labels, symbols and legend entries for consistency, then view the map at full size and at print scale to catch overlaps or crowding. I record what I checked and any exceptions in the metadata, and I ask a colleague for a second pair of eyes on anything going to an external audience.”
- 3
Tell me about a time you found an error in spatial data close to a deadline.
Why they ask: This behavioural question reveals how you handle pressure, honesty and quality control when time is short.
How to structure your answer: Use STAR. Set the situation and deadline, describe the task and your responsibility, explain the action you took to verify and fix the issue, and give the result including what you changed in your process afterwards.
Example answer
“We were finalising a set of land tenure maps for a planning meeting when I noticed a parcel boundary that did not line up with the cadastral source. The deadline was the next morning. I traced it back to a digitising shift from an older dataset and flagged it to the project lead straight away. We agreed to correct the affected parcels and mark the area as under review rather than send something misleading. I stayed back to fix the layer, update the metadata and rerun the check. The maps went out on time with a note on the correction, and I started a short checklist for boundary verification that the team now uses on every tenure job.”
- 4
A stakeholder asks you to produce a map that hides a gap in a flood planning layer. How do you respond?
Why they ask: This scenario tests your professional judgement, your understanding of who relies on the map and your ability to push back without damaging the working relationship.
How to structure your answer: Show your reasoning under pressure: clarify what they actually need, explain the risk of hiding the gap, offer alternatives such as a caveat, an inset or a separate data confidence layer, and describe how you would document the decision.
Example answer
“I would ask what problem they are trying to solve. Often the request comes from wanting a clean visual for a public meeting, not from a wish to mislead. I would explain that a flood planning map with an unexplained gap can be read as low risk, which is dangerous for residents and for the organisation. I would offer options: show the gap with a distinct hatched pattern and a note, add an inset explaining the data limitation, or produce two versions, one for internal analysis and one simplified but still honest for the public. I would record the decision and the caveat in the metadata so the reasoning is traceable.”
- 5
How do you explain a projection choice or data uncertainty to someone without a mapping background?
Why they ask: Cartographers work with planners, engineers, community groups and executives, so the panel wants to see that you can translate technical concepts without losing accuracy.
How to structure your answer: Describe your approach to plain language explanation: start with what the person needs to decide, use a simple analogy if it helps, avoid jargon, and confirm understanding. Then give a brief example from your experience.
Example answer
“I start by asking what decision the map supports. If someone needs to compare distances across a region, I explain that we use a projected coordinate system so measurements stay reliable, in the same way a paper street directory is designed for a city rather than the whole globe. If there is uncertainty in the data, I say plainly where it comes from, for example older survey records or sparse satellite coverage, and what that means for their decision. I check that the explanation landed by asking them to summarise the main caveat back to me. I keep a one page guide with simple diagrams for common questions.”
- 6
How do you manage version control and metadata across a spatial database used by several teams?
Why they ask: Shared spatial databases are only useful if everyone can trust the current version, so this question probes your discipline with records, naming and access.
How to structure your answer: Explain your system: naming conventions, folder or geodatabase structure, edit tracking, metadata standards, backup routine and how you communicate changes. Mention any tools or standards you follow.
Example answer
“I use a consistent naming convention that includes the dataset, date and version, and I keep working files separate from published ones. In the geodatabase I set up feature level metadata so each layer records its source, currency, datum and any known limitations. I log every significant edit with a short note, and I run a weekly check that published layers match the approved version. When a change affects other teams, I send a brief note explaining what changed and why. I follow the ANZLIC metadata guidelines as the common reference so everyone is working to the same standard.”