SQLPrep Review: Browser SQL Checks, Business Datasets, and Pro Waitlist Limits

SQLPrep lets you practice translating a business metric into SQL, then compare the returned values and row order. On its free category-revenue task, we verified that the checker rejected a changed revenue total and reversed ordering. It also accepted a renamed output alias in that same task. These controls show which parts of this task’s output were checked.

Begin with PracHub’s sales-and-customer SQL question and identify the grain, status filter and price source before writing a join. SQLPrep’s public exercise is useful precisely because a runnable aggregation can still represent the wrong business metric.

Checked November 3, 2026: official feature descriptions, our anonymous browser experiments, and an original local SQLite dataset are separate evidence classes. We did not buy access, join the Pro waitlist, or test a private company track. No independent candidate-outcome evidence supports hiring-effectiveness claims. PracHub publishes this review and provides the linked preparation questions.

The business contract in the public exercise

The SQLPrep homepage offered an editable Revenue by Product Category task. Its full problem page was linked from the same interface. We used the public homepage workspace without signing in.

The task required revenue for completed orders only, calculated from order-line quantity multiplied by the line’s unit price, grouped by product category, rounded to two decimal places and sorted highest first. The required output was described as category and revenue.

That specification contains several independent choices. The product catalog supplies the category, but its current price is not automatically the price charged on an old order. Order status decides which lines belong in the total. Grouping determines what one output row means. Sorting affects whether the first result really is the highest-revenue category.

Our correct query followed those choices explicitly:

SELECT p.category,
       ROUND(SUM(oi.quantity * oi.unit_price), 2) AS revenue
FROM order_items oi
JOIN orders o ON o.order_id = oi.order_id
JOIN products p ON p.product_id = oi.product_id
WHERE o.status = 'completed'
GROUP BY p.category
ORDER BY revenue DESC;

The browser returned five category rows and reported that values and row order matched. Electronics was first at 8,311.74, followed by Home at 6,169.04, Apparel at 4,783.72, Beauty at 2,841.75 and Books at 1,620.15. These are the exercise outputs we observed, not business results from a real retailer.

The useful lesson is the dependency chain from a sentence to a query. If the intended metric changes to net revenue after refunds, this query is no longer sufficient merely because it passed the original exercise. A correct result belongs to its stated contract and dataset.

What our checker controls established

We changed one property at a time after obtaining the correct result. Adding one to each aggregate preserved the row count but produced a value mismatch on the revenue column. Reversing the ordering also failed, with a mismatch at the first category. These are meaningful behavioral controls because both queries still execute.

We then changed the alias from revenue to total and changed the ORDER BY reference accordingly. The checker still accepted the result. The table displayed the new header. Therefore, this public task did not reject that alias change in our test, despite describing a particular output name.

A historical solved badge remained visible after later failing attempts. We used the latest run’s feedback rather than the persistent badge to classify each control. That is a useful habit in any workspace that separately stores completion history and shows current execution results.

These findings do not reveal the checker’s internal implementation. We did not test duplicate handling, numeric tolerance, every possible column permutation or all other tasks. The appropriate claim is that this sample reacted to the specific mutations above, not that SQLPrep universally enforces or ignores every schema detail.

An original dataset that exposes the wrong price source

To test the reasoning independently, we built a small local SQLite example. It has Tools with a current catalog price of 30 and Books with a current catalog price of 50. One completed order contains two Tools units charged at 12 each and one Books unit charged at 40. A cancelled order contains eight Tools units charged at 10.

Using completed order lines produces Tools revenue of 24 and Books revenue of 40. Substituting current catalog prices produces Tools at 60 and Books at 50, reversing the leading category. Omitting the status filter produces Tools at 104 and Books at 40.

We executed those three calculations locally. This fixture is our teaching example, not SQLPrep’s source data or hidden test suite. It demonstrates why two plausible joins and a syntactically valid SUM can produce different business conclusions.

A strong interview answer names the authoritative field before calculating. “Revenue uses the unit price recorded on each completed order line” is more useful than “join the three tables and sum sales.” The first statement can be challenged against the business requirement; the second leaves the main definition implicit.

