Rebuilding the Applicant Experience

The highest volumes of traffic to Fountain’s high-volume hiring platform are driven by workers applying for jobs. Our efforts to provide an accessible, seamless hiring experience recently led to an ambitious redesign of the applicant-facing side of our software. Rewrites are notorious in the software industry and are usually folly: if the current implementation is successfully serving millions of applicants around the world, you would be right to wonder why we would change it.

What could go wrong?

It’s important to acknowledge some of the risks up front. Our team has been growing rapidly, and while we have a lot of great people involved in the project, many of them are relatively new to Fountain. This complicates the planning and execution of a rewrite. Despite the best intentions and capability, it would be easy to miss important but rarely used features or misunderstand the context of an existing tool.

We needed to be able to focus on a subset of features that we could rebuild to be both correct and a delight for applicants to use. A shallow horizontal slice of the existing UI would be frustrating. Instead, we focused on delivering a narrow vertical piece of the existing tools so that we could get it in front of applicants quickly and validate that we were measurably improving their experience.

Motivation

From a product perspective, we wanted to build substantial improvements to make the applicant experience fast, intuitive, and delightful. For example:

Better support for browser autofill
Seamless mobile support
Improved load times for users with slow or limited internet connections

We also wanted to refocus on accessibility to provide opportunities for more people.

The design team also saw an opportunity to upgrade a clunky UI by meeting users where 85% of them were applying—on their phones. They engaged in an applicant diary study and rapidly prototyped some designs with users, working in parallel to create a component library that would enable future maintenance while improving accessibility.

Across product and design, the core metrics for success were the amount of time applicants spend filling out our workflows and the retention rate of applicants moving through workflow stages. Our big bet was that a major overhaul of the experience would help more people find jobs more quickly.

From the engineering side, we decided the best way to deliver on these expectations was to start from scratch. I know, we just said this was a bad idea. However, a few factors pushed us (cautiously) in that direction.

Justifying a rewrite

Code rusts as it sits. The tools used to build it fall out of support, while the pool of developers experienced with those tools and willing to work with them starts to shrink. Maintaining code becomes a burden. This is true of any developer tool chain, but is especially true in the fast-evolving world of front end development.

Much of our front end code has moved to React and Typescript and many of the developers we hire expect to see something of that sort. Our applicant UI, however, was mostly written with jQuery and CoffeeScript—great (or at least begrudgingly necessary) for bridging gaps in the JavaScript of the day, but less necessary when targeting modern browsers. Migrating the applicant UI to React and Typescript allows us to hire from a talent pool already versed in the tools, build systems, and testing frameworks.

While the front end side of the application would be undergoing a rewrite, most of the Ruby code backing it remained the same. We needed to adjust controllers to talk to the new UI, but we avoided touching the core business logic. We instead took the opportunity to add contract tests to these new controllers to tighten our expectations on how they would communicate, supporting future maintenance while avoiding a deep rewrite of the entire product. It’ll be different this time Aside from modernization, Fountain’s current engineering team had several advantages over when the original code was written. This is no fault of the original developers. We have more people, resources, next-generation tools, and the benefit of hindsight. Some highlights:

Translations—Our recruiter-facing UI recently changed to using Smartling for translations. Improving our translations was a big lift from a lot of people at the company and will have its own blog post. Moving the applicant UI to React let us draw on this work as well. The translation workflow from an engineer’s perspective is now much simpler, and the ability to upload context in the application (like screenshots or HTML) has improved the quality of those translations.
Testing—The existing UI had few unit tests. An end-to-end test suite was added but the feedback cycle for a developer was slow and the tests were challenging to write, making it prohibitively expensive for day-to-day development. So far the new UI has nearly 90% test coverage with React Testing Library. That along with TypeScript has dramatically increased our comfort making changes.
Storybook—Providing examples of our components in Storybook helped shorten the feedback loop between developers and designers when implementing new features. We also introduced Chromatic to provide visual diffs of our stories on pull requests. This helped reduce the risk of changes since we could see the fallout in other components in Chromatic.
Design—We had dedicated help from the design team who provided Figmas for the many screens we would be implementing. They were also quick to adapt to feedback from the engineering team during the implementation, which helped keep the project on track. The design team attended demo days both to give the engineers feedback on implementation and to preview what was coming next. They were deeply involved in conversations around improving international accessibility, like how to best handle the many misconceptions around names.
Libraries—For the areas we used the most, browser APIs have stabilized nicely and we needed fewer libraries to be productive. We’ve been more judicious with introducing polyfills and libraries into the new version of the product; before optimizations like code splitting, the bundle size is already down 50%.

