Six question sets written for the employer side of the table: 40+ questions with the reason each one is worth asking and what a strong answer sounds like, plus a live design exercise and an eight-area scorecard. Download as DOCX.
The first data architect candidate I ever interviewed drew a beautiful diagram on the whiteboard within ninety seconds of hearing the problem. It had seven boxes, a streaming layer, and a catalog. He never asked how much data we had. We had almost none.
That interview taught me the thing this page is built around: for a data architect, the questions the candidate asks are better evidence than the answers they give. The failure mode is not incompetence, it is calibration. Plenty of genuinely excellent architects are calibrated to an organization with a platform team, a security team, and a budget line you do not have.
At FirstHR, we build for companies hiring senior people without an HR department, where the founder runs every round personally. This page gives you 40+ interviewer questions in six sets, each with the reason it is worth asking and what a strong answer sounds like, plus a live design exercise and a scorecard. If you still need the posting, start with the data architect job description.
TL;DR
A data architect interview has to test five things: modeling and architecture fundamentals, system design judgment, governance and data quality, platform and cost ownership, and communication with non-technical stakeholders. Ask the same core questions of every candidate in the same order, run one live design exercise on a real problem from your business, weight the questions the candidate asks you above the diagram they draw, and score eight areas from 1 to 5 with written evidence.
What the Interview Has to Test
Five things, in this order: modeling and architecture fundamentals, system design judgment, governance and data quality, platform and cost ownership, and communication with non-technical stakeholders. A candidate can be excellent on the first and unusable at a small company because of the last two.
Architecture fundamentals are the entry ticket. What actually separates candidates is judgment: whether they right-size a design to your data volume, whether they interrogate a requirement before building it, and whether they have ever owned the consequences of a design after it shipped. Those are visible in an interview if you ask for consequences rather than definitions.
What to test
The question that reveals it
Architecture fundamentals
Walk me through a design end to end, from data created to acted on
System design judgment
The live exercise: what do they ask before they draw anything
Governance and data quality
Two reports disagree on revenue. How do you find out which is right
Security and access design
How do you decide who gets access to which data, and who reviews it
Platform and cost ownership
What was the monthly bill for the last platform you designed
Fit for your stage
What share of last year was hands-on versus documents and reviews
The last row is the one small companies skip and then regret. Ask it early, not as a closing pleasantry, because the answer determines whether the rest of the interview is even relevant to your situation.
Architect, Engineer, or DBA?
A data architect designs the blueprint, a data engineer builds and runs the pipelines, and a database administrator keeps specific databases healthy and secure. Confirm which one you actually need before you interview, because the three titles are used interchangeably and the interviews should not be.
At a small company, one person frequently does all three. That is fine, but it has to be said out loud in the interview rather than assumed, because a candidate arriving from a large data organization may be picturing a very different job. If your pressing need is nightly loads that do not break, look at the data engineer or database administrator descriptions first.
Responsibility
Data Architect
Data Engineer
DBA
Designs the overall data model and estate
Builds and maintains pipelines day to day
Tunes, backs up, and secures specific databases
Sets access, retention, and governance rules
Owns platform selection and cost
Use the table as a conversation opener rather than a rulebook. Show the candidate which rows the job covers at your company and ask which ones they have genuinely owned. The mismatches surface in about two minutes, which is far cheaper than surfacing them in month four.
The Six Question Sets
The questions below are grouped into five sets plus a scorecard. Each set targets a different failure mode, so a strong candidate should hold up across all of them rather than only in the area they are most rehearsed for.
Core Architecture
Modeling fundamentals
OLTP versus OLAP, normalization, dimensional modeling, changing dimensions, and the hands-on split. Ask these of every candidate, in the same order.
System Design Exercise
Live, 30 to 45 minutes
One real problem from your business, given to every candidate, scored mostly on the questions they ask before they draw anything.
Governance and Security
Trust and access
Conflicting numbers, quality checks, lineage, access design, personal data, retention, and whether they will push back on a risky request.
Cloud and Platform
Cost and migration
The monthly bill, migrations that broke, managed versus build, lock-in, and what would justify a bigger platform than you need today.
Stakeholder and Behavioral
Past behavior, named
Metric disputes, telling a leader no, documentation that survives them, projects they stopped, and working as the only data person.
Scorecard and Red Flags
Decide on evidence
Eight scoring areas at 1 to 5 with written evidence, nine red flags, and reference-check prompts written for a privileged-access role.
Weight the Questions the Candidate Asks You
Across every set, the single most predictive signal for this role is what the candidate asks before answering. An architect who asks about data volume, source count, consumers, budget, and who maintains it is doing the job in front of you. One who produces a recommendation without a qualifying question is showing you exactly how they will behave in week two. Score their questions on the same 1-to-5 scale you use for their answers.
40+ Questions and a Scorecard to Download
Download all six as a single Word document or copy individual sets. Each set lists when to use it, the questions with why each is worth asking and what a strong answer sounds like, what to listen for, and space for notes. The last file is the scorecard. Sets for other roles sit in the hiring templates library.
Download All 6 Data Architect Question Sets
Core architecture, live design exercise, governance and security, cloud and cost, behavioral, and an eight-area scorecard. All in one DOCX.
Set 1: Core Architecture and Modeling Questions
Eight foundation questions: OLTP versus OLAP, normalization trade-offs, dimensional modeling in plain language, changing dimensions, warehouse versus lake, a decision they got wrong, and the hands-on split. Ask these of every candidate.
Core Data Architecture and Modeling Questions
DATA ARCHITECT INTERVIEW: CORE ARCHITECTURE AND MODELING
Candidate: __
Company: __
Interviewer: __
Date: _
HOW TO USE THIS SET
This is the foundation set. Ask six to eight of these of every candidate, in the
same order, and score them on the rubric in Set 6. Each question lists why it is
worth asking and what a strong answer sounds like, so the person running the
interview can grade the answer without being a data specialist.
QUESTIONS
1. Walk me through a data architecture you designed end to end. What did the
data do from the moment it was created to the moment someone acted on it?
Why ask: an architect is hired for the whole picture, not one layer. This is
the fastest way to find out whether they owned a design or contributed to one.
Strong answer: names the sources, the ingestion method, where data landed, how
it was modeled, who consumed it, and at least one trade-off they chose and why.
Weak answer: describes a tool stack with no reasoning and no ownership.
2. Explain the difference between OLTP and OLAP systems, and how that changed a
design decision you made.
Why ask: this is the single most load-bearing distinction in the job, and the
second half of the question separates recall from applied judgment.
Strong answer: transactional systems are optimized for many small writes and
row-level access; analytical systems for large scans and aggregation. Then a
real example: they stopped reporting queries hitting the production database.
Weak answer: a textbook definition with no consequence attached.
3. When do you normalize, and when do you deliberately denormalize?
Why ask: tests whether the candidate designs for the workload or applies one
pattern everywhere. Small companies pay for over-engineered models.
Strong answer: normalize where write integrity matters, denormalize where read
performance and simplicity matter, and names the cost of each choice.
Weak answer: treats normalization as always correct, or never mentions cost.
4. Explain dimensional modeling to me as if I run the sales team, not engineering.
Why ask: the architect has to sell a design to people who fund it. If they
cannot explain a star schema in plain words, they cannot get one approved.
Strong answer: facts are the events you measure, dimensions are the things you
slice by, and a plain business example follows within a sentence or two.
Weak answer: retreats into vocabulary, or says it depends without unpacking it.
5. How do you handle a dimension whose values change over time, for example a
customer who moves to a different sales region?
Why ask: slowly changing dimensions are where naive designs quietly break
historical reporting. This is a practical, non-trivia depth check.
Strong answer: distinguishes overwriting from keeping history, explains which
the business needs and why, and mentions the reporting consequence of each.
Weak answer: has never thought about history and treats the record as current.
6. Data warehouse, data lake, or lakehouse for a company our size? Talk me
through the decision, not the definition.
Why ask: architects at large companies default to the biggest option. You need
someone who will right-size the platform to your data volume and budget.
Strong answer: asks about volume, sources, team size, and budget before
answering, then recommends the smallest thing that meets the requirement.
Weak answer: recommends a large platform without asking a single question.
7. Tell me about an architecture decision you got wrong. What did it cost, and
what did you change?
Why ask: senior technical candidates who cannot name a mistake usually have
not owned outcomes long enough to see one land.
Strong answer: a specific decision, a specific consequence, and the change
they made, without blaming the previous team for all of it.
Weak answer: a non-answer mistake, or a story where everyone else was at fault.
8. What percentage of your last year was hands-on building versus design
documents, reviews, and standards?
Why ask: this is the most important question on the page for a small company.
Many architects have not written production code or SQL in years.
Strong answer: a specific split, with examples of what they actually built,
and a straight answer about how hands-on they want to be next.
Weak answer: treats hands-on work as beneath the role.
WHAT TO LISTEN FOR
•Reasoning and trade-offs, not tool names
•Questions asked back about your volume, sources, and budget
•Plain-language explanation of technical choices
•Honesty about mistakes and about how hands-on they are
NOTES
__
__
Set 2: System Design Exercise and Scoring Guide
A live 30-to-45-minute exercise with a ready-made prompt you can swap for your own situation, plus six scoring dimensions weighted so that the questions they ask before designing count most.
System Design Exercise and Scoring Guide
DATA ARCHITECT INTERVIEW: LIVE SYSTEM DESIGN EXERCISE
Candidate: __
Interviewer: __
Time: 30 to 45 minutes
WHY RUN THIS INSTEAD OF A TAKE-HOME
Data architects are hired for judgment, and judgment shows up in the questions
they ask before they draw anything. A take-home hands them a defined problem and
removes the part you most need to see. Give every candidate the same real problem
from your business, anonymized, and score the reasoning rather than the diagram.
THE PROMPT (REPLACE WITH YOUR OWN SITUATION)
"We have order data in our e-commerce platform, customer records in our CRM,
support tickets in a help desk tool, and a spreadsheet the finance team maintains
by hand. Leadership wants one weekly view of revenue by customer segment, and
nobody trusts the numbers today. You have one person and a modest budget. Design
something we could run within a quarter."
Use the same prompt for every candidate. Do not help them for the first five
minutes.
WHAT TO SCORE, IN ORDER OF WEIGHT
1. The questions they ask before designing (heaviest weight)
Strong: how much data, how often does it change, who consumes it, what
decision does the weekly view drive, what is the budget, who maintains it.
Weak: starts drawing boxes immediately.
2. Scoping to your size
Strong: proposes the smallest architecture that satisfies the requirement and
names what they are deliberately leaving out for later.
Weak: proposes a platform that needs a team you do not have.
3. Handling the untrusted numbers
Strong: goes after definitions and ownership first, because "nobody trusts the
numbers" is usually a governance problem, not a pipeline problem.
Weak: assumes a new tool will fix trust.
4. The hand-maintained spreadsheet
Strong: treats it as a real source with a real owner, and proposes a path that
does not depend on the finance team changing how they work overnight.
Weak: dismisses it or plans to delete it.
5. Failure and cost
Strong: says what breaks first, how they would know, and what it costs monthly.
Weak: never mentions cost or monitoring.
6. Explaining it back
Strong: can summarize the design in two minutes to a non-technical listener.
Set 3: Data Governance, Quality, and Security Questions
Conflicting numbers, quality checks built into pipelines, lineage that has actually saved them, access design, personal data and deletion, offboarding, and whether they will push back on a risky request.
Data Governance, Quality, and Security Questions
DATA ARCHITECT INTERVIEW: GOVERNANCE, QUALITY, AND SECURITY
Candidate: __
Interviewer: __
WHEN TO USE THIS SET
Use every question here. A data architect decides who can see what, how long you
keep it, and whether anyone can trust a number. At a small company there is no
separate governance function, so this is part of the hire rather than a later
addition. These questions also surface how the candidate thinks about risk.
QUESTIONS
1. Two reports show different revenue numbers for the same month. Walk me
through how you find out which one is right.
Why ask: this is the most common data problem at a small company, and the
answer reveals method rather than opinion.
Strong answer: traces both back to the source, compares the definitions and
filters, and treats the disagreement as a definition problem until proven
otherwise. Ends with a single owned definition, not a patched report.
Weak answer: guesses which system is more reliable and moves on.
2. How do you build data quality checks into a pipeline rather than bolting them
on afterward?
Why ask: quality checks added later never get added. This separates people who
design for it from people who firefight.
Strong answer: names concrete checks (row counts, freshness, null and range
rules, referential checks), where they run, and who gets alerted.
Weak answer: talks about quality as a culture with no mechanism.
3. What is data lineage, and when has it actually saved you?
Why ask: lineage sounds like an enterprise luxury until a number changes and
nobody knows why. The saved-you half is the real question.
Strong answer: defines it as knowing where a field came from and what depends
on it, and gives a concrete incident where it shortened an investigation.
Weak answer: names a cataloging tool without a story.
4. How do you decide who gets access to which data, and how is that reviewed?
Why ask: the architect designs your access model. Getting this wrong is how
small companies leak customer or payroll data internally.
Strong answer: least privilege by role, sensitive fields separated or masked,
access granted through a documented request, and a periodic review.
Weak answer: everyone gets read access because the team is small.
5. How do you handle personal data: identifying it, protecting it, and deleting
it when you are supposed to?
Why ask: state privacy laws and customer contracts increasingly require a
defensible answer, and the architecture determines whether you can give one.
Strong answer: classifies sensitive fields, applies masking or encryption,
knows retention has to be designed in, and can describe deleting a record
across downstream copies rather than only in the source system.
Weak answer: treats privacy as legal’s problem.
6. How would you make sure a departing employee, including you, loses access
cleanly?
Why ask: architects hold privileged credentials. A candidate who has thought
about their own offboarding has run a real system.
Strong answer: access tied to identity rather than shared accounts, an
offboarding checklist, and rotation of any shared secret.
Weak answer: has never thought about it.
7. Tell me about a time you pushed back on a request because of a data risk.
Why ask: you need someone who will say no to a convenient shortcut with
customer data, including when the person asking is the founder.
Strong answer: a specific request, the specific risk, and the alternative they
proposed. Pushing back with an alternative is the mark of a senior person.
Weak answer: has never pushed back, or pushed back without offering a path.
WHAT TO LISTEN FOR
•Mechanisms and checklists, not intentions
•Least privilege treated as normal, not as distrust
•Retention and deletion designed in rather than promised
•Willingness to say no with an alternative attached
NOTES
__
Set 4: Cloud, Platform, and Migration Questions
The monthly bill and how they controlled it, a migration that broke, managed services versus building, vendor lock-in, unnecessary streaming, and what would justify a bigger platform than you need today.
Cloud, Platform, and Migration Questions
DATA ARCHITECT INTERVIEW: CLOUD, PLATFORM, AND MIGRATION
Candidate: __
Interviewer: __
WHEN TO USE THIS SET
Use this set when the role involves choosing a platform, moving off one, or
controlling what you already pay for. Most small companies are hiring an
architect at exactly one of those three moments. Skip the questions that do not
match your situation rather than asking all of them.
QUESTIONS
1. What is the monthly cost of the last platform you designed, and how did you
control it?
Why ask: cloud data platforms bill by consumption, and an architect who has
never owned the invoice will design something you cannot afford.
Strong answer: a real number, the main cost drivers (storage, compute, egress,
idle warehouses), and specific levers they used to bring it down.
Weak answer: never saw the bill, or treats cost as someone else’s concern.
2. Walk me through a migration you led. What broke, and what did you do about it?
Why ask: migrations are where architecture meets reality. The failure half is
where the useful information lives.
Strong answer: a phased plan, parallel running, a rollback position, and a
specific thing that broke with a specific fix.
Weak answer: a clean story with no problems, which usually means they watched.
3. How do you decide between managed services and building it yourself?
Why ask: at your size, the right answer is usually managed. You want to hear
the reasoning, not a preference.
Strong answer: weighs team size and maintenance burden against control and
cost, and lands on managed for a small team unless there is a real reason.
Weak answer: defaults to building because it is more interesting.
4. How much do you worry about vendor lock-in, and what do you do about it?
Why ask: this question separates pragmatists from purists. Both extremes cost
money at a small company.
Strong answer: accepts some lock-in as the price of speed, and protects the
parts that are expensive to move, usually raw data and transformation logic.
Weak answer: refuses all managed services, or has never considered the exit.
5. How do you handle real-time or near-real-time requirements when someone asks
for them?
Why ask: streaming is frequently requested and rarely needed. This tests
whether the candidate will interrogate a requirement.
Strong answer: asks what decision changes with fresher data, and proposes more
frequent batch loads unless the use case genuinely requires streaming.
Weak answer: builds streaming because it was asked for.
6. Our data volume is modest today. What would make you recommend a bigger
platform, and what would you do until then?
Why ask: forces the candidate to commit to a threshold rather than a
philosophy, and tells you whether they will over-build on day one.
Strong answer: names concrete triggers (volume, concurrency, query times, team
size) and proposes a simple interim design that can be grown into.
Weak answer: recommends the destination architecture immediately.
WHAT TO LISTEN FOR
•Real cost numbers and named cost levers
•Migration stories that include failures
•A bias toward managed services for a small team
•Requirements interrogated before they are built
NOTES
__
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
Metric definition disputes, telling a leader something is not feasible, documentation that survives them leaving, a project they stopped, working as the only data person, and the questions they ask you.
Stakeholder and Behavioral Questions
DATA ARCHITECT INTERVIEW: STAKEHOLDER AND BEHAVIORAL
Candidate: __
Interviewer: __
WHEN TO USE THIS SET
A data architect at a small company spends as much time negotiating definitions
and expectations as designing systems. Ask for past behavior with named
situations rather than hypotheticals, and use the STAR pattern to evaluate the
answer: Situation, Task, Action, Result. Push for the Result every time.
QUESTIONS
1. Tell me about a time two teams disagreed about the definition of a core
metric. How did it end?
Why ask: this is the daily work. The ending tells you whether they can drive a
decision or only document a disagreement.
Strong answer: a specific metric, how they got the parties in one room, an
owner assigned to the definition, and it written down where people look.
Weak answer: escalated it and waited.
2. Describe a time you had to tell a leader that what they wanted was not
feasible on the timeline or budget. What did you offer instead?
Why ask: you are hiring someone who will have to tell you no. How they do it
matters more than whether they will.
Strong answer: direct, unemotional, with a smaller alternative that delivered
part of the value on the original date.
Weak answer: either never pushes back, or pushes back with no alternative.
3. How do you document architecture so it survives you leaving?
Why ask: at a small company the architect is often the only person who
understands the system. Documentation is a business continuity question.
Strong answer: describes what they document (decisions and reasons, not just
diagrams), where it lives, and how it stays current.
Weak answer: documentation as an afterthought or a one-time deliverable.
4. Tell me about a project you stopped or scaled back. What made you call it?
Why ask: architects who have never killed their own project have usually not
been accountable for outcomes.
Strong answer: a real project, the signal that made them stop, and what they
did with what had already been built.
Weak answer: cannot name one.
5. You are likely to be the only data person here for a while. How does that
change how you work?
Why ask: a candidate from a large data organization may be dependent on
platform, analytics, and security teams that you do not have.
Strong answer: acknowledges they will build, run, and support their own work,
and describes how they would prioritize when everything is theirs.
Weak answer: assumes support functions exist.
6. What would you want to be true after your first 90 days here?
Why ask: the answer shows what they think the job is, and whether they
listened to what you described.
Strong answer: something concrete, modest, and tied to what you said you need,
usually one trustworthy reporting path rather than a platform rebuild.
Weak answer: a generic multi-year roadmap.
7. What questions do you have for us?
Why ask: the questions a senior technical candidate asks are diagnostic. Score
them the same way you score answers.
Strong answer: asks about data ownership, who consumes the output, budget,
what has already been tried, and who decides.
Weak answer: no questions, or only questions about title and equipment.
WHAT TO LISTEN FOR
•Named situations with dates and outcomes
•Comfort disagreeing with senior people, constructively
•Realism about working without a supporting team
•Modest, concrete first-90-days goals
NOTES
__
Set 6: Scorecard and Red Flags
Eight scoring areas at 1 to 5 with a line of evidence each, nine red flags, and five reference-check prompts written specifically for a role that will hold privileged access to your data.
Data Architect Scorecard and Red Flags
DATA ARCHITECT INTERVIEW SCORECARD AND RED-FLAG CHECKLIST
Candidate: __
Company: __
Interviewer: __
Date: _
HOW TO SCORE
Score every area from 1 to 5 immediately after the interview, while the answers
are fresh, and write one line of evidence next to each score. If more than one
person interviews, everyone scores alone before the group talks, so the most
senior voice does not set the tone. Use the same rubric for every candidate.
5 = Strong, specific evidence 4 = Solid evidence 3 = Some evidence
2 = Weak or mixed evidence 1 = No evidence or red flags
SCORING AREAS
Modeling and architecture fundamentals
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
System design judgment: right-sized the solution, asked questions first
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Governance, quality, and data trust
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Security and access design
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Platform and cost ownership
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Hands-on capability at our stage
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Communication with non-technical stakeholders
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Ownership and accountability
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
RED FLAGS (WEIGH CAREFULLY)
[ ] Designs before asking about volume, budget, or who consumes the output
[ ] Has not touched SQL, code, or a console in years and does not want to
[ ] Cannot name an architecture decision that turned out wrong
[ ] Recommends an enterprise platform without a single qualifying question
[ ] Has never seen the monthly bill for anything they designed
[ ] Treats access control and retention as somebody else’s job
[ ] Cannot explain a design in plain language to a non-technical listener
[ ] Every example depends on platform, security, or analytics teams you lack
[ ] No questions for you at the end
REFERENCE CHECK PROMPTS (FOR A PRIVILEGED-ACCESS ROLE)
1. What did this person actually build, versus specify for others to build?
2. How did they handle sensitive or personal data?
3. How did non-technical stakeholders describe working with them?
4. What happened to the systems they designed after they left?
5. Would you hire them again for a team with no dedicated platform support?
Grade what you can judge without the vocabulary, and borrow help for the rest. Four signals are visible to any interviewer, and together they predict fit at a small company better than a technical duel you cannot referee.
Did the candidate ask about your volume, budget, and consumers before proposing anything. Can they explain a design in plain words. Can they name a decision that turned out wrong. Have they seen the bill for something they built. The examples below show what each looks like in practice.
Data warehouse, data lake, or lakehouse for a company our size?
Strong answer: A strong candidate asks before answering: how much data, how many sources, who consumes it, what is the budget, who maintains it. Then recommends the smallest thing that meets the requirement and names what they are deliberately leaving out until a trigger is hit.
Weak answer: A weak answer recommends a large platform in the first sentence, without asking a single question about your volume, your team, or your budget.
Two reports show different revenue for the same month. Which one is right?
Strong answer: A strong candidate treats it as a definition problem until proven otherwise: trace both numbers to the source, compare the filters and the business rules behind each, then assign one owner to one definition and write it down. The fix ends with a single definition, not a patched report.
Weak answer: A weak answer picks the system that feels more reliable, adjusts the report that disagrees, and never asks how each number was defined.
What was the monthly cost of the last platform you designed?
Strong answer: A strong candidate gives a real number, names the main drivers such as storage, compute, and idle warehouses, and describes a specific change they made to bring it down. Cost ownership is one of the clearest signals that they ran a system rather than specified one.
Weak answer: A weak answer has never seen the invoice, or treats cost as a finance concern that arrives after the design is finished.
What percentage of your last year was hands-on versus design documents?
Strong answer: A strong candidate gives a specific split, names what they actually built, and answers straight about how hands-on they want the next role to be. At a small company you usually need someone above 50 percent hands-on for the first year.
Weak answer: A weak answer is evasive, or treats writing SQL and fixing pipelines as beneath the title. That mismatch is the most expensive hiring error in this role.
For the modeling depth you genuinely cannot assess, bring one senior technical person from your network in for a single round and hand them the same scorecard. Then check references with the prompts in Set 6, which are written to distinguish what a candidate built from what they specified for other people to build.
Governance, Security, and Privileged Access
A data architect decides who can see what, how long you keep it, and whether anyone can trust a number, so governance and security belong in the interview rather than in a later policy exercise. At a small company there is no separate governance function to catch what the architect misses.
Two federal resources are worth reading before you write these questions, because they tell you what a defensible answer looks like. The Federal Trade Commission publishes Protecting Personal Information, a plain-language guide for businesses that covers taking stock, scaling down, locking it, and disposing of it. The NIST Privacy Framework gives you the vocabulary for identifying, governing, and controlling personal data, which is useful for judging whether a candidate is describing a system or improvising.
Ask how they design access
The architect decides who can see payroll, customer, and revenue data. Listen for least privilege by role, masked sensitive fields, and a documented request path rather than blanket read access.
Ask how personal data is found and deleted
Retention and deletion have to be designed in. A strong candidate can describe removing a record across downstream copies, not only in the system where it was created.
Ask what saved them, not what they know
Lineage, cataloging, and quality checks all sound good in the abstract. The useful version of each question ends with when did this actually save you, which forces a real incident.
Check references on data handling
This role holds privileged credentials, so run a background check appropriate to the role and ask references directly how the candidate handled sensitive data.
Privileged Access Changes the Reference Check
A data architect will hold credentials to customer, revenue, and often payroll data within weeks of starting. That makes the reference call a security control, not a formality. Ask former colleagues what the candidate actually built rather than specified, how they handled sensitive data, and what happened to their systems after they left. Pair the reference check with a background check appropriate to the role and a signed confidentiality agreement in the offer packet. This is general information, not legal advice.
Scoring and the Red Flags That Matter
Score eight areas from 1 to 5 immediately after each interview, with one line of written evidence next to every score. Fresh scores anchored to something the candidate said are the only reliable way to compare four conversations that happened on four different days.
Scoring area
What a 5 looks like
Modeling and fundamentals
Explains trade-offs with consequences, not definitions
System design judgment
Asked qualifying questions first, right-sized the answer
Governance and data trust
Treats conflicting numbers as a definition problem with an owner
Security and access design
Least privilege by role, retention and deletion designed in
Platform and cost ownership
Real monthly numbers and specific levers they pulled
Hands-on capability
A specific split and examples of what they personally built
Communication
Explains a star schema to a non-technical listener in a sentence
Ownership
Names a decision that went wrong and what it cost
The red flags in Set 6 matter most in combination. A candidate who starts designing before asking anything, has not been hands-on in years, and needs a platform team to exist is not a weak architect; they are calibrated to an organization you are not. Use a consistent evaluation form so that pattern is visible on paper.
If more than one person interviews, everyone scores alone before the group discusses. This matters more than usual when one interviewer is technical and the others are not, because the technical voice otherwise sets the verdict and the plain-language observations quietly disappear. Structured interview feedback keeps both on the record.
Pay Context Before You Ask About Expectations
Know the federal benchmark before you discuss compensation, and raise the range in the first screen rather than the final round. Senior technical candidates withdraw late when the number arrives late, and at a small company a wasted four-stage loop is expensive.
Median $139,500 a Year (BLS OEWS, May 2025)
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), database architects had a national median annual wage of $139,500, about $67.07 an hour, with the 10th percentile at $86,240, the 25th at $109,370, the 75th at $169,290, and the 90th at $204,000. Database administrators, a useful anchor for a role that leans toward running databases, reported a median of $104,620 in the same survey. Overall employment of database administrators and architects is projected to grow 4 percent from 2024 to 2034, with about 7,800 openings a year (U.S. Bureau of Labor Statistics).
Database architects is the federal occupation that maps most closely to the title, though many people called data architects sit near it rather than squarely in it. Regional differences are large on this occupation, so benchmark to your metro and to the seniority you actually need, then set a range you can defend to every candidate equally.
Fair, Legal, and Structured Interviewing
Fair, legal, and structured are the same discipline seen from three angles. Asking the same job-related questions of every candidate keeps you compliant, reduces bias, and produces better hires at once. Generic question lists skip this part entirely.
Ask about the job, not the person
Federal anti-discrimination law, enforced by the EEOC, prohibits basing hiring decisions on protected characteristics, and questions that touch them create risk even when they arrive as friendly small talk. Senior technical interviews drift here easily. Do not ask what year someone graduated, where they are originally from, whether they plan to have children, how they would handle on-call around family, or any health or accommodation question outside the essential functions of the job. You may ask whether the candidate can perform the essential functions and whether they are legally authorized to work in the United States. Every question in the sets above is written to stay on the job. This is general information, not legal advice.
Same core questions, same order, every candidate
Asking each candidate the same core questions is both fairer and more predictive than a free-flowing technical conversation. It matters more than usual for a data architect, because the subject invites tangents: one candidate gets forty minutes on cloud platforms because that is where the conversation drifted, another gets forty minutes on modeling, and at the end you have no comparable evidence. Write the question set before the first interview, keep the order fixed, and use the same live design prompt for everyone. Consistency is what turns four conversations into a comparison.
Score alone, then discuss
When several people interview, have each one fill in the scorecard privately before the group talks. This is especially important when one interviewer is technical and the others are not, because the technical voice will otherwise set the verdict and the non-technical observations, which are often the more predictive ones, quietly disappear. Compare written scores and evidence first, then discuss the gaps. A candidate who scores 5 on modeling and 2 on plain-language explanation is a real risk at a small company, and only an independent scorecard surfaces that.
Do not screen on credentials you did not require
Decide the real requirements before you interview, and hold every candidate to the same bar. Data architect candidates arrive from very different paths: database administration, engineering, analytics, and consulting. If you did not put a specific degree or certification in the posting, do not let it become a tiebreaker in the room, because inconsistent criteria applied after the fact are both unfair and hard to defend. Write down what the role must accomplish in the first year, and score against that.
Same Questions, Scored on a Rubric, Predict Better Hires
A structured interview, where every candidate answers the same questions scored against a consistent rubric, predicts on-the-job performance more reliably than an unstructured conversation. Asking the same job-related questions of everyone also keeps you within the EEOC rules against basing decisions on protected characteristics. Structure is both the fairer approach and the more effective one.
Keep every question tied to the job and avoid the small-talk traps about age, graduation year, origin, family plans, or health. The question sets above are written to stay on the job. For a fuller list of what not to ask, see the guide to illegal interview questions. This is general information, not legal advice.
Interviewing a Data Architect Without HR
At a large company this candidate runs coordinated panels while a recruiter holds the scorecards. At a small business the founder runs every round alone, between everything else, and the three problems below are where those interviews go wrong.
You cannot grade the deepest technical answers yourself
Most owners hiring a first data architect are not data specialists, and the honest response is to grade what you can judge and borrow help for the rest. You can judge whether the candidate asked about your volume and budget before designing, whether they explained a star schema in plain words, whether they can name a decision that turned out wrong, and whether they have seen the bill for something they built. Those four signals separate strong architects from fluent ones more reliably than a whiteboard duel. For the modeling depth, bring one senior technical person from your network in for a single round, and give them the same scorecard everyone else is using.
The expensive mistake is hiring an architect when you needed an engineer
At a large company an architect sets standards and reviews designs while other teams build. At a small company the same title has to build. If your real need is pipelines that run every night, you may want a data engineer rather than an architect, and the interview should establish that before anything else. Ask for the hands-on split from the last year, and ask what they would personally build in the first 90 days. A candidate who describes governance councils and reference architectures is not wrong about the profession, they are wrong for your stage, and finding that out in the interview is far cheaper than finding it out in month four.
One person runs the whole loop between everything else
At a large company a data architect goes through coordinated panels with a recruiter holding the scorecards. At a small business the founder usually runs every round alone, which is why structure matters more here, not less: the same questions in the same order, the same design prompt, and a scorecard filled in before the next conversation blurs the last one. Once you choose someone, the work shifts to hiring well, and that is where FirstHR fits: the offer and confidentiality agreement sent for e-signature, the new hire paperwork, and an onboarding workflow that handles system access and policy sign-off. FirstHR is an onboarding and HR platform, not a data platform or an applicant tracking system, so pair it with those. Applicant tracking is coming soon to FirstHR.
None of this requires an HR department. It requires writing the questions down before the first conversation, using the same design prompt for everyone, and filling in a scorecard before the next candidate blurs the last one. That is the whole method, and it is what the hiring process looks like when one person is running it. Applicant tracking is coming soon to FirstHR, which will keep the candidates and the scorecards in one place.
From Interview to Onboarding
The interview is step one. Once you choose someone, the work shifts to hiring well: a written offer that states the scope and the hands-on expectation, a signed confidentiality agreement, access provisioned with least privilege, and a first 90 days with one agreed outcome.
Send the offer with scope in writing
Senior technical candidates accept on scope as much as on pay. Put the mandate, the reporting line, and the hands-on expectation in the offer, and send it for e-signature.
Get the confidentiality agreement signed
This hire will hold privileged access to customer, revenue, and employee data from an early date, so the agreement belongs in the same packet as the offer.
Provision access with least privilege
Grant access by role rather than by person, use named accounts instead of shared credentials, and record what was granted so offboarding is clean later.
Agree the first 90 days before day one
Write down the one outcome the first quarter has to produce, usually a single trustworthy reporting path, and review it at 30, 60, and 90 days.
Scope in writing matters more for this role than for most. A data architect who accepted a design mandate and arrives to find a pipeline backlog will leave within the year, so put the real split in the offer and in the new hire paperwork conversation. Applicant tracking is coming soon to FirstHR, and until it launches, run the interview records in whatever you already use.
FirstHR connects the offer, the confidentiality agreement, e-signatures, and the onboarding workflow in one place, and stores the signed documents on the employee profile, so a small business can run hiring-to-onboarding from one system. FirstHR is an onboarding and HR platform, not a data platform, so pair it with your stack. Use an onboarding template to give the new architect a structured start.
Key Takeaways
Test five things: modeling fundamentals, system design judgment, governance and data quality, platform and cost ownership, and plain-language communication.
Weight the questions the candidate asks before designing above the diagram they draw; it is the strongest single signal for this role.
Settle architect versus data engineer versus DBA before the interview, and ask for last year’s hands-on split early rather than as a closing pleasantry.
Run one live design exercise on a real anonymized problem from your business and give every candidate the same prompt.
Governance and access design belong in the interview, because at a small company nobody else will catch what the architect misses.
Benchmark pay against the federal database architects occupation, a median of $139,500 a year in the May 2025 survey, and raise the range in the first screen.
Frequently Asked Questions
What questions should you ask a data architect in an interview?
Ask across five areas: modeling and architecture fundamentals, system design judgment, governance and data quality, platform and cost ownership, and stakeholder communication. The highest-signal questions are specific and consequence-bearing: walk me through an architecture you designed end to end, explain the difference between OLTP and OLAP and how it changed a decision you made, two reports show different revenue for the same month so how do you find out which is right, what was the monthly cost of the last platform you designed, and what percentage of last year was hands-on building versus design documents. Avoid definition trivia, because an architect is hired for judgment rather than recall. Every question on this page comes with a stated reason it is worth asking and a note on what a strong answer sounds like, so whoever runs the interview can score it.
What is the difference between a data architect, a data engineer, and a database administrator?
A data architect designs the blueprint: what data you hold, how it is modeled, where it lives, who can access it, and how the pieces connect. A data engineer builds and runs the pipelines that move and transform data according to that design. A database administrator keeps specific databases healthy, performant, backed up, and secure. At a large company these are three separate roles with three separate hiring bars. At a small company one person often does all three, which is why the interview should establish the split before it establishes depth. If your immediate need is nightly pipelines that do not break, a data engineer is frequently the better first hire, and interviewing for an architect will get you someone who writes excellent documents you cannot yet act on.
How do you interview a data architect if you are not technical?
Grade what you can judge without the vocabulary, and borrow help for the rest. Four signals are visible to any interviewer. First, did the candidate ask about your data volume, sources, budget, and consumers before proposing anything. Second, can they explain a design in plain language to someone who does not work in data. Third, can they name an architecture decision that turned out wrong and say what it cost. Fourth, have they seen the monthly bill for something they designed. Those four separate strong architects from fluent ones more reliably than a technical duel would. For modeling depth, bring one senior technical person from your network in for a single round and give them the same scorecard. Then run the live design exercise and score the questions the candidate asks you rather than the diagram they draw.
Should a data architect interview include a system design exercise?
Yes, and a live exercise is usually better than a take-home. Give every candidate the same real, anonymized problem from your business and 30 to 45 minutes to talk through it. Score the questions they ask before designing most heavily, then whether they right-sized the solution to your actual volume and budget, how they handled the messy inputs such as a hand-maintained spreadsheet, whether they mentioned cost and failure modes, and whether they could summarize the design in two minutes to a non-technical listener. A take-home hands the candidate a defined problem and strips out the scoping judgment you most need to observe, and senior candidates increasingly decline long unpaid assignments. If you do use one, cap it strictly, use the same prompt for everyone, and write the rubric before anyone sits it.
What are the red flags in a data architect interview?
Nine come up repeatedly. The candidate starts designing before asking about volume, budget, or who consumes the output. They have not touched SQL, code, or a console in years and do not want to. They cannot name an architecture decision that turned out wrong. They recommend an enterprise platform without a single qualifying question. They have never seen the monthly bill for anything they designed. They treat access control and data retention as somebody else’s job. They cannot explain a design in plain language. Every example they give depends on platform, security, or analytics teams that your company does not have. And they have no questions for you at the end. None of these is disqualifying alone, but two or three together usually mean the candidate is calibrated to a large organization rather than to your stage.
How much does a data architect cost to hire?
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), database architects had a national median annual wage of $139,500, about $67.07 an hour, with the 10th percentile at $86,240, the 25th at $109,370, the 75th at $169,290, and the 90th at $204,000. Database architects is the federal occupation that maps most closely to the title, though many people called data architects sit near it rather than in it. For comparison, database administrators reported a median of $104,620 in the same survey, which is a useful anchor if your role leans toward running databases rather than designing the data estate. Regional differences on this occupation are large, so benchmark to your metro and to the seniority you actually need. This is general information, not legal or financial advice.
Is a data architect exempt from overtime?
In most cases yes, but the classification depends on the actual duties and pay rather than the title. Under the Fair Labor Standards Act, exempt white-collar employees generally must be paid on a salary basis of at least $684 per week, which is $35,568 a year, and must meet a duties test. Data architects typically qualify under the computer employee exemption or the professional exemption, since the work involves systems analysis, design, and independent judgment, and the compensation for the role usually sits far above the salary threshold. Some states set a higher salary threshold or a stricter duties test than federal law, so confirm your state rules before classifying. Classification should be based on the duties the person actually performs, documented at hire. This is general information, not legal advice.
How long should a data architect hiring process be?
Four stages inside two to three weeks is a reasonable target for a small company. Start with a 30-minute screen that covers scope, the hands-on split, and the compensation range, so neither side wastes time. Follow with a core architecture and modeling round, then the live design exercise on a real problem from your business, then a final conversation with the people the hire will work beside plus reference checks. Score after each stage while the answers are fresh rather than at the end of the loop. Senior technical candidates drop out of slow processes, so compress the calendar rather than the content, and tell the candidate the full shape of the loop at the screen. Anything past five stages starts costing you finalists you would have wanted.