The same discipline applies to discounts, tax, shipping and refunds. Do not silently decide whether they belong in revenue. Ask which amount the stakeholder wants, where that amount is recorded and whether later adjustments should be recognized in the original month or the adjustment month.

Test the grain before trusting the total

The public query joins order lines to one order and one product. An interview can add a table that has multiple rows per order, such as status history or shipment events. Joining it directly can duplicate line amounts even when each join condition is individually reasonable.

Before adding that table, state the required grain: one contribution per included order line. Check whether the new relationship preserves that grain. If an order has three shipment events, multiplying its line rows by those events does not create three times the revenue.

A useful original follow-up is to add two status-history rows to the completed order in our tiny dataset. Predict the incorrect duplicated total before writing a repair. Then decide whether you need the latest status, existence of an event, or an aggregated attribute. Each requirement suggests a different query shape.

Do not use DISTINCT as an unexplained antidote. Two legitimate order lines can have equal amounts, so deduplicating projected values may erase real sales. Preserve identifiers long enough to explain which rows are duplicated and why. Correct aggregation depends on row meaning rather than cosmetic output uniqueness.

This extension was not a native SQLPrep checker test. It is an editorial way to deepen the business dataset practice. The site’s matching result is a starting observation; your own counterexample determines whether the reasoning transfers to a changed schema.

Free practice and the Pro waitlist

The official homepage described business datasets covering ecommerce, rideshare, SaaS events and advertising. It displayed 70 problems with 12 free. Those are changing catalog descriptions, not an audit of every problem or evidence that all domains have equal depth.

The Pro page was explicitly marked coming soon. It promoted planned Python and pandas work, timed mocks and company-style tracks through a waitlist. We did not submit contact details or verify a paid checkout. A planned feature is not an available entitlement.

For someone deciding where to practice tonight, the public category-revenue task is the clearest verified entry point. If your requirement is a particular cohort, funnel or attribution exercise, open that exact problem and confirm its access state first. A business dataset label alone does not establish that a specific interview skill is covered.

The same distinction applies to a company-style track. That phrase can mean an original exercise inspired by a domain, not a sourced employer question or an accurate current assessment format. Nothing in our public test establishes a relationship between SQLPrep’s checker and an employer’s scoring system.

Our editorial recommendation is to evaluate the free task on the quality of the contract and feedback you can use. Treat the Pro plan as something to revisit after it launches and its actual access, exercises and limits can be observed.

A practice session that produces reusable evidence

Start by writing the metric in plain language. Name the source rows, exclusions, grouping key, amount field, rounding rule and output order. Then write one deliberately incorrect query that violates just one choice. A changed-value control is especially useful because it distinguishes query execution from result checking.

After the correct run, preserve the query and one failing variant. If the output is wrong, locate the earliest point where rows stop representing the intended grain. Inspect a small order’s joined rows before changing the final aggregation. This makes the diagnosis explainable to an interviewer.

Finally, rehearse a changed requirement. Ask for net revenue, a time range, a category with no completed sales, or tied revenue totals. State whether zero rows should appear and how ties should be ordered. You do not need to solve every extension at once; you need to recognize which assumptions have changed.

Avoid presenting the accepted alias experiment as permission to ignore output contracts in other assessments. Another checker may compare headers strictly, and a downstream consumer may require an exact schema even when a practice site tolerates a difference. Meet the written contract unless you have a reason to clarify it.

Five questions for business-SQL transfer

These PracHub records provide further metric, join and revenue reasoning. They are independent preparation prompts, not SQLPrep integrations or a prediction of company questions.

Use the sales-and-customer prompt to explain the full metric contract. Use the join-debugging question when your row count changes unexpectedly. The advertising and net-revenue records change the meaning of the numerator and exclusions, which is valuable practice precisely because the original retail calculation cannot be reused unchanged.

SQLPrep’s inspected free task offers useful feedback on business values and ordering. The best next step is to pair that feedback with a tiny dataset you can calculate by hand. Then choose a related question from PracHub’s SQL interview collection and explain why your result answers the business question, including the assumptions a green practice result leaves unresolved.

Sources and further reading

• SQLPrep homepage, datasets and free revenue workspace
• Revenue by Product Category: full problem
• SQLPrep Pro: coming-soon feature and waitlist descriptions
• SQLPrep privacy policy