Click to upload or drag and drop
PDF, DOCX, PPTX, TXT, JPG, JPEG, PNG, HEIC, ODP, ODT, BMP, or TIFF
up to 20MB
Uploading...
To screen candidates with a knowledge quiz, generate the questions from the documents that already define the role, the job description, the SOPs, the training deck, then keep the quiz to 10 to 15 questions and 15 minutes. Test only knowledge the job actually requires on day one, score every candidate against the same key, and use the result to rank rather than to reject outright.
That constraint about generating from role documents is not a stylistic preference. It is what keeps the quiz defensible. A screening test that draws its questions from the documented requirements of the job is job-related by construction. A test somebody wrote from memory, or pulled from a generic question bank, is much harder to justify if a candidate ever asks why they were screened out.
It is a filter, not an interview. The job is to tell you, before you spend 45 minutes on a call, whether this person knows the things the role assumes they know. A bookkeeping hire who cannot identify an accrual, a support hire who has never seen a ticketing workflow, a warehouse lead who does not know the safety terminology, all of that surfaces in ten minutes instead of an hour.
What it is not for is measuring judgment, communication, or whether someone will be good at the job. Those are interview questions and work samples. Knowledge quizzes are cheap and fast at exactly one thing, and stretching them past it is where hiring teams get into trouble.
| Source document | What it produces | Use it for |
|---|---|---|
| Job description | Terminology and required-skill questions | The baseline screen, every role |
| Standard operating procedures | Process and sequence questions | Operations, support, clinical, warehouse |
| Training deck or onboarding docs | Questions matching what you would teach in week one | Checking who can skip the basics |
| Compliance or safety policy | Rule and threshold questions with one right answer | Regulated roles, OSHA-relevant work |
| Product documentation | Domain vocabulary questions | Sales, support, technical writing |
| Software manuals | Tool-specific questions | Any role where a named system is a requirement |
The practical move is to upload the actual document rather than trying to remember what is in it. A job description run through a question bank generator produces more usable screening items in a minute than most hiring managers write in an hour, and every item traces back to something the role genuinely requires.
Ten to fifteen questions, fifteen minutes, and say the time up front. Completion rates fall off a cliff past twenty minutes, and the candidates you lose first are the strong ones with other offers in play. A short, clearly job-relevant test reads as respectful. A 45 minute assessment before a human has spoken to anyone reads as a company that does not value your time, and word travels.
Mix the difficulty deliberately. Two or three easy items confirm the basics, the middle band does the real sorting, and one or two harder items separate the top of the pile. If everyone scores 95 percent, the quiz is not doing anything. If the median is under 40 percent, you are testing things the job description never asked for.
Multiple choice for anything with a defensible right answer, because it scores itself and scores identically for every candidate. That consistency is the whole point of a screening instrument. True or false is fine for policy thresholds and rules but weak elsewhere, since a coin flip gets half of them.
Short answer earns its place for two or three items where you want to see how someone explains a concept, and nowhere else. Every short answer question is a human reading and judging, which is exactly the cost the screen was meant to avoid, and it reintroduces the inconsistency that structured screening exists to remove.
Avoid trick questions completely. They measure test-taking, not competence, and a candidate who spots the trick and resents it is a candidate you lose for no reason.
In the United States, a pre-employment test is a selection procedure, and the same rules that govern interviews govern it. Three practical guardrails cover most of the risk.
First, job-relatedness. Every question should map to something written in the job description or the role's documentation. Generating the quiz from those documents makes this straightforward to demonstrate.
Second, consistency. Same questions, same time limit, same scoring key, same stage of the process for every candidate for that role. Ad hoc adjustments are where disparate treatment claims start.
Third, accessibility. Offer accommodations, state clearly that they are available, and do not build a test that depends on speed unless speed is genuinely part of the job. Also check your state and city rules, since several US jurisdictions now regulate automated tools in hiring specifically.
None of that is a reason to skip screening. It is a reason to build the quiz from documentation and score it the same way every time, which is easier than the ad hoc alternative anyway.
After the application, before the first call. Candidates who clear the knowledge bar go to a human, and the quiz result travels with them so the interviewer can probe the specific gaps instead of covering ground the test already covered.
At volume this only works if the surrounding pipeline is automated too. Teams running hundreds of applicants typically pair the knowledge screen with a system that sources and ranks candidates before anyone opens a resume, so the quiz filters a shortlist rather than the entire inbound pile.
One more use worth knowing: the same quiz, given again after 90 days, tells you whether onboarding actually worked. If new hires who scored 60 percent at screening still score 60 percent after a quarter of training, the training is the problem. The employee training quiz maker covers that side, and compliance training quizzes handle the regulated version where the records matter.
Yes, when the test is job-related and consistent with business necessity, administered the same way to every candidate for that role, and offered with reasonable accommodations. Problems arise when questions test knowledge the job does not require, when the test is given inconsistently, or when it produces a disparate impact the employer cannot justify. Several US states and cities also regulate automated hiring tools specifically, so check local rules.
Ten to fifteen questions and no more than fifteen minutes, with the time stated before the candidate starts. Longer tests reduce completion rates, and the strongest candidates with competing offers are the first to drop out. If you need more depth, use a work sample later in the process rather than extending the screen.
Only the knowledge the role requires on day one: terminology, core processes, tools named in the job description, and any regulatory rules the job depends on. Leave judgment, culture fit and communication to the interview. If a question does not trace back to something in the role documentation, cut it.
Yes, and it is the most defensible starting point you have, because the job description is the written record of what the role requires. Upload it, generate the question set, then review every item and cut anything that tests knowledge the role does not actually need. Adding the SOPs or training materials gives you deeper, more process-specific questions.
Telling candidates whether they passed is good practice and costs you nothing. Sharing per-question answers is not, since it degrades the test for everyone who takes it afterward. A short message stating the outcome and the next step handles most of the goodwill without compromising the instrument.
Building one this week? Upload the job description or the SOPs and generate the screening questions from your own documentation, then review, set the time limit, and send the same test to everyone.
From the same family of tools