Assessments
Build tests and quizzes that grade themselves — 17 question types, partial credit, negative scoring, time limits, shuffling, retake policies, and a manual grading workflow for open-ended answers.
Overview
An assessment is a graded test built in the assessment builder. Participants take it through a link; every attempt is graded at submission and lands in the workspace as a submission you can review, grade, and analyze.
Layout is up to you: everything on a single page, multi-step with several questions per page, or strictly one question at a time.
Question types
Most types grade automatically; essay and code writing always go to manual review. Types marked with partial credit can award fractional points when partial scoring is enabled.
Knowledge & recall
Matching & organizing
Code
Pacing
Grading & scoring
Every answer is graded the moment the assessment is submitted. Auto-graded questions score instantly; essay and code-writing answers — and any auto-graded question left unconfigured — are flagged for manual review, where a grader assigns points from a dedicated grading screen.
Partial credit
With partial scoring enabled, supported types award fractional points — three of four correct matches earns three quarters of the question's points. Each question can override the assessment-wide setting either way.
Negative scoring
Optionally deduct a percentage of a question's points for a fully wrong answer. Only submitted answers are penalized — blanks never are — and the assessment total never drops below zero.
Passing score
Choose a preset or enter a custom percentage in Scoring → Passing score. Use the separate Pass/fail control to show that result to participants. Results chooses how much detail they see afterwards: nothing, the score only, or a detailed per-question review. Partial credit, wrong-answer penalties, question order and question selection also have their own controls in this category.
The grading screen
Manual grading happens on a dedicated screen that walks through the submission question by question. Every answer carries a status — correct, incorrect, partial credit, no answer, or needs review — and a summary panel tracks grading progress, the running score, and whether the participant currently passes.
A final review step warns about questions still awaiting review or left blank and shows exactly how many points the participant will receive. Grades stay editable after submitting — a grade is never locked in.
Coding assessments
Alongside standard assessments you can create a coding assessment — a dedicated type chosen when the assessment is created. Instead of mixed question types, it is an ordered set of coding problems, and it counts against the same assessments-per-workspace limit as any other assessment.
A Professional feature
Problems & test cases
Each problem has a problem statement, one language chosen by the author, optional starter code participants begin from, and an optional reference solution visible only to authors. You can add up to 20 test cases for automatic grading — each pairs an input (stdin) with the expected output. Test cases are optional; problems without them go to manual review.
Test cases can be visible or hidden. Visible ones act as samples participants can run their code against; hidden ones run only at grading, so the full test suite is never exposed.
Supported languages
Thirteen languages are supported: JavaScript, TypeScript, Python, Java, C, C++, C#, Go, Rust, Ruby, PHP, Swift, and Kotlin. Each problem targets exactly one of them, chosen by the author.
The participant experience
Participants work in a full-screen IDE-style environment: one problem per screen, the statement beside a code editor with syntax highlighting, autocompletion, in-code search, and adjustable editor preferences. Before submitting they can run their code against the visible sample tests as many times as they like, or execute it with custom input in the built-in console — hidden tests stay out of reach until grading.
How coding problems are graded
For problems with tests, each submitted solution is compiled and executed server-side in a sandboxed runner against every test case — visible and hidden. With partial credit enabled, the score is the problem's points multiplied by the share of passing tests; otherwise it is all-or-nothing. Problems without tests go to manual review.
Output comparison trims surrounding whitespace and ignores letter case by default; both can be configured per problem. If code execution is unavailable or a problem has no test cases, the submission routes to manual grading instead of scoring zero.
The coding editor groups settings under Access, Rules and Design. Time limits, attempt limits, passing scores and Retake delay use menus with presets and custom numeric values. Score policy offers highest, latest or average score directly from its menu. IP restrictions, Group restrictions and Scoring rules each open their own focused dialog. Current values stay visible in the ribbon; analytics and exports remain available in the workspace. Search settings and actions from the field after the ribbon categories, or press Ctrl/Cmd-K.
Timing, attempts & shuffling
Use Rules for timing, attempts, retake delay and score policy; Scoring for the standalone grading and question controls; Access for availability and participant restrictions; and Design for layout and appearance. Proctoring contains monitoring and exam-browser settings. Numeric menus accept custom values; settings with several fields open focused dialogs. Search settings and actions from the field after the ribbon categories, or press Ctrl/Cmd-K. These controls shape every attempt:
Participant identity
In the ribbon's Access category, use Participant identity to choose fully anonymous, name only, or username-and-password credentials you manage per participant. IP collection has a separate dropdown for anonymous assessments. Both controls show their current setting on the ribbon.
Identified participants make attempt limits, retake delays, and score policies meaningful — the platform knows which attempts belong to the same person.
Import and export participant accounts
In Assessment Participants, choose Import CSV to add up to 500 accounts at once (256 KB per file). Download the template and edit its example row. The username and password columns are required; full_name, email and is_active are optional. Usernames use 3–24 letters, numbers or underscores; passwords use 4–24 characters. Use true or false for is_active; a blank value means active. Review the preview before importing. Invalid rows or duplicate usernames stop the entire import without changing existing accounts. Import requires participant management permission and a Professional or Enterprise plan.
Export CSV downloads all participants matching your search and filters across every page. You can also select rows and choose Export selected. Export requires participant viewing permission. Passwords are excluded by default; select Include passwords to include readable credentials, or fill in the password column before importing the file into another workspace. CSV exports protect values that spreadsheets could interpret as formulas; importing an unchanged export restores those values.
A Professional feature
Submissions & analytics
Every attempt appears in the submissions list with its score, pass or fail state, grading status, and any proctoring flags. Open a submission to review it answer by answer, or jump into the grading screen for manual questions.
The analytics dashboard aggregates performance across submissions — score distributions, pass rates, and per-question statistics — and everything exports to CSV, Excel, JSON, or PDF on every plan. The Analytics & Exports guide covers both in detail.