Dice’s enhanced Recruiter Profile system, offering the ability for recruiters to link their profile to active job postings and highlight news and hiring needs within their profile, is live on the platform. Like any feature upgrade or similar build, what you don’t see in the final product is the process the team went through to overcome development and logistical challenges. From the integration of backend systems to legacy code obstacles to working with a team across multiple time-zones, we’ll walk through the lessons we learned throughout the process to bring Recruiter Profile to market.
As always, it helps to start with objectives. The primary goal of the Recruiter Profile upgrade is to allow recruiters to more effectively showcase their brands to candidates, build credibility and better connect recruiters to their active jobs. In addition, from a development perspective, the enhancement needed to provide:
- High deliverability and uptime (little—or zero!—downtime).
- Fast request/response.
- High consistency between services (i.e., ensuring data shared between services is quickly kept up-to-date).
- Redundancy.
- High security.
Development teams know that their cloud vendor (such as Amazon Web Services or Azure) can perform some of the heavy lifting behind these tasks. Nonetheless, it’s the responsibility of project managers to ensure that the team is mindful of these objectives throughout the development process. Knowing the end in mind, let’s dig into the primary hurdles we encountered throughout the process, and the solutions our team landed on.
Breaking Away from an Old Service (While Building a New Service)
As developers know, it’s difficult for teams to build new features that successfully break away from older legacy applications. In the case of Recruiter Profiles, our product team wanted to build a new, isolated, and ultimately self-deployable service that didn’t rely on legacy code. Essential to the process: Lots and lots of pre-planning.
Specifically, our team spent time identifying the constraints of the old profile system in order to ensure that the new system wouldn’t break any existing logic. Parallel to that, we engaged in discussions with other teams to get a complete sense of that logic. Only when we had a complete picture did we proceed.
When breaking away from older, monolithic applications, it’s also important to start with building small elements of functionality, while keeping a constant eye on avoiding going beyond the core requirements of the service. In the case of Dice’s new recruiter profiles, there was the possibility that the product would end up used for brands beyond Dice, so it needed to be built in a way that would support multiple brands with slight variations in business logic and functionality.
Building a Single Recruiter Product to Serve Multiple Brands
When crafting the roadmap for a product used across brands, we decided to identify those elements that might end up used in other contexts (with slight variations) and build them as early as possible in the development cycle. This gives teams like ours plenty of time to troubleshoot and debug, as well as plug in brand-specific variations where necessary. On a coding level, it also means creating completely separate areas of code in the “diverging areas” to ensure there are no mix-ups in terms of brand functionality.
Of course, building a product that serves different brands can put pressure on any development team’s resources. In our case, the front-end developers worked to optimize workflow and processes from the outset, before potential problems emerged; back-end developers helped where they could. Trying to clear integration pain-points early in the process won’t prevent all problems from arising, but they can mitigate the scale of some issues.
As with many teams at many companies, our product team must also coordinate with teams across multiple time-zones. The reliance on other teams potentially reduced our autonomy and lengthened the schedule. To prevent that, we depended on regular meetings and catchups; over-communication can mean the difference between unexpected challenges and a relatively smooth process, especially when teams are working remote for the duration of worldwide COVID-19 lockdowns.
Integrating Back-End Systems
With any new product, it’s important to make sure it’s well-integrated with a company’s broader ecosystem of apps and services. For example, it would be unfortunate if a user tried to delete data from a profile, only for that data to (accidentally) persist in other parts of the site.
When it came time to architect the enhanced recruiter profiles, we focused on making sure that the service was perpetually up-to-date with the rest of the Dice platform. That meant designing the service so that it could “listen” for messages pushed from other platforms and applications, recognize the relevant ones, and react accordingly (such as replicating or deleting data). The service, in turn, would share relevant information with these other parts of the Dice platform.
Avoiding Release and Testing Delays
The new Dice recruiter profile system was built via continuous integration and deployment. In other words, our team worked iteratively on small parts of the service at a time, with each iteration featuring its own dedicated tests. This pipeline helped us release code regularly without too many delays (including the auto-generation of change-request Jira tickets when the pipeline released code to production).
The Final Product is the Tip of The Iceberg
The iceberg analogy is especially apt for a project like the launch of Dice enhanced Recruiter Profiles. The Dice revamped system is designed to build trust, and to give recruiters a way to boost their visibility and promote their latest jobs and news, and the final product gets the job done. That said, it was a project with a lot of moving parts, and the only way it makes it across the finish line in its current form is through strategic planning and execution from the development team at every stage in the process.
