Most hiring processes for data roles are optimizing for the wrong things. Certifications, technology lists, years of experience — these are proxies. Imperfect ones. After years of building and leading data teams in regulated financial environments, here's what I've learned actually separates the people who move organizations forward from those who just occupy a seat.
The Question That Filters 80% of Candidates
I ask every candidate, early in the conversation: Tell me about a time the data was wrong and you were the last line of defense.
Not "tell me about a bug you fixed." Not "describe a challenging project." Specifically: wrong data, real consequences, and you standing between it and something bad happening downstream.
The good candidates have a story. Usually more than one. They describe what they detected, how they investigated, what they escalated versus what they resolved themselves, and critically — what they changed after so it couldn't happen again.
The weak candidates describe technical work. The strong ones describe judgment.
What I've Stopped Caring About
Certification lists. I have Oracle certifications myself. They matter for establishing baseline competence — they don't tell me whether someone can think under pressure, communicate with non-technical stakeholders, or take ownership when things break at 11pm on a Friday before a regulatory submission.
Trendy technology stacks. The teams I've watched struggle most are the ones that chased technology adoption without establishing the operational discipline to run it reliably. Give me someone who runs a well-governed Oracle environment over someone who's deployed three different "modern" tools that nobody fully understands.
Impressive-sounding titles from large organizations. Big companies produce specialists who've never had to think end-to-end about a problem. I want people who've had to own something entirely — architecture, implementation, operations, and accountability for outcomes.
What I Do Care About
Communication across levels. Data professionals who can only talk to other data professionals are a liability in any mature organization. I want to see evidence that someone has explained a data quality issue to a finance director, pushed back on an unrealistic deadline from a regulatory team, or built enough trust with a business stakeholder to get resources for infrastructure nobody can see.
Operational instinct. Do they think about failure modes before they build? Do they ask about monitoring before asking about features? Do they distinguish between what's technically possible and what's operationally maintainable by a team over time?
A track record of finishing things. Startups and large enterprises both produce people who prototype beautifully and deliver inconsistently. I look for evidence of things actually shipped, adopted, and running in production — not just designed.
The Hardest Thing to Screen For
Integrity about data. The willingness to say "this number is wrong" when a manager wants it to be right. The discipline to report a data issue instead of finding a workaround that technically produces the expected output.
In regulated financial services, this isn't a soft skill. It's the difference between a company that passes its audits and one that doesn't.
I ask about it directly in interviews. I check references specifically on this point. And I watch for it in the first three months on the job — because that's when the culture either reinforces it or erodes it.
Hiring well in data is hard because the skills that matter most are the hardest to see on paper. The best hires I've made came from people who were honest about what they didn't know, specific about what they'd actually built, and clear about what they cared about. That profile doesn't always come with the most impressive CV.