Assessments
How to build a multi-stage technical hiring assessment
Split aptitude, coding, and written work into stages with their own timing and scoring, then review responses before anyone moves forward.
A single two-hour “tech test” asks too many questions at once: Can they reason? Can they code? Can they explain? Can they finish under time? When those signals share one score, interviewers argue about what the number meant.
Multi-stage technical hiring is the practice of giving each question a job.
Why stages beat one composite exam
Graduate and lateral engineering hiring usually needs at least two instruments:
- A short screen that is cheap to run at volume
- A deeper task that is expensive to review
If you only run the deep task, you drown reviewers. If you only run the screen, you hire for speed on MCQs. Stages let you spend human time where the remaining pool is small.
A practical pattern:
| Stage | Typical format | Decision |
|---|---|---|
| 1 | Timed MCQ / short coding | Eligible for the work sample |
| 2 | Coding + written or file task | Eligible for interview |
| 3 | Live interview | Hire / hold / reject |
Progression rules should be numeric enough to be fair, and human enough to allow exceptions.
Choose formats that match the role
Edgeryt Hire assessments can combine multiple-choice questions, coding exercises, written responses, and practical file submissions. Use your own questions or start from the question library.
- Backend / DSA roles: coding with hidden tests, plus a short written explanation of trade-offs.
- Data roles: SQL or Python coding plus a file or notebook-style submission if that is the job.
- Product / analyst roles: case-style written answers; skip coding if the job does not require it.
- Campus mixed drives: aptitude section first, coding only for engineering tracks.
Do not add a format because it looks rigorous. Every extra format is more candidate time and more review time.
How Edgeryt Hire organises stages
Hire lets you organise assessment stages and progression rules, then review candidate scores and responses before moving people forward. Applications, scores, and stage progression stay on the role, so a later interviewer is not opening a ZIP of CSVs.
You can also keep recruiter and interviewer access separate, so campus coordinators can move stages without exposing every comment.
Related: coding tests for campus and lateral hiring and question-bank import.
Implementation notes that save the week of the drive
- Time-box each section. Open-ended “complete whenever” stages stall campus calendars.
- Tell candidates whether they can go back to earlier questions.
- Calibrate difficulty on a small internal sample before the TPO sends the link.
- Store a version of the assessment. Editing live questions mid-drive makes scores incomparable.
- Review a handful of full attempts before you trust the cut-off.
Adjacent area: interviews are a stage too
Scheduling Google Meet or Microsoft Teams from the same record is part of the assessment design, not an afterthought. See interview scheduling.
Questions teams ask
How many stages is too many?
If candidates cannot finish in one sitting you planned for, or if reviewers cannot explain each gate in one sentence, cut a stage.
Should later stages hide earlier scores from interviewers?
Some teams hide numeric scores to reduce anchoring. Others show them with the responses. Pick one rule and apply it to the whole drive.
Can we reuse stages across roles?
Reuse question banks. Rebuild progression rules per role so a backend cut-off is not copied onto a non-coding internship.
Next step
The overview lists assessment and shortlisting capabilities. Pricing covers plan limits. Request a demo if you want to map stages to an existing graduate paper.