SQL Developer interview questions and practice.
Writes and tunes SQL queries, stored procedures and database objects that power applications, reports and integrations.
No card for the taster. Full interviews are paid one at a time. Nothing renews.
Last reviewed
This page is still being written: no authored question bank for this competency family. The role is fully supported in the interview itself; only the published question bank is outstanding.
What interviewers for SQL Developer actually ask
The question bank for this role is still being written. These are the first three competencies in the model the interview is scored against.
Builds batch and streaming pipelines that are idempotent, restartable and observable, and designs for late data, backfills and failure from the start.
Designs schemas and layered models (raw, cleaned, business) that serve analytics efficiently, evolve safely and have clear ownership and definitions.
Makes data trustworthy with automated tests, freshness and volume checks, lineage and clear SLAs, and catches problems before consumers do.
What they are really assessing
Interviewers rarely score whether you seemed nice. They score against a model like this one, usually without telling you it exists. Each competency has a weak, adequate and strong shape, and the difference is almost always the level of specific detail you volunteer without being asked.
Pipeline design & reliability
Builds batch and streaming pipelines that are idempotent, restartable and observable, and designs for late data, backfills and failure from the start.
- Weak
- Pipelines are scripts on a schedule; reruns duplicate data; cannot describe handling late-arriving data, a backfill, or how failures are detected.
- Adequate
- Builds idempotent, orchestrated pipelines with retries and alerting, and has done backfills, but late data and partial failure are handled case by case.
- Strong
- Gives a real pipeline with its idempotency and partitioning strategy, how late data and backfills are handled, a failure that was caught by monitoring, and the measured improvement in freshness or failure rate.
Data modelling & warehousing
Designs schemas and layered models (raw, cleaned, business) that serve analytics efficiently, evolve safely and have clear ownership and definitions.
- Weak
- Loads source tables as-is; cannot explain dimensional modelling, slowly changing dimensions, or why a schema change broke downstream reports.
- Adequate
- Designs star schemas or layered models with documented definitions and handles schema evolution, but performance and cost of the model were not measured.
- Strong
- Describes a modelling decision (grain, SCD type, partitioning, denormalisation) with the query patterns and cost numbers that drove it, and a schema migration done without breaking consumers.
Data quality & observability
Makes data trustworthy with automated tests, freshness and volume checks, lineage and clear SLAs, and catches problems before consumers do.
- Weak
- Data quality problems are found by analysts; no automated tests; cannot describe an SLA for a dataset or how lineage is tracked.
- Adequate
- Has tests for schema, nulls and freshness and alerts on failures, but coverage is uneven and incidents are not tracked or learned from.
- Strong
- Gives a data incident (silent upstream change, duplicate load, definition drift) caught by their checks or missed and then covered, with the SLA, lineage and incident process they put in place and its measured effect.
Performance & cost efficiency
Optimises storage, compute and query performance with measurement, and keeps cloud data platform costs proportionate to value.
- Weak
- Cannot say what a pipeline or warehouse costs or why a job was slow; optimisation is 'add more workers'.
- Adequate
- Has tuned partitioning, file formats or clustering and reduced a job's runtime, but cost tracking is coarse and savings are not quantified.
- Strong
- Gives measured before/after runtime and cost for an optimisation, the diagnosis (skew, shuffle, small files, scan volume), and the guardrails (budgets, query governance) that keep costs in check.
Platform, orchestration & software engineering practice
Applies software engineering discipline to data: version control, testing, CI/CD, infrastructure as code and orchestration that other engineers can maintain.
- Weak
- Code lives in notebooks or the orchestrator UI; no tests or code review; deployments are manual.
- Adequate
- Uses version control, code review, CI and an orchestrator with environments, but tests are thin and infrastructure is partly manual.
- Strong
- Describes a data platform with tested transformations, CI/CD for pipelines, infrastructure as code, and a change they made safer through this (e.g. catching a broken model in CI).
Security, privacy & data governance
Handles personal and sensitive data lawfully and safely: access control, encryption, masking, retention and lineage that satisfy POPIA/GDPR and internal governance.
- Weak
- Everyone has access to everything; personal data is copied freely into dev environments; cannot explain what POPIA requires of a pipeline.
- Adequate
- Implements role-based access, masking of PII and retention policies, but governance is reactive and lineage of sensitive fields is incomplete.
- Strong
- Describes classifying and protecting sensitive data end to end (masking, column-level access, retention, audit), a governance request they handled (deletion, access review), and how they made compliance automatic rather than manual.
Working with data consumers & producers
Partners with analysts, scientists and source-system teams: negotiates contracts, communicates changes and outages clearly, and prioritises by consumer value.
- Weak
- Builds what is asked without understanding use; cannot describe negotiating a data contract with a source team or communicating a breaking change.
- Adequate
- Consults consumers on requirements and announces changes, but upstream changes still break pipelines and prioritisation is first-come-first-served.
- Strong
- Gives a case of establishing a data contract or change process with a source team that reduced breakages, and one of reprioritising work with consumers based on decision value, with the outcome.
Incident ownership & follow-through
Takes responsibility when data is wrong or late, communicates impact honestly, and fixes root causes rather than patching symptoms.
- Weak
- Attributes data problems to sources or analysts; cannot describe an incident they owned end to end or told consumers about proactively.
- Adequate
- Owns incidents and communicates them, but root-cause fixes are sometimes deferred and recurrence is not tracked.
- Strong
- Describes an incident where they told consumers early with impact and ETA, found the root cause, fixed it structurally, and can show recurrence dropped.
Reading the questions is the easy half. Try answering three of them out loud, to someone who follows up.
Try 5 minutes freeWhat your 30 minutes covers
The same shape as a real first-round interview, pitched at mid-level SQL Developer and scored throughout.
Warm-up, then Motivation & fit
Build rapport, settle nerves, and get a short walk-through of your background. Why this role, why this employer, and what you are actually looking for.
Your experience
Two or three real situations from your CV in depth: context, what you did, what happened, what you would change.
Pitched at mid-level scope: owns a data domain's pipelines, models and quality; accountable for freshness, correctness and cost in that area.
Role-specific questions
The core competencies and domain knowledge for the role, with follow-ups on anything vague.
Drawn from this role's domain: designing an idempotent, restartable batch pipeline with backfill support, handling late-arriving and out-of-order data in streaming and dimensional modelling: grain, slowly changing dimensions and conformed dimensions, and the rest of the competency model.
Your questions, then Wrap-up
Your questions for the interviewer, and yes, they are assessed. Next steps and a clean finish.
What changes with seniority
The questions barely change between levels. What changes is the answer they will accept.
| Junior | Mid | Senior | |
|---|---|---|---|
| Scope of ownership | Owns pipelines and models within an existing platform with review; expected to write tests and handle reruns safely. | Owns a data domain's pipelines, models and quality; accountable for freshness, correctness and cost in that area. | Owns data platform architecture and standards across teams; accountable for reliability, cost and governance of the platform. |
| Tolerance for ambiguity | Handles tickets with some gaps by asking targeted questions of consumers and source owners. | Turns consumer needs into a data model and pipeline design; identifies upstream risks and negotiates contracts. | Defines platform direction from business needs; makes build-vs-buy and architecture decisions with incomplete information. |
| People leadership | No formal leadership. | Mentors juniors, reviews code, may lead a small project. | Technical lead for data engineers, drives design reviews, mentors across teams. |
| Who they deal with | Own team, analysts, source-system developers. | Analysts and scientists, source-system teams, platform engineers, business owners of data. | Data and engineering leadership, security and privacy, finance for platform spend, vendors. |
What your report would say
Every competency above scored from your own answers, the sentence that cost you quoted back, and your weakest answers rewritten the way a strong SQL Developer would have said them.
- Gives a data incident (silent upstream change, duplicate load, definition drift) caught by their checks or missed and then covered, with the SLA, lineage and incident process they put in place and its measured effect.
The format, not a result. Scores on your report come from what you actually said.
Is the AI interviewer realistic? See a full sample report