How we build custom applicant tracking system

As the hype around the elaborate automation of business processes continues, a relatively huge part of automation software accounts for recruitment tools. The market abounds with the numerous services, ranging from generic recruiting platforms and applicant tracking systems (ATS) to as ingenious ones as Textio. This, for instance, utilizes linguistic assessment algorithms to rank job listings and highlight biased phrases that may dramatically influence an outcome pool of candidates.

With the ubiquitous tendency to supplant white-collar duties by algorithms, it’s becoming a challenge to make a difference on the recruitment software market. However, off-the-shelf solutions may either be superfluous or lacking functionalities for the specific businesses and their HR-frameworks. That’s why the demand for custom recruitment options remains stable.

IDEA

Should I choose custom or off-the-shelf?

“I could do better or, at least, design it better! Why this button is here anyway?”

Every now and then we get annoyed of devices and interfaces we come across and use. Baffling algorithms of the Facebook news feed, compulsive and timid Windows checking back any action you want to take:

“Do you really want to delete this file? That may be dangerous. Think twice!”

Knowing that you could design better or have something more adapted to your needs drives opting for custom solutions.

Since one of the major expertise spheres of DDI Development is recruitment platforms, we often receive requests to develop customizable systems for various HR-needs. Last year we were engaged in building a custom ATS, the recruitment service for the client’s company internal needs.

Our client’s team undergoes dynamic growth, and their HR-department has recently felt short of management tools to make the recruiting of new hires coherent. For the company of 50-100 employees, that may not be an issue. But once a team turns 200 or more and the number of everyday interviews reaches at times dozens, it takes meticulous records to keep every applicant’s story up-to-date.

There are available applicant tracking systems on the market that streamline and help to manage a recruitment process with numerous everyday candidates. However such efficient platforms as RecruiterBox are merely designed to serve all types of businesses, regardless of a sphere and recruitment patterns. Basically, an employer has to augment a recruitment workflow with extra tools specific to a company niche.

For this very reason, the client of ours decided to integrate and adopt a custom environment for hiring mainly IT-specialists. It had to contain following tools:

• Vacancy openings with candidate assessment stages, CVs import and retrieving data into a database;
• Generating candidate’s profiles with candidate’s assessment tracking;
• Dashboard with tasks displayed, calendar, and agenda;
• Candidate search with filters.

As the idea evolved, the client decided to build not only the internal ATS but also distribute its capacities and sell the system as a service for those companies which experience the same IT recruiting issues. Basically, we moved from the custom concept to the off-the-shelf as the overall idea was building up and the system seemed promising in terms of its growing versatility.

THE MAJOR CHALLENGES

Taking project off the ground

As we also practise off-the-ground policy which implies building MVP to start with, the core objectives of our work were:

• To research existing recruitment options on the market;
• To design and deliver MVP for the initial project evaluation;
• To compose the roadmap of further customization to meet specific needs.

This type of cooperation between a company and a stakeholder required intensive feedback on deliverables and ongoing adjustments. The client opted for the dedicated team model to handle swift development with flexible technical requirements.

Lean project requirements

As we launched a research there were three major points to be considered.

• Parsing mechanism and importing CVs: the ways candidates appeared in the database.
• Roles: types of users accommodated, who belong to the same enterprise though differ in their permissions within the system;
• Recruiter workflow: the ways user flows through the interface and manages to assess candidates.
• Search engine: the tools to retrieve CVs out of the database with regard to set search criteria.

The major features of the ATS are providing tools for a company owner and employees to set a vacancy opening, decide stages of candidates assessment, align available candidates with those stages, and track the whole recruitment course from an initial email to a hiring date.

SOLUTIONS

User roles

It’s not very common for existing recruitment solutions to have multiple user roles. And in most cases puzzling a system with numerous patterns of behaviour regarding a user status isn’t the right approach. An average recruitment system is designated to be utilized by an HR-specialist who performs all actions within it. Why should things get more complicated? It’s not that functional division between users from a single enterprise is useless, it’s that elaborate development isn’t worth an outcome in most cases.

However, as two rounds of negotiations passed the pitfalls of a single recruiter role unraveled.

Owner. If we assume that payments within the platform are tied to a number of vacancy openings, who is supposed to be in charge of a financial side? You either let a common recruiter release payments or these activities may be available for a company owner only. If we take the latter, that implies, at least, two roles: a recruiter and an owner.

Manager. An HR department of a company with 50+ employees usually has several specialists, including managers and common recruiters. As managers assign tasks, recruiters may be in charge of some particular candidate assessment stages while the final decisions are made by managers or even owners. So, we’ve considered adding manager’s role who would be able to create new vacancy openings, decide stages, and assign particular tasks for recruiters to complete within stages.

Recruiter. Moreover, if a recruiter leaves the company managers and owners will keep the history and will be able to reassign tasks to other recruiters.

Having this in mind, we’ve come up with 3 user roles.

Project structure and technologies

Vacancy opening

Generic interfaces for vacancy openings seemed too overwhelming for us since they may require a lot of data to be input and numerous minor tweaks. We didn’t want to deter a user from the interface like an operation board at a nuclear power plant.

The flow we offered divides the opening stage into 4 aspects. This solution allowed both to embrace all the data inputs we needed and make a process more approachable:

• Title an opening
• Decide hiring stages: e.g. screening, phone interview, in-office interview, etc.
• Add job listing and details (years of expertise, technologies, desired salary)
• Import CVs

Recruiter dashboard and calendar

