SQLSimplified Review: Free SQL Practice, Worked Solutions, and Query-Check Boundaries

SQLSimplified offers free browser SQL practice with worked explanations and an editable query workspace. Its execution boundary needs care: on the hard task we inspected, an intentionally wrong query returned a table without a visible answer-rejection verdict. The worked solution returned the expected-looking category winners, and invalid syntax produced a database error. Separate those execution results from an answer-correctness verdict.

Start with PracHub’s top-spend ranking question and calculate a tiny answer by hand before running SQL. The site can help you explore joins, CTEs and window functions, but a displayed result is most useful when you have an independent reason to believe it answers the task.

Checked November 3, 2026: official descriptions, our anonymous public browser runs and an original local SQLite counterexample are separated below. We did not verify every task’s checker, account synchronization or hiring outcomes. No independent candidate reports establish effectiveness. PracHub publishes this review and provides the linked preparation questions.

The free task we opened

The SQLSimplified practice library offered difficulty categories and a public task called Best Customer Per Category. We opened its editor, hint and worked solution without creating an account.

The question asked for one top-spending customer in each product category, returning the category, customer name and total spend. The visible schema context was a store with Customers, Orders and Products. A hint pointed toward ranking within each category, and the worked solution used a CTE with ROW_NUMBER.

The site described a database running in the browser and advertised expected-output comparison elsewhere in its public material. Those are provider descriptions. Our review evaluates what the inspected task actually displayed rather than assuming every advertised mechanism appeared in this view.

The broader navigation included lessons, functions, examples, interview material, a cheatsheet and a playground. That breadth can make it convenient to look up syntax while practicing. We did not audit every lesson or establish that all difficulty labels represent comparable assessment difficulty across other products.

The meaningful free-access observation is narrower: we could run queries and reveal help in this task anonymously. We did not need to purchase anything to perform the controls below.

Three runs that separate execution from judgment

First, we entered a deliberately irrelevant result with the requested-looking column names:

SELECT 'zzz' AS category,
       'Nobody' AS customer,
       0 AS total_spend;

The Run action produced the one-row table and a row-count/execution-time display. We did not observe an incorrect-answer verdict or comparison with expected category winners in that task view. A Mark as complete control remained separate from the query output; we did not use it to claim success.

Next, we ran the displayed worked CTE. It returned three rows: Electronics with Ava Coleman at 289.98, Furniture with Ben Foster at 349, and Stationery with Kayla Perry at 63.96. These are observed exercise outputs, not business results from a real store.

Finally, we intentionally misspelled SELECT. The workspace displayed a parser error. That confirms error feedback for invalid SQL in this run, but it does not establish that a valid query returning the wrong business answer is rejected.

We are not claiming that the whole product lacks a checker. Another task or interface may behave differently. The evidence boundary is that this inspected hard-task Run flow did not give us a visible verdict distinguishing the arbitrary result from a correct answer.

That distinction should shape your preparation. Use the workspace as a runnable database and worked-example resource, and establish correctness through expected results or additional checks unless a task clearly demonstrates its own result comparison.

What the worked query teaches

The displayed approach first aggregates spend by category and customer name. It then assigns row numbers within a category in descending spend order, keeps row number one and orders the final categories. This is a useful structure for separating group-level totals from within-group selection.

A CTE gives a name to the intermediate result; it does not automatically make the logic correct. Define what one intermediate row represents before ranking it. In a top-customer task, that should be one customer’s spend in one category under the declared inclusion and price rules.

ROW_NUMBER selects one row even when spend ties. If the business wants all tied winners, a different ranking contract is needed. If it wants exactly one, ask how ties are resolved. A secondary stable key can make the choice deterministic, but it should be chosen deliberately rather than added after an unexplained mismatch.

Also inspect the amount source. The displayed store example multiplied quantity by product price. That can be appropriate for its supplied teaching schema. A historical-sales schema with recorded transaction prices may require a different field. Do not carry a query into a different dataset without checking what the values mean.

Our purpose here is to evaluate how to learn from a reference, not to accuse the platform of a production defect. The strongest next step is an original dataset that changes one assumption and makes the hidden choice visible.

An original same-name customer counterexample

