How would you build a data governance framework from scratch at a company that doesn't have one?

I start with a small, high-value scope rather than trying to govern everything at once. I identify the three or four datasets that drive the most important decisions, usually customer, revenue, and product usage data, and build governance around those first: clear ownership, an agreed definition for each key metric, and a data dictionary that's actually maintained rather than written once and forgotten. I run a short working group with the business owners of each dataset so the rules reflect how the business actually uses the data, not just what looks tidy on paper. I deliberately avoid a heavy policy document nobody reads. Instead I embed the rules into the tools people already use, like naming conventions enforced in the warehouse and validation checks in the ingestion pipeline. I treat the framework as a living thing: I review it every quarter and retire rules that turned out not to matter.

Walk me through how you'd handle a data quality issue discovered in a report that's already gone to the executive team.

First I confirm the scope of the error before saying anything: which numbers are wrong, how wrong, and which decisions might have been based on them. I've found that a fast, vague warning causes more damage than a slightly slower, accurate one. Once I have the facts, I notify the report owner and the executive recipients directly, with the corrected numbers and a plain explanation of the root cause, not just an apology. In one case a churn dashboard was double-counting reactivated accounts, inflating the retention rate by about 6 percentage points for two quarters. I traced it to a join condition that didn't account for accounts that had churned and returned within the same period, fixed the query, added a reconciliation check against the billing system, and briefed the executive team on both the correction and the fix so they knew it wouldn't recur silently.

How do you manage master data across multiple systems, for example duplicate customer records between a CRM and a finance system?

I start by establishing which system is the source of truth for each field, since trying to make every system equally authoritative is how duplicate records happen in the first place. For customer identity, I usually designate the CRM as authoritative for contact and relationship data, and the finance system as authoritative for billing and legal entity data, then build a matching key, often a combination of company registration number and normalised name, to link records across the two. I run a deduplication pass on a schedule, not just once, since new duplicates get created every time someone manually enters a customer without checking first. For the cases the automated matching can't resolve confidently, I route them to a human reviewer with the two candidate records side by side rather than auto-merging, because a wrong automatic merge is harder to unwind than a missed match.

How do you measure the health or maturity of an organisation's data practices?

I track a small set of practical indicators rather than a single maturity score, because a single score tends to hide where the actual problems are. I look at data quality incidents per month and whether that trend is falling, the percentage of critical datasets with a named owner and an up to date definition, how long it takes to answer a new data request, since a slow answer usually means people don't trust the existing data enough to self-serve, and how often the same question gets asked twice because the answer wasn't documented anywhere findable. I also pay attention to a softer signal: whether people in meetings cite the dashboard numbers directly or quietly recalculate them in a spreadsheet first, since that habit is the clearest sign that trust in the data hasn't actually been earned yet.

Tell me about a time you pushed back on a business stakeholder who wanted to bypass data governance to move faster.

A sales operations lead wanted to load a purchased contact list directly into the CRM ahead of a campaign launch, skipping the usual validation and deduplication step to hit a Friday deadline. I didn't just say no. I explained the specific risk: the list had no verification against our existing suppression list, so we risked emailing contacts who had already opted out, which is a genuine compliance problem, not just a tidiness one. I offered a compressed version of the validation process, about four hours instead of the usual two days, running only the checks tied to actual legal risk and deferring the cosmetic cleanup. The campaign launched about half a day later than originally planned. Afterwards the sales operations lead asked me to build that compressed path as a standard option for time-sensitive campaigns, which is now documented as our expedited review process.

Describe how you've managed and developed a small team of data analysts or data stewards.

I managed a team of three data stewards, each responsible for a different business domain: customer, product, and finance data. Early on I noticed one steward was excellent at technical documentation but avoided the stakeholder conversations needed to resolve data ownership disputes, which meant issues in his domain stayed unresolved longer than the others. Rather than working around it, I paired him with the steward who was strongest at stakeholder conversations for a joint session on a specific dispute, then had him lead the next one solo with me observing. Within two months he was running those conversations independently. I hold monthly one to ones focused specifically on what's blocking their domain, not general status updates, since the blockers are usually where I can actually help, and I've found that specific, current blockers get resolved much faster than anything raised in a general catch-up.

Tell me about a data breach or near-miss you handled, and what changed afterwards.