It took much of discussions of what is actually supposed to be on a dashboard. From the technical standpoint, the dashboard is pretty simple and represents conveniently organized links to the most important data feed you receive and operate within the system. But how do you make it really convenient and clear and what actually is supposed to be displayed?

• How assigned tasks are going to be showcased?
• Are the stages of candidate assessment going to be displayed?
• How is the feed filtered according to a user role? Will be an owner capable of tracking the tasks of employees?
• What are the additional data a user may see here?

Considering these issues, there was a requirement making our goal even more challenging. The core objective for our UX-specialist was to make an experience as much seamless as it was needed to adopt the system within one business day for a common user. We have mocked up several wireframes and elaborately tested them until we come up with the smoothest interface.

The system makes it inevitable for a recruiter to keep everything under control showing all assigned events and reminding if something missed. Once a user sets hiring stages, he’ll be able to correlate each event with a date in a calendar nearby.

Modular and responsive approach to each chunk of information lets users customize their environments for different types of displays.

List of candidates, search engine, and semantic network

Besides a dashboard with tasks notifications, the list of candidates is another important environment that a recruiter deals with. As the database grows with candidates it becomes tedious to retrieve the right candidates out of a list, especially when you measure them in hundreds. The solution to this issue is building a convenient search engine with both major and specific tweaks.

We’ve started with generic filters ample to be applied for all types of candidates:

• Words. Any words mentioned in messages, names, etc.
• Stages. The system will showcase the candidates in regard to a chosen stage.
• Openings. As candidates are related to vacancies, you may filter them accordingly.
• Date. A user may set a date range to see all the candidates added within this time period.
• Labels. You may assign custom labels to each candidate and search by them.
• Location. Places where candidates dwell in or ready to move for work.

As we were aligning the system with IT-recruiting, we’ve decided to add a number of search filters specific to this niche.

• Technology. We’ve designed a semantic algorithm which retrieves listed technology skills and number of years candidate utilizes technology from CVs and adds them to each candidate’s profile.
• Experience and technology. A user can set search in accordance with years some particular technology has been used by a candidate, set ranges to receive a relevant search feed.
• Technology type. The candidates’ profiles can also be filtered in regard to different technology types such as a pure language, database, framework, CMS, etc.
• Salary. The algorithm would is also able to retrieve numbers related to the desired salary so that a user can filter results in amount ranges.

The most challenging part was designing a semantic algorithm which would find data related to technology, experience, and salary in PDF, CSV documents as well as at web sources.

Candidates profiles

One of the features that exceed the MVP version and undergoes constant improvements is rendering a user profile. As we’ve applied the semantic algorithm, we’ve decided to utilize it more ingeniously. Besides regular candidates data fields, we’ve decided to create a graphic representation of technologies skillsets.

The skills graphs show relations among different technologies a candidate is armed with. They also graphically show the expertise level defined by the number of years this technology is being utilized. In order to make it visually work, we’ve used D3JS capacities.

Unfortunately, most of the candidates don’t correlate technology skills with years in their CVs yet this as we believe is a rather informative criterion. In order to elicit this information, recruiters have to manually add years into a candidate’s profile after initial hiring stages.

The obvious question is:

“Do you really need to allocate so much effort to a feature that merely seems a gimmick?”

With that being an extremely reasonable argument, we’ve considered why those graphs worth it:

• Convenience. Reading through technologies lists in CVs is tedious and, by the end of a day, a tired recruiter with an opaque vision is likely to miss something important. Graphs allows assessing the overall picture at a glance.
• Relations can file off the lack of understanding. Recruiters aren’t yet engineers though they know some basics. In IT, job listings may be both specific (“We need a Python/Django ace”) or general (“We need a topnotcher who is well-versed in a few Python frameworks). For the second case with Python being a core skill, you can easily define that a candidate knows some Python frameworks regardless of whether you heard of them or not.

  

• The feature is reusable. That’s the argument related to our “Innovation Labs” approach. The noSQL database of relations in software development can be efficiently utilized for many platforms related.
• Relations can be customized and manually updated. The major flaw of this idea is that you’ll never be able to cover all the numerous relations as a potential number of technologies is intimidating and huge. Yet there’s a solution. Along with prebuilt relations, we’re planning to integrate an interface allowing to manually add technologies into the DB and set relations specific to corporate recruitment needs.
• It looks good. Sounds silly though infusing aesthetics into the HR workflow is a way to encourage professionals to be productive. Well, that definitely isn’t a point subject to HR-departments only.

The implementation of this idea is still in its infantry and we keep exploring options to enhance the algorithm.

ACHIEVEMENTS

The MVP was adopted as an internal ATS and currently supports the needs of our client’s enterprise. As we’re incrementally adding new functions, the system has helped to process over 150 candidates and more than 1000 candidate profiles have been generated.

Semantic algorithm. The major advancement compared to existing solutions on the market is the semantic network which helps to set clear vacancy requirements and filter CVs that aren’t matching when importing. However, the system is yet to be enhanced. As we parse and import CVs we’re struggling to make the algorithm correctly retrieve the data out of its initial source since CVs are all written differently by candidates. Now, the algorithm clearly distinguishes skills and other data that are in the DB but at times fails to correlate those with numbers.

UI/UX and responsiveness. We’re making the system which can easily be operated via any device. The modular customizable interface and responsive design help to react on changes rapidly regardless of a recruiter’s current situation. For instance, some recruiters engaged in testing are completing their assignments when commuting.

Niche-specific yet general. We’re developing an environment which would be comfortable to use for an IT-company. Though it potentially can be utilized by enterprises of various niches as the semantic network can be customized manually which merely allows to add any skill into the DB and tweak its relations among other input skills.

Stay tuned for updates.