We built a separate local SQLite fixture with three customers. ID 11 is named Sam and spends 20. ID 12 is also named Sam and spends 30. ID 13 is named Ari and spends 40. Assume they all belong to one category and the task asks for the highest-spending individual customer.

Grouping only by name merges the two Sams into a total of 50 and incorrectly makes Sam the winner. Grouping by stable customer identity keeps the two people separate and correctly makes Ari, at 40, the top individual.

We executed both grouping versions locally and checked that their leading results differed. This is our adversarial fixture, not a claim that SQLSimplified’s current sample data contains duplicate names or that its native output was wrong for the provided rows.

The repair is to retain customer ID while grouping, alongside the name needed for display. A name is an attribute that can be shared or changed; it is not automatically the entity key. The same issue appears with product names, cities, employees and accounts.

If the prompt intentionally asks for totals by display name, grouping by name may be correct. The point is to establish the entity and grain before choosing columns. A technically valid query can faithfully answer a different question from the one the stakeholder intended.

Build a small correctness check beside the playground

Before entering a long query, write the expected output for a dataset containing one ordinary case and one counterexample. For top spenders, duplicate names and tied totals are more informative than ten rows with unique names and strictly increasing amounts.

Then inspect the intermediate aggregation separately. If two people have already merged in the CTE, changing the window function will not repair their identities. This is why debugging from the final row alone can waste time: the mistake may occur before ranking begins.

Check cardinality after joins as well. An order joined to multiple events can appear repeatedly, inflating spend. Keep the order or line identifier visible while examining the joined rows. Adding DISTINCT at the end can hide duplicated projections without restoring the intended monetary total.

Separate parser errors, execution errors and incorrect answers in your notes. A parser error means the engine could not interpret the statement. A returned table means it executed. Correctness requires comparing that table with the contract, including rows, values, ties and ordering where relevant.

This discipline is especially useful when a practice interface offers a manual completion control. You can mark an exercise complete under your own standard, but write down what that standard was. “Ran the reference” and “independently derived and tested the result” should not become indistinguishable accomplishments.

Decide what absence means before adding a join

An original follow-up is a customer with no orders in a category. Should the result include that customer with zero spend, omit the customer, or return an empty category? The answer changes the population before ranking. A left join can retain missing matches, but a later filter on an order column can remove them again.

Write the intended output for that empty case before editing the query. This is a specification exercise, not an observed failure in SQLSimplified’s dataset. It prevents a query from quietly choosing the reporting population on the stakeholder’s behalf.

Use the explanation without turning practice into copying

Try to formulate the intermediate table before revealing the solution. You might write: one row per category and customer ID, carrying total spend. Once that table is clear, choosing a ranking method becomes a smaller step.

If you need the hint, use it to identify the missing operation, then close it and write the query yourself. After reading the complete solution, change the requirement: return all tied winners, exclude cancelled orders or keep categories with no spend. Predict which parts of the original query must change.

A useful explanation includes why the wrong answer looked plausible. Grouping by name is compact and works on many small datasets. Returning a constant row has the right column shape. Both can execute while failing the business requirement. Being able to explain that gap is valuable interview preparation.

Do not treat displayed execution timing as a portable benchmark. Browser startup, local execution and dataset size affect it, and our runs were not designed as performance measurements. Optimize only after the correctness contract is clear and the relevant scale is specified.

The learning area and playground can support syntax exploration. For graded-assessment rehearsal, independently confirm the exact task’s feedback behavior rather than assuming an execution surface and an answer judge are the same feature.

Five questions for SQL transfer

These independent PracHub records extend customer spend, ranking and reporting. They are not SQLSimplified integrations, official partner exercises or predictions about a company’s assessment.

Use the top-category question to change the ranking direction from customers within categories to categories within customers. The recent-spend query adds a time boundary. Monthly counts change the aggregation grain. Explain the changed requirement before reusing the CTE pattern.

SQLSimplified is a sensible free resource when you want runnable examples and nearby explanations. Our inspected task supports that use. A verified incorrect-answer verdict remained outside the observed boundary, so pair the workspace with hand-calculated expectations and small counterexamples. Choose a follow-up from PracHub’s SQL interview questions and make the next result something you can defend beyond “the query ran.”

Sources and further reading

• SQLSimplified practice library
• Best Customer Per Category: inspected query workspace and solution
• SQLSimplified learning area
• SQLSimplified browser playground