Writing a problem
Authoring a coding problem end to end - the signature, examples, reference solution, the checks that must pass before it publishes, and what review looks at.
Problems on Revquix are not all written by us. Anyone can ask for the ability to write one, and the process is deliberately more demanding than a text box - a broken problem costs every person who attempts it far more than it cost to write.
Getting access#
Professional mentors have authoring already. If you conduct paid mock interviews on Revquix, your authoring page is open to you now - nothing to request.
For everyone else authoring is off by default and is requested in one click from the same page. Once granted you can create problems, edit your own drafts, and send them for review.
Publishing directly - and reviewing or editing other people's - is a separate, higher permission held by the Revquix team. Your own problems are yours: no other author can open or change them.
What you build#
A problem is not just a statement. Six pieces, and the editor walks you through them:
-
The details - title, difficulty, one to five topics, and the constraints. The first topic is the primary one and is what shows on the problem list.
-
The signature - the function's name, its parameters and their types, chosen from a fixed list (integers, strings, booleans, arrays, matrices, linked-list nodes and so on). You write this once, language-neutrally.
From it the platform generates both the stub each solver sees and the code that calls their function. You never write either, in any language, which is why adding a language to your problem is a checkbox rather than a rewrite.
-
The statement - the prose, in a rich editor.
-
The test cases - a handful of samples and at least eight hidden ones. You supply the inputs only.
-
The reference solution - a correct solution, in every language you offer.
-
An input generator, optionally - a small program that builds one input of size
n. This is what enables Analyse my solution for people solving your problem. It can be added later, to a problem that is already published.
Suggest edge cases#
The test-case editor can ask AI for edge cases you may have missed - the empty input, the single element, the duplicate values, the maximum constraint. It costs credits, and the price is shown before you press it.
It suggests inputs only, never answers, and you add them one at a time after reading each. There is no "add all": the point is you deciding, not padding the case count without looking.
The checks#
Before a problem reaches a reviewer - and before a direct publish - the platform verifies it. The panel runs them on demand and this is your main loop: draft, run the checks, fix what they find, repeat.
| # | Check |
|---|---|
| 1 | Your reference solution is accepted on every test case, in every language you offer |
| 2 | Expected outputs regenerated from it, never author-typed |
| 3 | The slowest reference run fits comfortably inside the time budget in its slowest language |
| 4 | At least two samples and at least eight hidden cases |
| 5 | Statement, constraints, at least one topic and a difficulty, all present |
| 6 | The statement survives sanitising without losing meaning |
| 7 | It is not a near-duplicate of a published problem |
| 8 | The signature compiles in every language you offer |
Check 1 is the one that matters. It means publishing is not a claim that the problem works - the platform has literally run your solution against your tests and watched it pass.
Check 3 has deliberate headroom, because your reference solution is the optimal one and a student's correct-but-unoptimised solution is legitimately slower. A budget with no slack would reject correct work.
The checks cost several sandbox runs, so they are run when you ask rather than on every keystroke, and the panel shows progress while they go.
Review#
Sending a problem for review locks it - editing it sends it back to draft, so a reviewer is never reviewing a moving target.
A human reviewer looks at the things a machine cannot:
- Is it original? A pasted statement from elsewhere is the thing this step exists to catch.
- Is the prose comprehensible to the person it is aimed at?
- Is the difficulty honest?
- Are the topics right? Wrong tags poison the filters and the tracks.
- Are the hidden cases adequate? The empty input, the single element, the maximum constraint, the duplicates. This is the check that separates a real problem from a toy.
Submitting sends you a confirmation email, so you have a record of what went in and when.
After that you are notified when it is approved, when changes are requested (with the note explaining what), and when it goes live. You are also notified the first time somebody solves it.
After it is published#
Your problem gets its number at publish, not at creation - so abandoned drafts do not burn numbers and leave the published set reading 1, 2, 5, 9.
Its URL is fixed from that point. A problem can later be unlisted - the link still works, it just leaves the lists - or retired, which keeps it readable for anyone who already solved it.
If either happens, you are told, and you are told why: the reason reaches you in your notifications and by email. A draft that never published can also be deleted outright, and that carries a reason too. Nothing you wrote is ever removed silently, and if you think a decision was wrong, reply to the email and say so.
You can also write the Approach for your own problem, and up to five hints.
Related#
Was this page helpful?