Reviewing Results
How hiring teams should interpret Merge assessment output.
Merge results are meant to support human hiring judgment, not replace it. Treat the result as structured evidence about how a candidate reviews code.
Result Contents
Section titled “Result Contents”A result can include:
- candidate submission
- grading summary
- rubric-level observations
- proctoring events
- timestamps
- assessment context
What To Look For
Section titled “What To Look For”Strong candidates usually:
- find important correctness issues
- explain consequences clearly
- avoid spending all their time on style-only comments
- suggest practical fixes
- identify missing tests or ambiguous requirements
Weak submissions often:
- list generic concerns without tying them to code
- miss obvious failure paths
- over-index on formatting
- provide fixes without explaining the risk
- ignore product context
Calibration
Section titled “Calibration”Before using a result as hiring signal, compare it against known examples from your team. Decide what “hire”, “lean hire”, and “no hire” look like for your engineering bar.
Reviewing Proctoring Events
Section titled “Reviewing Proctoring Events”Proctoring events should be used carefully. A snapshot or browser event is context, not a verdict. Look for patterns and combine them with the submission itself.