Interview questions
A reusable bank of coding questions for live interviews, under Interviews → Questions.
These are separate from assessment questions. An assessment question is sat alone against a clock; an interview question is worked through with someone watching and talking. They have different fields and different lives, which is why they are different libraries.
Two kinds
Test cases — function-based and automatically graded, the same machinery as a code question in an assessment. You define a function name, parameters, a return type and test cases; the candidate's code runs against them and the room shows which passed.
Pure code — the candidate writes whatever they like and it runs, showing standard output only. Nothing is graded.
Pure code is the better default for an interview. The point of a live technical interview is watching someone think, and a pass/fail bar in the corner pulls both of you toward the bar. Reach for test cases when you specifically want the candidate to iterate against a target, or when several interviewers need comparable results.
Writing one
| Field | Notes |
|---|---|
| Title | How you find it later |
| Description | The problem, in rich text |
| Language | The primary language |
| Allowed languages | Extra languages the candidate may switch to |
| Difficulty | Easy, Medium or Hard |
| Tags | Free-form, for filtering the bank |
| Starter code | Optional; what the candidate opens to |
| Solution code | Required |
| Interviewer guidelines | Optional notes for whoever runs the interview |
Solution code is required, and that is deliberate. Writing the solution is how you find out that the problem is ambiguous, that it needs more setup than the slot allows, or that it has an unintended trivial answer. Interviewers also need something to compare against at speed while the candidate is still in the room.
Interviewer guidelines are where a question becomes repeatable. What a good answer covers, the hint to give a candidate who stalls, and the follow-up for one who finishes early. Without them, two interviewers using the same question run two different interviews and their scores are not comparable.
Neither field is ever shown to the candidate.
Private questions
Mark a question private to keep it to yourself while drafting. Otherwise it is visible to your colleagues, which is normally what you want — a shared bank is the point.
Publishing to the library
A question can be published to the shared library, making it available beyond your own company. Consider whether you want it there: a question circulating publicly is a question candidates can prepare for, which is fine for a warm-up and fatal for your best signal.
Using them
Questions reach an interview two ways: bundled into an interview template so every interview for a role opens with the same set, or imported into a running session from the room.
The room tracks time spent and run count per question, and both appear on the report. They are useful context — a candidate who ran their code twelve times on one question was working differently from one who ran it twice — but they are observations, not scores, and they mean nothing without the code beside them.