SQL Query Writing Assessment with Executed QueriesYour query runs. Then it runs again, on the rows you have not seen.
Six SQL statements executed against a real database, twice each, plus thirty-four keyed exercises on the judgement that decides whether a correct query answers the right question.
Almost every SQL test in this market is multiple choice about SQL
There is a reason for that and it is not a good one: running code is more work to build than asking about it. So the standard product asks which of four statements is correct, and a candidate who can read SQL fluently and write it badly passes. This one gives you a schema, a worked example with its expected output, and a blank box, and then it runs what you write.
It runs it twice. The first run is on the rows printed in the exercise. The second is on a set you have not seen, and that set is the whole design. It carries the order placed in the previous year that a missing filter would count, the order with no lines that an inner join would silently drop, the rating somebody left blank that an average must skip, the invoice a feed loaded twice, the order timestamped four minutes before midnight on the last day of the month. None of it is exotic. All of it is what separates a statement that works from a statement that happened to work on the example.
Around the six statements sit thirty-four exercises on the part that decides whether a correct query is a useful one. What one row of your result is supposed to mean. Why a total went up when you added a table, and why the direction of that error tells you which fault it is. What an average does with a blank, and why an empty result is a different finding from a zero. What you check before a number reaches somebody who is going to act on it, and what you write beside it so a challenge is a short conversation rather than an argument. Twelve are single-choice, eight ask which of several things you would actually do, eight are plain claims to accept or reject, and six ask you to put a sequence in order.
The report places you on a five-rung ladder where every rung carries a description of what somebody at that rung does, so the rung above yours is the development goal written out rather than a label to aspire to. The cut for unsupervised work is drawn on the ladder as a dashed line with its own standard error printed beside it, because a cut is a judgement somebody made and burying it is how a band turns into a verdict. Your two spans are drawn across the rungs, which is the fastest way to see that a forty-exercise sitting cannot separate the top of one rung from the bottom of the next.
And if the execution service cannot run your statements, those six exercises leave the denominator rather than scoring zero, and the report says so in plain words. A platform that cannot run your code has not discovered anything about you.
What you walk away with
Not a percentage. What somebody at your rung does, and what the next one up does, which is the development goal stated as behaviour rather than as an adjective.
The sixty-eight and ninety-five per cent spans across the rungs, so the width of the uncertainty is visible against the thing it is uncertain about.
Drawn on the ladder as a line, with the standard error of judgment behind it printed. You are entitled to disagree with where it sits and to see your score against it.
Passed on the worked example and held on the hidden rows, reported separately for every task. The gap between those two columns is the reading worth having.
Grain, joins, absences and checking — what getting each right gets you, and where each one goes wrong when it is overdone.
Items, omega, and what that permits, part by part, with the parts that cannot carry a number saying so rather than printing one.
Inside your report
Illustrative sample — your report is generated from your own responses.
The rung comes from the point estimate and the boundary warning from the narrow span, so a placement is never firmer than the sitting can support.
The hidden set is never exotic: a repeated row, a blank value, a timestamp four minutes before midnight on the last day of a month.
A cut is a judgement somebody made rather than a measurement of anything, so it is printed where it can be argued with.
Built for
- Analysts and engineers who write SQL and want a work sample rather than a quiz
- Hiring teams who need to know whether a candidate's query survives real data
- Data teams setting a defensible bar for unsupervised query work
- Anybody who has sent a number that turned out to be double what it should have been
Write the statement. Watch it run twice.
6 executed SQL tasks and 34 keyed exercises · about 55 minutes · a five-rung ladder with a published cut, both spans, and every task reported separately.
₹999 (incl. GST) · assessment and full report, nothing further to pay
Frequently asked questions
You write it. Six exercises give you a schema, a worked example with its expected output, and a blank box, and your statement is executed against a real database. The other thirty-four are keyed exercises about judgement rather than syntax, in four different formats, because a form of one type repeated forty times measures the format alongside the skill.
The same statement is run against a second dataset you have not seen. It carries the ordinary complications that separate a query that works from one that happened to work: a duplicate row from a feed that ran twice, an order with no lines, a rating left blank, an order timestamped late on the last day of a month. Nothing about it is a trick, and it is where most statements that pass the example stop passing.
Standard SQL executed on SQLite. Every exercise is written so that nothing dialect-specific decides the answer, and the schema and the expected output are printed in the exercise. If your statement runs anywhere it will run here.
Those exercises are reported as not run, they leave the denominator rather than scoring zero, and the report says so on the page. Your score comes from the thirty-four keyed exercises and is unaffected. A platform that could not run your code has not discovered anything about you, and reporting it as though it had would be the platform's failure written up as yours.
About fifty-five minutes for forty exercises. ₹999 in India, inclusive of GST, or US$9.99 elsewhere, one-time, for the sitting and the full report. Nothing is timed exercise by exercise and no part of the score uses how fast you answered.
Each one takes a single capability, puts you inside the situations where it is actually tested, and scores your choices against published evidence — with a report designed for that capability alone, not a template. They span hiring, compliance, education, operations and personal skill.
Browse the catalogue →Methodology: Forty original exercises across five formats: six executed SQL work samples run against a real database, twelve keyed single-choice items, eight select-every-that-applies items, eight true or false claims and six ordering exercises. Construct statement: it measures whether somebody can turn a business question into a correct query at the right grain, join without multiplying or losing rows, handle absent values and empty groups honestly, and check a figure before it leaves their hands. It does not measure database administration, query tuning, schema design, warehouse architecture, statistics, or how quickly somebody types. Declared response instruction: knowledge and demonstrated skill throughout. Every exercise has a defensible answer that does not depend on what the respondent would prefer to do. Execution: the six work samples are run against a database, twice each - once on the rows shown in the exercise and once on a second set the respondent has not seen, which carries the duplicate row, the absent value or the boundary timestamp that separates a query that works from a query that happened to work. Where the execution service cannot be reached, those six exercises are reported as not run and are removed from the denominator rather than scored zero; the report says so in plain words on the page. Construct grounding, drawn across sources rather than from one framework: the three-valued logic of the SQL standard and the semantics of the NULL marker (ISO/IEC 9075; Codd, 1979); the documented behaviour of aggregate functions over absent values and of outer joins (Date, An Introduction to Database Systems; the SQLite datatype and expression documentation); grain declaration as the first step of any measurement, and the failure modes of a fact table joined to a many-side table (Kimball and Ross, The Data Warehouse Toolkit); one row per observation and one column per variable as the definition of a tidy result (Wickham, 2014); the taxonomy of data-entry and structural faults that survive validation (Broman and Woo, 2018); measured human error rates in spreadsheet and query work, and why self-review detects so little of it (Panko, 1998; 2008); the slip-versus-mistake distinction that separates a typing fault from a wrong model of the data (Reason, Human Error, 1990); the criterion validity of work-sample tests against job performance (Roth, Bobko and McFarland, 2005; Schmidt and Hunter, 1998); the modified Angoff procedure for setting a defensible cut score and reporting the standard error of judgment (Angoff, 1971; Cizek and Bunch, 2007); the standard error of measurement and the rule that a band, not a point, is what may be reported (AERA, APA and NCME Standards for Educational and Psychological Testing, 2014); and McDonald's omega as the reliability estimate to report in place of coefficient alpha (McDonald, 1999). All items are original works. No item, dataset, scale name or report section is taken from any commercial instrument, and no affiliation with or endorsement by any vendor or certification body is claimed or implied.