Skip to content
Technical screening

Screen on evidence, not on a CV

9 question types in one paper: objective questions scored on submission, coding problems executed against your test cases, and long-form answers your team reviews against a rubric.

  • Mixed sections
  • Weighting you control
  • Question-level analytics

Design the round

One paper, several kinds of evidence

Knowledge, reasoning and implementation ability are different things. A screening round should be able to measure more than one of them.

Mix question types in one paper

A screening round rarely wants only one kind of question. Sections can be objective, coding or both, each weighted the way you decide.

Sections that mirror your process

Fundamentals, then applied reasoning, then code. Each section carries its own question set and contributes its own share of the score.

Weighting you control

Decide what a section is worth. A role where correctness matters more than breadth should score that way, not by accident of question count.

Automatic where it should be

Objective and coding questions are scored on submission. Nobody marks multiple choice by hand, and nobody should pretend prose can be marked without reading it.

Human where it must be

Comprehension, long answer and case study responses go to a review queue with your rubric. The result records who scored it.

Question-level analytics

Difficulty and discrimination per question across the cohort, so you can tell a genuinely hard question from a badly worded one.

Process

From role definition to shortlist

  1. 01Step

    Define what the role needs

    Pick the topics and difficulty mix. Tags and categories in the question bank make this a filter rather than a rewrite.

  2. 02Step

    Assemble the paper

    Add sections, pull questions or draw from a randomising pool, set duration and weighting, and preview it as a candidate would see it.

  3. 03Step

    Screen the pipeline

    Invite candidates as they apply. Objective and coding scores land automatically; long-form answers queue for review.

  4. 04Step

    Compare on the same basis

    Every candidate answered a comparable paper under comparable conditions, with integrity signals attached to each attempt.

Scoring

Automatic where it is honest to be

Objective questions and code have a correct answer a machine can check. Prose does not, and scoring it automatically would produce a number nobody should act on.

  • Objective and coding scores are available the moment an attempt is submitted
  • Long-form answers queue for a reviewer with your rubric alongside
  • The result records which questions were machine-scored and who marked the rest
  • A candidate's total is never a mix of measured and guessed

Scored automatically

  • Single choice
  • Multiple choice
  • Fill in the blank
  • Image based
  • Code snippet MCQ
  • Coding problem

Scored by a reviewer

  • Paragraph / comprehension
  • Subjective / long answer
  • Case study

Fair comparison

Make candidates comparable, not identical

Randomised pools give each candidate a different paper drawn from the same specification — comparable in difficulty and coverage without being the same questions.

  • Specify the pool and how many questions to draw
  • Filter a pool by topic and difficulty so the draw stays balanced
  • Sharing questions between candidates stops being useful
  • Cohort analytics still compare cleanly, because the specification is shared

Same specification

Five medium-difficulty questions on data structures means the same thing for every candidate, even when the five differ.

Comparable results

Per-question analytics show whether a pool is drawing evenly, so a candidate is not penalised for an unluckily hard draw.

Questions

What hiring teams ask

Can one assessment contain both MCQ and coding?
Yes — that is what a mixed section is for. You can also keep them in separate sections with separate weights if you want fundamentals and implementation scored independently.
How do you stop a screening round from just filtering for test-taking skill?
Partly by design choices you make: real coding problems with your own test cases rather than trivia, generous enough time limits, and weighting that reflects the role. Question-level analytics then tell you which questions are separating candidates and which are just noise, so you can fix the paper.
Do you generate an assessment from a job description?
No. Assessments are built by a person from your question bank or a pool. We would rather say that plainly than ship a generator that produces plausible-looking questions nobody has validated for the role you are hiring.
Can different interviewers see different assessments?
Yes. Access can be scoped per assessment, so an interviewer sees only the drives assigned to them, and permissions are set per member on top of their role.
How long does it take to set up a first screen?
If you are writing questions from scratch, most of the time goes into the questions — the assembly itself is minutes. Once the bank has content, a new screening round is a matter of picking sections and setting a window.

Build your first screening round

Free trial, no card. Bring one role and see whether the round tells you something a CV did not.

Have questions? Email sales@parikshafy.com