Our older test creation flow had several inherent problems associated with it: 1. Profile drivenEarlier to this, we had test creation based on job profiles (role-based), which was restrictive as the skills were tightly coupled to the roles and were not customizable by the recruiters. For example, I could select a profile say front-end engineer […]
Our older test creation flow had several inherent problems associated with it:
1. Profile driven
React skill, they had to add them manually from our questions library or theirs.
2. Complex UI
The older interface was filled with unwanted form elements and had almost no provision to support newer question types. We somehow missed to provide a scalable and an intuitive step-by-step test creation flow that catered to the needs of our non-technical recruiters.
3. Rigid algorithm
The algorithm we used for selecting the test questions was relatively rigid, so there was a limited scope in picking questions from a mix of skills and of varied difficulties, either from the HackerEarth’s questions library or from the company’s library or both.
4. Restricted question types
Though there was a demand from our customers to include additional question types such as SQL, front-end project and Java project questions to the test creation flow, we could not accommodate them as the interface was already bloated.
Your browser does not support the video tag.
Based on the customer feedback and research data, it was important for us to improve the old flow in accord to the correct persona of our users. More focus was put on enterprise talent acquisition teams. We found out that in general scenario, such teams are bound by the following:
The new design was implemented keeping in mind all the requirements by our star designer, Neha Singh. The idea was to keep the interface minimal and distraction free, so to attenuate the cognitive load for the recruiter.
The new skill-based test creation flow involves a stepwise process where bare minimum inputs from a user are taken to auto-generate a test. Primarily, the flow is divided into two screens:
The default selected option would be 0-3 years of experience.
The above mentioned inputs are sufficient to auto-generate a test.
After selecting the skills and experience, the user is shown the summary of the questions selected using our algorithm. They can simply click on the “Create Test” button to get the task done. The following information would be shown, in case they want to edit any information:
<First skill name> Test. This was an assumption based on the philosophy that the recruiter would usually choose the first skill as the most important one. This implementation helped to reduce the effort needed to type the heading always
The new skill-based test creation was a complex implementation. Around 5,000+ lines of code was added to get the feature up and running without bugs. I would try to be precise in explaining the front-end engineering behind it.
The app was built using
React v15+ (now using v16.8.5) and
Redux. The modules were bundled using
Webpack. We maintain a default config for all our
Webpack apps. So, to create the config for new test creation app, the following changes were added:
WebpackConfigGenerator is our in-house implementation. It is a class consisting of various methods to handle the default configuration such as
module loaders. The
isExternal criteria checks if the modules are from
node_modules directory or any other external library. So, with the above config, we get 2 JS files viz.
vendors.js and dependent CSS files.
Based on the new interface, the following components were required:
Disabled create test link
We have planned to restrict the new skill-based test creation to few customers at first. Moreover, in case of API or server failure, a recruiter should not have access to the test creation modal but should be able to create a blank test. Hence, separated out this component.
We already had a full width modal component and planned to use that.
Custom select dropdown with tags
This was built over the
React Select package.
The prominent aspect was to create a separate component for options dropdown. The
Select component provided by the package, expects a prop
optionComponent. The component
CustomSelectOption was used for that. It was responsible for handling mouse events like
options object, containing the selected status of every option, was provided as
props by the parent component
SkillsInputContainer was responsible for handling skills and experience selections, providing a link to create a blank test and showing statuses such as “You can add more than one skill to your test” and “Maximum number of skills selected. Please remove existing skills to add more”.
Stylus for writing
CSS. We already had custom design for input fields, but the design for this particular use case was a bit different. As we were using common code from the
React Select package, we had to overwrite most of the default
CSS code to make the component as per the design.
By default, the test name is created using the first skill selected by the user. In case the recruiter wants to edit the test name, they can click the heading and edit. This component also handles the case if the recruiter clears the test name. In such case, the default name populates again immediately when the input is focused out.
Notifies which question set was updated along with the test duration update.
Test summary container
We used our own UI framework, Nuskha, for building out tables. We had to follow a particular HTML structure to build the required table.
Basic structure to generate a table with 2 rows:
In the above code snippet,
action-icons-container contains two icons blocks viz. edit and delete. The delete icon is used to load a
popup component for confirmation while the edit icon will take the recruiter to edit the existing question set.
Question set table
For recruiters, we had kept the options to edit an existing question set and add a new question set. While editing or creating a question set, they can update skills, question type such as MCQ and Programming, and question counts for each difficulty level. The interface take care of the duration update.
If a recruiter is mistakenly trying to override and existing set, we prompt them for confirmation to save the hassles.
The algorithm that we use to populate initial set of questions is a complex one. We use parameters such as experience levels, skills selected by the recruiter, difficulty levels, and types of skills selected to display a summary table with appropriate question sets.
Our internal algorithm tries to create a test of 90 min duration first, however if there are not enough questions then it will fall back to 75, 60, 45 minutes in that order. These are the durations with which we had started and had the following restrictions or limitations:
Of course, the above logic is just the tip of the logics ice-berg that we use to auto-generate a skill-based test.
With this feature in place, we aspire to add a few differentiating aspects to it as well.
I will also take this opportunity to thank one of the great engineers that I have worked with, Jagannadh Vangala aka Jaggu for being the perfect ally in diligently completing this project together.
Posted by Chandransh Srivastava