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.
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.
From a product perspective, we wanted to build substantial improvements to make the applicant experience fast, intuitive, and delightful. For example:
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.
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.
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:
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!
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.
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.
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!