Hiring a SQL developer is not the same as hiring a generic backend engineer who happens to write queries. The person who owns your data layer can quietly save you thousands in infrastructure and lost hours - or quietly cost you the same. This guide gives you a concrete way to evaluate skill, structure the interview, choose an engagement model, and spot the red flags before they reach production.
What this guide covers
- Why the right hire matters
- Core technical skills to look for
- Which skills matter most by role
- Soft skills and communication
- In-house vs freelance vs agency
- Interview questions that actually work
- A take-home test that tells you something
- Red flags to watch for
- What to expect on cost
- A candidate scorecard
Why the right hire matters
A SQL developer sits on the part of your stack that is hardest to walk back. Application code can be refactored on a Tuesday afternoon. A schema that was modelled badly two years ago, with millions of rows now depending on its quirks, is a migration project with real risk attached. The cost of a bad database hire is rarely a single dramatic failure - it is the slow accumulation of decisions that each looked fine in isolation.
Consider what a weak hire actually produces. Queries that work on a seed database of a few hundred rows but crawl once real traffic arrives. Indexes added reactively, one per slow page, until writes are choking under twenty redundant indexes nobody dares remove. Stored procedures with no error handling that silently swallow failed transactions. A permissions model where the application connects as a superuser because setting up least privilege was "too fiddly." None of these show up in a demo. All of them show up at 2am six months later.
The flip side is why this role is worth getting right. A strong SQL developer will often deliver a 10x or 100x speedup on a critical report simply by reading an execution plan and adding the correct composite index - work that no amount of extra hardware would have matched. They design schemas that absorb new requirements instead of fighting them. They write queries a teammate can read a year later. If you want to go deeper on the payoff side, our guide to performance tuning shows the kind of gains a competent person routinely finds.
Frame the role first: a reporting-heavy analytics role, an OLTP application role, and a data-platform role all say "SQL developer" but reward different strengths. Decide which one you are hiring for before you write the job post - it changes the whole scorecard.
Core technical skills to look for
Below is the skills matrix we use. The point of the middle column is to define "good" concretely, so you are not grading on vibes, and the right column gives you a fast way to probe each one in an interview or take-home.
| Skill | What good looks like | How to test it |
|---|---|---|
| Querying & joins | Reaches for the right join type instinctively, understands the difference between filtering in WHERE vs ON, avoids accidental fan-out that inflates aggregates. | Give a two-table question where a LEFT JOIN plus a WHERE on the right table secretly turns it into an inner join. See if they catch it. |
| Schema & data modeling | Normalises sensibly, knows when to denormalise on purpose, chooses correct types and constraints, uses foreign keys and NOT NULL to make bad states unrepresentable. | Ask them to model a small domain (orders, invoices) on a whiteboard and defend each key and constraint. |
| Indexing | Reads execution plans, understands composite index column order and selectivity, knows an index helps reads but taxes writes. | Show a slow query plus its plan and ask what index they would add and why. See our indexes guide for the reference answer. |
| Stored procedures & functions | Encapsulates logic cleanly, handles errors, keeps procedures testable, knows when logic belongs in the DB vs the app. | Ask for a procedure that must be idempotent and handle a duplicate-key case gracefully. |
| Transactions | Understands ACID in practice, isolation levels, deadlocks, and keeps transactions short to reduce lock contention. | Ask them to explain what happens under READ COMMITTED vs REPEATABLE READ for a given concurrent update. |
| Security | Uses parameterised queries by reflex, applies least privilege, thinks about data exposure and injection. | Ask how they would stop SQL injection and grant an app account only what it needs. See SQL security. |
| Performance tuning | Measures before changing, reasons from the plan, fixes the query or index before reaching for more hardware. | Ask for the last time they made something 10x faster and exactly what the bottleneck was. |
Notice that almost every "how to test" item asks the candidate to reason out loud rather than recite a definition. A person can memorise the ACID acronym; far fewer can walk you through a real deadlock and how they would break the cycle. The gap between those two is exactly what you are hiring for.
Which skills matter most by role
Not every skill deserves equal weight. Weighting depends entirely on the role you framed earlier. The chart below is our rough guidance for a typical application-backend SQL role - the kind that owns an operational database behind a web or mobile product. Treat the numbers as relative priorities, not precise scores.
Shift the weights for a different role. A reporting or analytics hire pushes advanced tuning and window functions to the top, while transaction handling drops. A data-platform or DBA-leaning role pushes security, backups, and replication up. The mistake to avoid is grading a candidate against the wrong profile - rejecting a superb analytics engineer because they were rusty on isolation levels they would never touch in your role.
Soft skills and communication
Database work is deceptively collaborative. The SQL developer is usually explaining a trade-off to someone who does not think in relational terms: a product manager who wants a report "just added," a frontend engineer who does not understand why one more join is expensive, a finance stakeholder who needs to trust a number. The best database people translate cleanly between those worlds.
- Explains trade-offs in plain language. "We can make this report instant, but every write gets a little slower - here is the deal we are choosing." That sentence is worth more than a dozen certifications.
- Writes queries other people can read. Consistent formatting, meaningful aliases, comments on the non-obvious. Code is read far more than it is written, and SQL is code.
- Pushes back constructively. When a requested query would scan a billion rows nightly, a strong hire proposes a better shape instead of silently building the slow thing.
- Documents decisions. A one-line note on why a denormalised column exists saves the next person a day of archaeology.
You can probe this directly. Ask the candidate to explain indexing to you as if you were a non-technical manager. Clarity under that constraint is a strong signal. If you want to see how deliberate skill-building looks in practice, our SQL mentorship approach is built around exactly this kind of explain-your-reasoning habit.
In-house vs freelance vs agency
Before you evaluate a single candidate, decide how you want to engage one. The three common models optimise for different things, and picking the wrong one wastes weeks.
| Model | Cost | Speed to start | Control | Best for |
|---|---|---|---|---|
| In-house employee | Highest total (salary, benefits, ramp) but lowest per-hour | Slow - weeks to hire, weeks to onboard | Full - your process, your standards | Long-lived product with an evolving schema and ongoing ownership needs |
| Freelancer | Moderate hourly, no overhead, pay only for work done | Fast - days to engage | Medium - depends on the individual and your spec | A defined project: a migration, a tuning sprint, a schema review |
| Agency / studio | Highest hourly, but includes review, backup, and process | Fast - a team is already assembled | Medium - you work through their process | When you need capacity plus a safety net and cannot risk a solo dependency |
A simple heuristic: if the work is ongoing ownership, hire in-house. If the work is a bounded outcome with a clear finish line, a freelancer is usually the best value. If you need the outcome plus guaranteed continuity and code review, an agency earns its premium. Many teams blend these - a freelancer or agency delivers the initial build and mentors the in-house hire who takes it over. If you would like a hand deciding, our SQL developer service can scope any of the three, and you can always talk to us first.
Interview questions that actually work
The questions below share one property: a strong answer reveals reasoning, not recall. Avoid trivia like "name the five aggregate functions." Ask questions where a weak candidate and a strong one give visibly different answers.
| Question | What a strong answer shows |
|---|---|
| "A query got slow last month. Walk me through how you would find out why." | They start with measurement and the execution plan, not guesses. Mentions looking at row estimates vs actuals. |
| "When would you deliberately break normalisation?" | Understands normalisation is the default and denormalisation is a considered trade-off for read performance, not laziness. |
"This LEFT JOIN is behaving like an inner join. Why?" | Spots that a WHERE filter on the right-hand table nullifies the outer join. A precise, common gotcha. |
| "How do you stop SQL injection?" | Says parameterised queries first and immediately, not string escaping or "validate input." A tell for security instinct. |
| "You have a composite index on (a, b). Does a query filtering only on b use it well?" | Explains leftmost-prefix behaviour - that the index is not efficient for a lone b filter. |
Pair the discussion with short reading-and-writing exercises. Show these snippets and ask the candidate to explain what each does, then to modify it. First, a join that should be routine:
-- customers and their order totals, including customers with zero orders
SELECT c.customer_id, c.name, COALESCE(SUM(o.amount), 0) AS total
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.customer_id
GROUP BY c.customer_id, c.name;A strong candidate immediately notes the COALESCE is what preserves the zero-order customers, and that moving a filter on orders into the WHERE clause would silently drop them. Next, a window function - a genuine dividing line between intermediate and advanced:
-- most recent order per customer, no self-join needed
SELECT * FROM (
SELECT o.*,
ROW_NUMBER() OVER (
PARTITION BY o.customer_id
ORDER BY o.created_at DESC
) AS rn
FROM orders o
) ranked
WHERE rn = 1;Ask them why the window function must be wrapped in a subquery before filtering on rn - a candidate who knows window functions cannot appear in the same WHERE that references them is showing real depth. Finally, an indexing decision expressed as intent:
-- query filters by status then sorts by date -- index to match
CREATE INDEX idx_orders_status_created
ON orders (status, created_at DESC);The reasoning you want to hear: put the equality-filtered column (status) first so the index narrows quickly, then created_at so the sort comes for free. If they can articulate that column order, they understand composite indexes for real.
A take-home test that tells you something
A good take-home is small, realistic, and reveals judgement rather than endurance. Do not ask for a weekend of unpaid work - that filters for availability, not skill. Cap it at ninety minutes and give a schema plus a seed dataset.
Give a small imperfect schema
Three or four tables with a deliberate flaw - a missing foreign key, a column that should be NOT NULL, an obvious missing index. Include seed data with enough rows to matter.
Ask for three queries
One straightforward aggregate, one that needs a correct join and a group, and one that rewards a window function or CTE. Judge correctness and readability equally.
Ask them to critique the schema
A short written note on what they would change and why. This is the most revealing part - it surfaces modelling instinct and communication in one shot.
Ask for one performance improvement
Point at the slowest query and ask for a fix plus a one-line explanation. You are looking for an index or a rewrite, backed by reasoning, not a shrug.
Grade the write-up as heavily as the SQL. Two candidates can both return working queries; the one who explained a trade-off clearly and flagged the missing constraint is the one who will save you from the 2am incident. Someone who has done structured practice - for instance our SQL beginner course and beyond - tends to show this reflex naturally.
Red flags to watch for
Watch out: any single one of these is a conversation, not an automatic no. But two or more together should make you cautious.
- "Just throw more hardware at it." Reaching for RAM or a bigger instance before reading the query plan signals someone who has never actually diagnosed a slow query.
- Building queries by string concatenation. If they hand-glue user input into SQL and do not mention parameters, you have a security incident waiting.
- Cannot read an execution plan. Tuning without the plan is guessing. This is a hard requirement for any performance-sensitive role.
- Fear of
NULL. Confusion around three-valued logic (= NULLvsIS NULL) points to shaky fundamentals. - "I always
SELECT *." Fine in a quick console; a habit in application code that hurts performance and breaks silently when schemas change. - No opinion on when logic belongs in the app vs the database. A developer with real experience has scars and preferences here.
- Dismisses backups and migrations as "ops, not my job." The person owning your schema must respect how it changes safely.
What to expect on cost
Rates vary enormously by region, seniority, and engagement model, so treat the chart below as indicative ranges only - a sanity check, not a quote. These reflect typical freelance and contract hourly rates in USD-denominated markets as of writing; in-house salaries convert to a lower effective hourly but add benefits and overhead.
The counter-intuitive truth about cost: the senior rate is usually the better deal for hard problems. A specialist who diagnoses a query in an hour that a junior would circle for two days is cheaper per outcome, even at three times the hourly. Reserve juniors for well-scoped, supervised work where learning time is acceptable, and pay up for the person who reads the execution plan and knows immediately what is wrong.
A candidate scorecard
Bring structure to the final decision. Score each dimension 1 to 5 across your interviewers, weight by the role profile, and compare candidates on the totals rather than on whoever left the strongest last impression. Below is a starting template - adjust the weights to match the role you framed at the top.
| Dimension | Weight | 1-2 (weak) | 4-5 (strong) |
|---|---|---|---|
| Querying & joins | High | Struggles with multi-table logic; misses join gotchas | Fluent; catches fan-out and outer-join traps unprompted |
| Schema modeling | High | Under-constrains; no view on normalisation | Constraints by default; denormalises with clear reasons |
| Indexing & tuning | High | Guesses; wants more hardware | Reads plans; reasons about column order and selectivity |
| Security | Medium | Vague on injection and privileges | Parameterises reflexively; applies least privilege |
| Transactions | Medium | Cannot explain isolation trade-offs | Handles concurrency and keeps transactions short |
| Communication | High | Explanations stay jargon-locked | Translates trade-offs for any audience |
| Judgement | High | Builds what is asked, even when it is wrong | Proposes the better shape and flags risks early |
The single best predictor: a candidate who reasons out loud, measures before changing, and explains trade-offs clearly will outperform a flashier one who cannot. Weight judgement and communication as heavily as raw SQL - the fundamentals can be sharpened, but the instinct to think before acting is what keeps your data layer healthy.
Put it together: frame the role, weight the scorecard to match, run reasoning-first questions plus a short take-home, watch for the red flags, and choose the engagement model that fits the work. Do that and you replace a stressful gamble with a repeatable, defensible hire.