A contractor was given broader access to a customer database than their project required, and we discovered it during a routine access review, three weeks after the access was granted, with no evidence it had been misused. I treated it as a near-miss requiring the same rigour as an actual incident: I documented the timeline, revoked the excess access immediately, and worked with IT to confirm no data had actually left the system through logs and export records. The root cause was that access requests were approved by a single manager without a second check against the principle of least privilege. I introduced a two-person approval step for any access above standard read-only, and added a quarterly access review specifically for contractors rather than folding it into the general annual review, since contractor access changes far more often than employee access.

How do you approach GDPR or data privacy compliance in practice, not just in policy?

I start from the specific data flows, not the regulation text, because compliance failures usually happen in a process nobody mapped rather than a policy nobody wrote. I maintain a record of processing activities that lists what personal data we hold, why, where it's stored, and who can access it, and I update it whenever a new system or integration is added, not just annually. For subject access and deletion requests, I've built a checklist that covers every system holding personal data, including the ones people forget, like backups and third-party analytics tools, since a technically correct deletion in the primary database that leaves data sitting in an old export is still a compliance gap. I also run a lightweight privacy review before any new tool or vendor is onboarded, checking their data processing agreement and where they store data, rather than treating that as legal's job alone.

What do you look for in a data catalogue or metadata management tool, and how have you used one?

I look for three things: how easily non-technical users can search and understand a dataset without asking someone on the data team, how well the tool tracks lineage so I can trace a number in a report back to its source tables, and how much manual upkeep it requires, since a catalogue that needs constant manual tagging tends to go stale within a few months. I've used Collibra and also a lighter open-source setup built on top of dbt's documentation and lineage graph for a smaller team that didn't need the full governance workflow features. The lighter setup worked better for that team specifically because adoption depended on the tool being nearly invisible: engineers documented things as part of their normal workflow rather than as a separate governance task, which meant the documentation actually stayed current.

How do you prioritise between data governance work and data engineering infrastructure fixes when they compete for the same resources?

I frame both in terms of risk and cost of delay rather than treating governance as inherently secondary to infrastructure, which is the default assumption in a lot of organisations. A pipeline outage that stops a daily report is visible and urgent, but a governance gap, like an undocumented dataset feeding a regulatory report, can be just as costly if it surfaces during an audit, it's just less visible day to day. I work with the data engineering lead to score both types of work on the same scale: business impact if left unaddressed, and effort to fix, then sequence the backlog together rather than governance and engineering running two separate, competing lists. When the two directly conflict for the same sprint capacity, I default to whichever failure would be harder to explain to a regulator or an executive after the fact, which tends to make the trade-off concrete rather than abstract.

Data Manager

Data Manager interviews test something different from a Data Analyst or Data Engineer interview: whether you can make an organisation trust its own data. Interviewers want to see a clear approach to governance, quality, and compliance, plus the judgement to know when a rule needs enforcing and when it needs revisiting. This guide covers the questions asked most often and the answers that show you can bridge the technical and business sides of data.

For general interview preparation tips, read our guide to common interview questions.

Prepare further

How to ace the behavioural interview (STAR method)How to prepare for a technical interview

Common Data Manager Interview Questions

Behavioural Interview Questions for Data Manager Roles

Technical Questions for Data Manager Candidates

What Hiring Managers Look for in Data Manager Interviews

What hiring managers really look for in Data Manager candidates:

Judgement about which rules matter. A governance framework that tries to control everything usually controls nothing effectively.
Comfort saying no to a stakeholder, but always with an alternative attached, not just enforcement for its own sake.
Fluency in both directions: technical enough to work with data engineering, business-fluent enough to explain a data quality issue to an executive without jargon.
Evidence of real compliance work, not just policy knowledge. Specific detail about deletion requests, access reviews, or breach handling is the tell.
A track record of developing the people on their team, not just managing tasks and tickets.

Questions to Ask Your Interviewer

→How is data ownership currently split between the data team and the business units that generate the data?
→What does the current data quality incident process look like, and how often does it get used?
→How much of the data governance work here is policy versus actually embedded in the tools and pipelines?
→What is the relationship like between the data team and data engineering: separate roadmaps, or one shared backlog?
→What would success look like for this role in the first six months?

Practise These Questions Before Your Interview

The mock interview tool builds a practice session around a specific job posting and your background, so you rehearse the questions most likely to come up.

Start Practising

Free to start. No commitment.

Related Roles

Available in Other Languages

Français Español