ASSESSMENTS · PLACEMENT PREPARATION

Building a placement assessment experience around HyreNet

At HCL GUVI, I owned the Placement Preparation mock-test frontend from discovery and reports through coding assessments, and later contributed backend changes for B2C access and multiple organisations. GA4 recorded 25,038 views from 8,249 active users on mock-test pages during July–September 2026. Those figures describe use of the experience, not growth attributed to a single change. HyreNet supplied the assessment engine, and the original assessment backend was primarily a teammate’s work.

The learner journey around the assessment engine

  1. Discover a test
  2. Sign in to start
  3. Take the assessment
  4. Wait for report readiness
  5. Review explanations
Simplified learner journey. Result visibility is enforced by server-side organisation policy, while the frontend presents the appropriate state.

The problem: make an existing test engine feel native

Placement Preparation already offered learning material, but students needed a place to discover timed assessments, take a test and understand their results. GUVI’s HyreNet product supplied the assessment engine and college question banks. The task was to bring that capability into a coherent learner experience rather than rebuild the engine.

I owned the mock-test frontend from its first release through the coding-test experience. I later contributed backend changes for B2C access and multiple organisations. The original HyreNet backend sync, ranking and cutoff logic was primarily a teammate’s work.

Build for the states between launch and report

The learner journey includes more than a working launch button: an upcoming test, an active attempt, a completed session and a report that may not be ready yet. I built discovery and report interfaces, including retry and invalid-report states, and added explanations rendered from Markdown with MathML support.

Report availability is policy, not a cosmetic UI choice. College drives need results withheld until the testing window ends, while self-directed B2C users may need immediate feedback. Keeping that decision on the server lets the frontend show the correct state without making the browser responsible for enforcement.

Open discovery, then support coding assessments

The experience later expanded beyond partner-college users. Guest browsing let anonymous visitors see available tests, with login requested when they tried to start an assessment. My backend contributions included separate B2C credentials and guest listings; test metadata and result visibility remained tied to the organisation rules.

For coding assessments, I built a split-pane editor with run/submit flows, draft autosave, a countdown and resume support. A timeout must not discard a valid last-second submission, so auto-submit waits for an in-flight submission before completing the attempt. These edge cases are part of making a timed test dependable, not optional polish.

Reach and the boundaries of the claim

GA4 recorded 25,038 views from 8,249 active users on mock-test pages during July–September 2026. The mock-test landing page was the site’s third most-viewed page after the homepage and signup. Production records also showed more than 1,000 test submissions.

Those figures describe use of the experience, not a controlled estimate of the effect of any one change. In particular, the project did not have a clean guest-before/guest-after conversion comparison, so this case study does not attribute a specific signup lift to guest browsing. Design, assessment infrastructure and product delivery were collaborative; this page distinguishes my frontend ownership and later backend work from the team’s contributions.