Measuring success

Fountain uses Amplitude extensively to track customer interactions in our product. In the application process, identifying workflows that are especially time consuming or cause people to abandon their in-progress applications is crucial. Reducing that drop-off rate and the amount of time required to complete hiring workflows were two of the core metrics for measuring the rewrite’s success

We’re also adopting customer satisfaction (CSAT) ratings as an A/B test to see if people perceive the new version of the applicant workflow to be an improvement. None of this is any help if our users hate it!

QA is your Friend

I would be remiss if I didn’t include a special thanks to our QA team in this post. As we near the initial release, they’ve been invaluable for getting us over the line with confidence. I mentioned earlier that many of those involved on the project have only limited tenure or product knowledge at Fountain, and our QA team has been incredibly helpful in finding edge cases and overlooked features that would have been missed without their careful inspection. They’ve taken the time to provide videos and detailed steps for every issue and have been generous with their time in answering engineers’ questions.

Lessons learned

We started with an ambitious goal: releasing an overhauled applicant experience in three months. As is typical for a rewrite project, we underestimated the breadth and complexity of the existing code during the initial planning phase. We had to adjust our aim in several areas as the project went on.

Measuring success was going to be critical. We had to deliver something as early as possible and let the market decide if we were on a good path so we had room to hit the brakes and shift our investment elsewhere if necessary.
We learned quickly that we weren’t going to be able to deliver a complete-enough product to release to all our customers at once. As a result, we dramatically cut the breadth of the work to get a high-quality vertical slice of the product that we could get in front of customers sooner.
Some features in the original UI have limited adoption or were built for specific customers who have since churned. A rewrite tied to heavy customer messaging is a good opportunity to reassess those features and cut them if possible. The less code we have to maintain now means more room for future work that our customers are asking for.
Developing a design system concurrently with the implementation of a product is challenging. We started with MUI but our design team has been building it into something very much their own. In the early stages, engineering got ahead of design while using MUI. As detailed designs came in, we went back and customized MUI to make it match up. Those customizations proved brittle later. The new design system wasn’t itself at fault, but the divergence from the system led to some miscommunication during hand-offs and rework on previously-completed screens. With the customizations we had done, that rework sometimes led to cascading changes elsewhere and more repairs needed.
The rewrite was used as an opportunity to pilot several new concepts for development at Fountain. We migrated to a monorepo layout for our front end code, introduced contract testing with rswag, and generated our front end API client from OpenAPI documentation. Some of that work took valuable time at the beginning of the project that could have been used for building features. The changes seem well-liked, but in the future we will probably separate it and do that in advance of a large project rather than as a prerequisite to starting the project work.
We didn’t include some libraries that were in common use in the recruiter-facing React application such as Axios and Redux. Removing libraries isn’t always a popular choice and socializing that shift in development technique can be difficult as new teams are brought in to work on the project. We are all working on the same project but our features don’t often overlap. Being heads down on our own work (and remote) doesn’t give us a lot of natural opportunities to explain the changes. We will be continuing to invest in team communication in the future.

Where we go from here

At the time of this writing, we are about to do a soft launch to our first customer. We will be implementing more pieces of the hiring workflow in our new UI and design system, which will allow us to continue to bring more customers into the redesign. At each step, we’ll be listening for feedback and plotting our course. We’re excited to see the impact this will have for applicants on our platform!

Hey, Fountain is hiring! Ready to use your technical know-how to help open opportunities for the global workforce? We’d love to hear from you!

This was originally posted in the Fountain Newsroom