Case study: Job Search at Stack Overflow

Donna Choi
The Startup
Published in
4 min readSep 17, 2020

During my tenure at Stack Overflow, one of my team’s major goals was to increase job applications submitted through our product. We knew that search was the primary path through which people found and applied to jobs, yet we hadn’t invested in improvements in years. I was tasked with researching and designing areas that would improve the job search experience by helping users quickly and easily find jobs that they’d want to apply to.

Current state

Current state for job search

I started by analyzing the current state of job search, digging into usage analytics, and reviewing existing qualitative feedback. I identified a few key problem areas:

Problem #1: Easy-to-use, desirable filter options were either not available or accessible only through advanced syntax search, which saw very low usage and required users to enter complex queries to run even the most basic searches. Based on our existing knowledge of our users, we hypothesized that compensation, benefits, and technologies were the most important filtering options that were currently missing or hard to discover.

Problem #2: Job alerts, which allowed users to get email updates when new jobs matching their search criteria were published, were extremely hard to discover. They were hidden at the bottom of the search results view and available only to logged-in users within certain states of search. As a result, subscriptions were low. We hypothesized that if job alerts were more discoverable and available to more users, subscriptions would increase, followed by the number of job applications.

Problem #3: Keyword search didn’t match common sense user expectations. For example, if a user typed “remote jobs” in the keyword field, search would return jobs that contained an exact match of “remote jobs” in the job title or description, rather than returning jobs tagged with “remote” metadata. We hypothesized that keyword search was the easiest, most direct path for users to search and filter for jobs (easier, still, than a filter UI), so we wanted to ensure that users using keyword search would benefit from the quality of filtered search results.

Design, research, repeat

We conducted multiple rounds of design iteration, user research, and experiments in order to suss out our job search solution. Here were a few things we learned and iterated upon along they way:

  • User research told us that technology and compensation were the most important qualities that users wanted to filter against. However, benefits filters were not as useful as we had hoped, partially because of the lack of quality, specific benefits data that users felt they could trust. As a result, we visually prioritized technology and compensation filters, and visually deprioritized benefits filters.
  • An experiment told us that “job collections”, which were pre-defined, popular job search queries that we surfaced to users at the top of the search results view, did not drive any particular increase in job views or applications. As a result, we scrapped the “job collections” concept and focused on user-directed filters like core search, filtering, and sorting.
  • User research told us that clearing and editing existing search queries had some clumsy interactions, and that it needed to be much simpler to see one’s existing query, add or remove criteria, and clear all criteria.

Following multiple iterations and rounds of research, here’s where we landed:

Job search with filters pane and prominent “Create alert” button

The Search button was rendered redundant thanks to Ajax-driven search results, where results would automatically run if the user took certain actions with their keyboard or mouse. Usability research allowed us to finesse these search result micro-interactions so that users weren’t left confused about the lack of the Search button or frustrated by overly frequent, unexpected search result updates. Additionally, through a series of experiments, we continuously improved keyword search.

In place of the Search button, we added a prominent “Create alert” button, which was now available to everyone (including unregistered users!) in a highly discoverable location. We saw an exponential increase in newly created job alerts and a resulting increase in job applications.

Creating a job alert

We also implemented a rich set of filter options, including technologies, salary, equity, experience level, and benefits filters. The filter pane was further improved by my colleague Paweł Ludwiczak, who made the pane more accessible through keyboard navigation optimizations.

Filter options

Further iterations

Following this release, the team, led by Piper Lawson and Courtny Cotten, continued to improve job search. For example, filter categories became fully exposed on the search result view, rather than obscured behind a filter button. The search button was also brought back, as subsequent feedback taught the team that its absence led to some user confusion.

Reflection

Working on job search was a great learning experience, as was observing my colleagues’ continuous learning and iteration on this feature area. I, like, many users, take high quality search for granted thanks to the high bar set by Google Search. I learned how difficult it is to get search just right and to find the balance between giving users control and making assumptions on their behalf.

Thanks for reading! If you have your own stories about search, I’d love to hear. Please leave a comment or email me at donnachoi30@gmail.com.

--

--

Donna Choi
The Startup

I write about user experience, leadership, and research. Product design @ Google. http://donnachoi.com