Data Manager Interview Questions With Model Answers

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.