Almost anyone who writes software can write a query. What distinguishes a database developer is modelling: designing a schema that stays correct and fast as the data grows and the requirements change, and knowing which of those two goals you are trading away when you make a choice. That skill is much rarer than query fluency and it is what you are paying for.
Test modelling, not syntax
Give a candidate a small real domain and ask them to model it, then change a requirement and watch how the model absorbs it. Ask when they would denormalise and what they would give up. Ask how they would handle a column that needs to become a one to many relationship in a table with a very large number of rows and no maintenance window. These reveal whether someone reasons about data over time or simply satisfies today's query.
Performance questions that separate real experience
Ask how they diagnose a query that became slow without the query changing, and listen for statistics, plan changes and data distribution rather than adding an index reflexively. Ask what they check before adding an index and what an index costs on write. Ask how they would safely change a schema on a busy production system. People who have operated databases under load answer these with caution and specifics; people who have not answer with confidence.
Data protection is part of the role now
Whoever designs your schema decides where sensitive data lives and how it is separated, so security belongs in the interview. The elements at 16 CFR 314.4 are a fair reference even outside financial services: access controls limited to authorised users by job need, encryption of customer information in transit and at rest, logging of authorised activity and secure disposal. Ask how they would design for those rather than whether they have heard of them.
Reporting is a different hire, and often the one actually needed
A great deal of work described as database development is really analytics and reporting: building models and dashboards over data that already exists. That is a different skill set, closer to the business than to the engine, and hiring a backend database engineer for it produces a frustrated expensive person building charts. Be honest about which problem you have, because the reporting specialist is usually cheaper and better at the reporting problem.
Questions people ask about hire database developer
How do we test a database developer properly?
Give them a small real domain to model, then change a requirement and watch how the model absorbs it. Ask about diagnosing a query that slowed without changing, and about altering a schema on a busy system with no maintenance window.
Should we hire a database developer or hire Power BI developers for reporting?
If the work is dashboards and models over data that already exists, hire the reporting specialist. Backend database engineers are a different and usually more expensive hire, and they tend to be unhappy and slower doing reporting work.
Should security be part of a database hire's assessment?
Yes, because the schema decides where sensitive data lives. The elements at 16 CFR 314.4 make a good reference: access limited by job need, encryption in transit and at rest, activity logging and secure disposal.