# Glassdoor Engineering The official blog of Glassdoor's engineering team, sharing ideas and learnings found during our mission of helping people everywhere find a job and company they love. - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Improving Embedding-Based Candidate Generation for Recommender Systems with a Two-Tower Model DevFeed: [Improving Embedding-Based Candidate Generation for Recommender Systems with a Two-Tower Model]() Original publisher: [Read original article]() Author: Ahmad Khan Published: 2026-03-18T21:04:58Z Content type: article Language: en Sources: [Glassdoor Engineering]() Topics: [recommendation systems](), [Machine learning](), [Embeddings](), [Neural Network](), [data](), [ordering]() Tags: [ai](), [data](), [embedding](), [machine-learning](), [model-training](), [neural-network](), [ordering](), [ranking](), [recommender-systems](), [self-supervised-learning](), [two-tower-model]() ### AI overview Glassdoor describes a two-tower neural network for candidate generation in its Community feed recommendation system. The model learns user and post embeddings from interaction data to retrieve potentially relevant posts before filtering, ranking, and ordering. ### Source excerpt Overview At Glassdoor (part of Indeed), millions of professionals come to learn about workplaces, ask career questions, and share experiences through our Community platform. When users open the Community Home Feed, they expect to see posts that are relevant to their interests, industry, and career stage. However, generating that feed is not a simple task. At any moment, thousands of new posts across hundreds of community feeds compete for attention. From discussions about interview experiences to workplace culture questions and industry advice, the platform contains a diverse and constantly evolving stream of content. The challenge is to quickly identify which of these posts are most relevant for each user. To address this problem, we built a multi-stage machine learning recommendation system that efficiently sources, filters, and ranks posts before they appear in the user's feed. In a previous post, Inside Glassdoor's Multi-Stage Recommendation System, we described the architecture of this system and how the different stages work together to deliver personalized content. Snapshot of the Glassdoor Community Home Feed At a high level, the system consists of four stages: Candidate Generation -- retrieves a large set of potentially relevant posts Filtering -- removes posts that are undesirable, duplicated, or already seen Ranking -- predicts which posts a user is most likely to engage with Ordering -- applies heuristics to maintain diversity and freshness in the feed Each stage progressively narrows the set of posts until only the most relevant posts remain. 4 Stage ML RecSys Design In this blog post, we focus on the Candidate Generation stage, which is responsible for retrieving an initial pool of potentially relevant posts from a very large pool of posts across many different feeds. For Candidate Generation, we developed a Two-Tower Neural Network Model that learns embeddings for users and posts based on real interaction data. In the rest of this blog post, we will walk ## Inside Glassdoor's Multi-Stage Recommendation System DevFeed: [Inside Glassdoor's Multi-Stage Recommendation System]() Original publisher: [Read original article]() Author: Prateek Shekhar Published: 2025-08-12T19:37:39Z Content type: article Language: en Sources: [Glassdoor Engineering]() Topics: [recommendation systems](), [recommendations](), [personalization](), [Algorithms](), [ordering](), [ann]() Tags: [algorithms](), [ann](), [glassdoor](), [ordering](), [personalization](), [recommendation-system](), [recommendation-systems](), [recommender-systems]() ### AI overview This article gives a high-level overview of Glassdoor's hybrid, multi-stage recommendation system. It describes how the system uses user behavior, similar-user behavior, and item features to produce personalized recommendations for the Community Feed, Email, and Push notifications, with stages including candidate generation, filtering, scoring, and ordering. ### Source excerpt Introduction: Recommendation systems are central to modern digital platforms, delivering personalized content by intelligently analyzing user behavior and preferences through advanced algorithms. Widely used in e-commerce, streaming services, social media, and online learning, they drive user satisfaction, engagement, and retention while supporting business growth. Typically, these systems operate using one or more of the following approaches: Collaborative Filtering: This approach examines user behavior by comparing how users interact with items. It identifies patterns by analyzing similar user actions. For example, if two users have watched or purchased similar items, the system will recommend those same items to other users with similar behavior. Content-Based Filtering: In this approach, the system analyzes the characteristics of the items themselves, such as text, images, or other features. It recommends items that have features similar to those a user has previously liked. For example, if a user enjoyed books with specific keywords, the system will suggest books with those exact keywords. Hybrid Approach: This approach combines collaborative and content-based filtering to enhance personalization and accuracy. It utilizes user behavior patterns in conjunction with item features, offering more personalized and accurate recommendations. At Glassdoor, our Community Feed, Email, and Push notifications are powered by a recommendation system that follows a hybrid approach. It analyzes individual users' behavior, such as posts, comments, and reactions, as well as the behavior of similar users, to deliver tailored, personalized recommendations. This post presents a high-level overview of the multi-stage architecture behind our system, highlighting candidate generation, filtering, scoring, ordering, and supporting infrastructure. Glassdoor's Recommendation System ArchitectureFigure 1: Glassdoor's Recommendation System Architecture Glassdoor's Recommendation System follo ## Data Quality at Petabyte Scale: Building Trust in the Data Lifecycle DevFeed: [Data Quality at Petabyte Scale: Building Trust in the Data Lifecycle]() Original publisher: [Read original article]() Author: Zakariah Siyaji Published: 2025-02-14T15:52:43Z Content type: article Language: en Sources: [Glassdoor Engineering]() Topics: [Data Quality](), [data-engineering](), [data-processing](), [DataOps](), [Usability]() Tags: [data-engineering](), [data-patterns](), [data-platform-engineering](), [data-quality](), [decision-making](), [gable](), [pipeline](), [shift-left](), [software-engineering](), [trust](), [usability]() ### AI overview Glassdoor describes a shift from reactive data engineering to a proactive, trust-centered approach to data quality. The article connects organizational culture with technical checks across the data lifecycle. ### Source excerpt The data Lifecycle with Data Quality Checks at GlassdoorMotivation Glassdoor has transformed from an employee review site to a community for workplace conversations [1]. As our platform evolves to support content creators, facilitate discussions, and offer rich content, it has become more apparent than ever that adopting a data-driven culture is essential. Businesses rely on accurate, high-quality data to understand their operations and assess strategic outcomes. Flawed or incomplete data results in misguided decisions and undermines trust. Recognizing this risk, we made data quality a foundational principle of our data-driven transformation. Although every company defines data quality differently, there is a universal expectation that data used for decision-making must be trustworthy. Additionally, data quality challenges are not solely technical; a psychological component is closely linked to trust in data. Airbnb recognized this and sought to develop a scoring system that acknowledges the belief that data quality is a multivariate issue, encompassing accuracy, reliability, stewardship, and usability, along with more detailed dimensions within each of these categories [2]. On the other hand, Netflix employs a more technically centered approach to quality: data is initially written to a temporary staging area, audited, and then published to the production location upon passing quality checks [3]. Ultimately, Glassdoor drew inspiration from these lessons and aimed to reinforce trust through a cultural shift and a series of technical solutions. This article demonstrates how a proactive, trust-centered approach that connects data producers and consumers establishes a foundation for more rigorous data quality methods, ultimately bolstering a strong company-wide strategy. Figure 1. Enhancing quality guards at the application code layer.Culture Shift: Reactive to Proactive Historically, Glassdoor's data engineering teams have been reactive, learning about issues only aft ## Glassdoor Decreases Latency Overhead and Improves Data Monitoring with WhyLabs DevFeed: [Glassdoor Decreases Latency Overhead and Improves Data Monitoring with WhyLabs]() Original publisher: [Read original article]() Author: Lanqi Fei Published: 2023-09-06T21:57:52Z Content type: article Language: en Sources: [Glassdoor Engineering]() Topics: [Latency](), [Logging](), [Monitoring](), [Library](), [async](), [Open Source](), [Graphs]() Tags: [architecture](), [async](), [complexity](), [graph](), [latency](), [latency-optimization](), [library](), [logging](), [model-monitoring](), [monitoring](), [open-source]() ### AI overview This article examines how Glassdoor and WhyLabs addressed latency when integrating data monitoring into a real-time service. It describes changes to whylogs, an open-source data logging library, and compares architectural options including asynchronous calls, DAG-based restructuring, and keeping work in a linear execution path. ### Source excerpt Authors: Lanqi Fei, Jamie, Natalia This blog was written by Lanqi Fei, Senior ML Scientist at Glassdoor, Jamie Broomall, Senior Software Engineer at WhyLabs, and Natalia Skaczkowska-Drabczyk, Customer Success Data Scientist at WhyLabs. The challenge of integration latency Consider the scenario where we want to integrate a new tool into an existing service that potentially operates in real-time and involves some user interface. We need to make sure that the latency of the service in production is acceptable after the integration, while still keeping the overall maintenance costs low. In this scenario, there are trade-offs to be made and the right choice will depend on the individual characteristics of the service and the newly integrated function. Simplifying this function is a common path to gaining a significant advantage in this optimization game. This blog, written in collaboration between Glassdoor and WhyLabs, describes a real-world instance of an integration latency challenge and gives a detailed walk-through of the changes applied within whylogs (an open-source data logging library maintained by WhyLabs) to mitigate it. What are the best options for reducing latency? There are a couple of options for reducing latency when integrating a new function into an existing service. Restructuring your service or architecture to allow an early response to the caller before doing the additional work (this may be as simple as using an async call pattern with a log statement or as complex as a DAG framework). You can think of your service as a graph -- its nodes should be the latency-critical tasks and ideally those should be executed, instrumented and tested independently. Using a DAG can be a good way of scaling out a service to a large number of new features and integrations while maintaining latency requirements and managing the complexity of the critical path to generating a high quality user response. The downside of this approach is the additional complexity as well ## Introducing Glassdoor's ML Registry: A Centralized Artifact Management Solution DevFeed: [Introducing Glassdoor's ML Registry: A Centralized Artifact Management Solution]() Original publisher: [Read original article]() Author: Rich Papalia Published: 2023-08-30T21:20:29Z Content type: article Language: en Sources: [Glassdoor Engineering]() Topics: [Machine Learning & Artificial Intelligence](), [Open Source](), [Development](), [Amazon SageMaker AI]() Tags: [aws](), [configuration-management](), [feature-store](), [lifecycle](), [machine-learning](), [machine-learning-platform](), [open-source](), [pipelines](), [registry]() ### AI overview Glassdoor describes its newly open-sourced ML Registry, a centralized service for managing machine-learning artifacts and related metadata. The registry is intended to provide a single source of truth and consistent access across teams and applications, integrating with other tools and services. ### Source excerpt Photo by Ryunosuke Kikuno on UnsplashGlassdoor's Machine Learning Engineering and Platform Team As part of Glassdoor's journey to becoming an ML-driven company, we've created an exceptional Machine Learning Engineering and Platform team, (see our blog about building this team here) dedicated to developing the foundational infrastructure for all of our ML initiatives. We've strategically built our ML platform by utilizing a combination of buying, building, and adopting from existing open-source solutions. This approach has allowed us to leverage the best of all worlds. Our team has had the opportunity to build numerous tools from scratch, including data pipelines, human-in-the-loop tools, and more. We've also built on top of existing tools like AWS Sagemaker to incorporate powerful in-house customizations into our feature store. We have more exciting plans in flight, such as building a new recommendations platform, further open-source contributions from our platform, and continuing to build on the foundation which we've established. Today, we'll delve into our newly open-sourced ML Registry. What is an ML Registry? The ML lifecycle encompasses far more than just model development. Once a model is built, many questions arise: Where does it reside? How do we access it? What if updates or versioning are needed? Where can we store the metadata describing the model? And what about other non-model artifacts? How can we efficiently manage all of this? Enter the ML Registry. Glassdoor's ML Registry is a centralized management service for ML artifacts and all related metadata. It serves as the single source of truth for all data pertaining to ML, enabling uniform and reliable access to this data across diverse teams and applications. It seamlessly integrates with other tools and services and provides robust, feature-rich functionality. Choosing Between Buying and Building, What Differentiates Our ML Registry? While several paid and open-source model registries already exist, ## Building Glassdoor's Machine Learning Platform and Engineering Team DevFeed: [Building Glassdoor's Machine Learning Platform and Engineering Team]() Original publisher: [Read original article]() Author: Malathi Sankar Published: 2022-08-01T07:19:34Z Content type: article Language: en Sources: [Glassdoor Engineering]() Topics: [MLOps](), [Machine Learning & Artificial Intelligence](), [Data Infrastructure](), [DevOps](), [Monitoring](), [airflow](), [debug](), [Provisioning]() Tags: [airflow](), [data](), [data-infrastructure](), [debugging](), [devops](), [engineering](), [glassdoor](), [infrastructure](), [machine-learning](), [machine-learning-platform](), [ml-engineering](), [mlops](), [monitoring](), [organization]() ### AI overview This article describes how Glassdoor developed and scaled its machine learning platform and engineering team. It covers the organization's early machine learning systems, deployment and infrastructure challenges, adoption of MLOps practices, and the use of combined open-source, commercial, and proprietary tools to orchestrate its machine learning pipeline. ### Source excerpt In this post, I would like to share how Glassdoor built and scaled its ML platform and engineering team and what we learned along the way. Historic ML journey at Glassdoor Ten years ago, machine learning at Glassdoor started with a straightforward logistic regression model, which was used to power our job recommendations. Today machine learning is ubiquitous. It is used across most of our products -- search, ads, reviews, salaries, interviews, benefits, and Fishbowl post recommendations, to name a few. Data quality, model innovations, hardware advancements, data infrastructure, resource investments, and tools propelled this growth. Until 2021, our machine learning team was mostly comprised of scientists who were experts in math and statistics. They worked with data engineers to prepare data and build optimized models to solve problems. Batch deployments were done in Airflow by the scientists, while project engineers carried out the online model deployments. Infrastructure provisioning was left to the DevOps team. This organizational structure was less than ideal, however, and created many challenges. Communication gaps and resource misallocations made deployments tedious and time-consuming. Monitoring, observing, maintaining, and debugging models were difficult. Machine Learning's technical debt grew rapidly and had a negative impact on Glassdoor's operations. Adoption of MLOps framework: To deal with the above challenges, we conceptualized real-time machine learning as primarily an engineering and infrastructure problem. As Scully et al. have discussed in this paper [1], only a small fraction of a real-world ML system is composed of ML code (illustrated by the black box in Figure 1), while the surrounding infrastructure is vast and complex. By adopting a set of DevOps and Engineering best practices known as MLOps, we were able to effectively manage this complexity. As previously discussed in our blog, our initial approach comprised a mix of open source tools, commer ## Personalized Fishbowl Recommendations with Learned Embeddings: Part 2 DevFeed: [Personalized Fishbowl Recommendations with Learned Embeddings: Part 2]() Original publisher: [Read original article]() Author: Ahmad Khan Published: 2022-04-05T00:24:03Z Content type: article Language: en Sources: [Glassdoor Engineering]() Topics: [recommendation systems](), [Embeddings](), [Natural language processing](), [datasets]() Tags: [deep-learning](), [doc2vec](), [embeddings](), [model](), [nlp](), [personalization](), [quality](), [ranking](), [recommendations](), [recommender-systems](), [research](), [word-embeddings]() ### AI overview This engineering article explains how Fishbowl recommendations can use learned embeddings. It describes Doc2Vec-based post and user embeddings, collaborative signals from users with similar likes, cosine-similarity ranking, and additional personalization features such as employer, job title, work city, and feed information. It also introduces transfer learning for text content embeddings. ### Source excerpt Introduction In the previous blog post, we saw how we can utilize text based embeddings to help recommend posts to users on Fishbowl, a professional networking community that was recently acquired by Glassdoor, in which working professionals can have workplace related conversations with other peers in industry. On Fishbowl, users can anonymously write what's on their mind in posts and also comment on posts from other anonymous users in what we call "bowls" or "feeds"; a collection of posts related to a certain industry or topic. Previously we discussed how in the absence of clear negative signals from click stream data we cannot as easily use a supervised learning setup to rank items to users. Given the inputs we used were text based, we can instead use more unsupervised methods like Doc2Vec [1] to generate post text embeddings. We can treat the text of the posts as individual documents and use those to train a Doc2Vec model to generate a post text embedding. For users, we can take the average post text embedding of the posts the user liked and consider that as the user embedding. We can also add the user embeddings of other users who liked a post into our post embedding calculation so we incorporate some "collaborative" notion of what other similar users liked as opposed to a pure content similarity ranking. We can next compute the cosine similarity between the user and posts embeddings and use the similarity score to rank posts to recommend to users. Ranking via Embeddings Overview However, such an approach can have some shortcomings. First the text of the post is just one of many features we can use for personalization. We can also leverage other user provided information when users agree to sign up like the employer, job title, work city of a user as features. In addition, the bowl or feed name and its description can be considered important features for posts as posts under the same feed tend to be about similar topics. Second, the previous Doc2Vec approach tra ## ML Prediction Pipeline Orchestration with ML Control Center DevFeed: [ML Prediction Pipeline Orchestration with ML Control Center]() Original publisher: [Read original article]() Author: Vance Thornton Published: 2022-04-01T23:32:32Z Content type: article Language: en Sources: [Glassdoor Engineering]() Topics: [MLOps](), [Machine learning](), [YAML](), [data-processing](), [GitOps](), [model-deployment](), [Open Source](), [Library](), [real-time]() Tags: [data-pipeline](), [data-processing](), [gitops](), [library](), [low-latency](), [machine-learning](), [ml](), [mlops](), [mlops-platform](), [models](), [open-source](), [orchestration](), [pipeline](), [real-time](), [yaml]() ### AI overview This article describes Glassdoor's ML Control Center, an MLOps project for connecting machine learning components and orchestrating prediction pipelines. Pipelines are defined with YAML configuration, support reusable and custom components, and can run for online, near-real-time, offline batch, or automated testing use cases. ### Source excerpt A YAML based approach for building data processing pipelinesIntroduction In a previous blog post we described Glassdoor's a la carte approach to MLOps. We chose this approach because the MLOps landscape is rapidly evolving and we want to have the flexibility to use the best available options. ML Control Center (MLCC) is a project that we are developing at Glassdoor which will act as the glue to connect and unify these disparate components. Our plan is to move to a GitOps oriented approach where YAML configuration files in our Git repositories control the deployment and execution of all the tasks and services needed for our ML projects. One part of this is support for ML prediction pipelines which we recently released as an open source project at: https://gitlab.com/glassdoor-open-source/ml-control-center. A ML prediction pipeline typically involves gathering feature data from various sources, providing the data to feature extractors and/or ML models for prediction, and then writing the output to a data store. In MLCC these pipelines are defined using YAML files which specify the configuration of the operations to perform and the flow of data input/output of those operations. One of our primary design goals is to make it easy to implement the most common use cases quickly with simple YAML configuration and minimal coding. We want to allow ML scientists and engineers to focus on defining what they want the pipeline to do with many of the engineering implementation details such as parallelization, metrics, and retry logic taken care of automatically. MLCC has a library of reusable components which provide the functionality that is typically needed for our use cases and it is easy to add custom components when needed. This approach promotes flexibility and reuse by encouraging a modular implementation. Another trend that we have seen at Glassdoor is that online and near real time ML processing is becoming more common. The design of MLCC prediction pipelines makes them w ## MLOps in Glassdoor: an à la carte approach DevFeed: [MLOps in Glassdoor: an à la carte approach]() Original publisher: [Read original article]() Author: Zixin Wu Published: 2022-01-12T00:42:43Z Content type: article Language: en Sources: [Glassdoor Engineering]() Topics: [MLOps](), [Machine learning](), [data](), [Software Engineering]() Tags: [airflow](), [data](), [devops](), [machine-learning](), [mlflow](), [mlops](), [model-training](), [monitoring](), [offline](), [orchestration](), [software-engineering]() ### AI overview The article introduces Glassdoor's MLOps approach, explaining how machine-learning systems differ from traditional software because they depend on changing data, model training, data-centric evaluation, version tracking, and monitoring. It presents MLOps as the application of DevOps practices to ML systems through automation and monitoring. ### Source excerpt Authors: Zixin Wu, Srinivasan Ramaraju Introduction Data Science and Machine Learning (ML) have become an essential toolkit for businesses to increase their competitiveness and provide greater value to their customers in recent years, largely thanks to the abundantly available large data sets, more cost-effective computation resources, and advancements in ML algorithms. In Glassdoor, we utilize ML to build intelligent products which help our job seekers find the jobs and companies they love. While ML can unlock new capabilities for businesses, it comes with its complexity and challenges compared to traditional software engineering, mainly due to data dependency and team skillset shift. Data dependency: a major reason for using ML approaches to build complex software is exactly because the desired behavior of the software is so complex that it's more efficient to be driven by data. This dependency brings new components in the software development process: Instead of simply compiling source codes, now the software (ML models) needs to be trained/retrained by (usually a large amount of) data before it can be used to serve clients Evaluation and test of ML model behaviors is data-centric and often involves offline experimentation Version tracking of ML models needs to consider both code and data changes The data could change over time due to various reasons, such as the way the data is collected or processed, or customer behavior changes which, in turn, could be driven by the effect of using the ML model. This essentially creates a hidden feedback loop. All these changes in data need to be monitored and acted accordingly. Team skillset: in many companies, the majority of the ML team members are data scientists or ML researchers, specialized in dealing with data and ML algorithms. However, to integrate an ML solution to existing systems and continuously operate it in production, many more components are needed besides ML model training and evaluation. Automating and stan ## Personalized Fishbowl Recommendations with Learned Embeddings: Part 1 DevFeed: [Personalized Fishbowl Recommendations with Learned Embeddings: Part 1]() Original publisher: [Read original article]() Author: Ahmad Khan Published: 2022-01-07T21:48:24Z Content type: article Language: en Sources: [Glassdoor Engineering]() Topics: [recommendation systems](), [personalization](), [Machine learning](), [Embeddings]() Tags: [doc2vec](), [embeddings](), [fishbowl](), [glassdoor](), [machine-learning](), [personalization](), [recommendation-system](), [recommendations](), [word-embeddings]() ### AI overview Glassdoor's Fishbowl team describes the recommendation problem created by a growing volume of posts and explains the move from recency and global-popularity rankings toward personalized recommendations using machine learning and learned embeddings. ### Source excerpt Glassdoor recently acquired Fishbowl, a professional networking community where working professionals can have workplace related conversations with other peers in the industry. Fishbowl users can anonymously write posts and see posts from other anonymous users in what we call "bowls": a collection of posts related to a certain workplace, industry or topic. Bowls can be an effective way to gain insights into workplace topics and conversations. The anonymous nature of the app can further encourage honest and frank discussion on topics users may otherwise feel uncomfortable discussing. Users can subscribe to different bowls and then see new posts from their subscribed bowls show up in their main home feed when they open the app. Every day Fishbowl users post thousands of new posts. With a growing and increasingly active user base that number will keep increasing. Surfacing the most interesting content to users can therefore become increasingly challenging with scale and a lack of personalization can detract from the overall user experience. Given the large number of possible posts to recommend and the small number of posts that can be surfaced to the user in app at any time, we have a typical recommendation system problem. From Global Rankings to Personalized Recommendations To personalize the posts recommended to a user we decided to use Machine Learning shortly after Glassdoor's acquisition. Prior to this Fishbowl just used the recency and global popularity of a post to sort what to show users in app. At the time of starting the project we also did not collect any explicit user click data that could have defined our problem into a classic supervised learning problem (e.g: predicting the probability of a user clicking a post given they saw the post). While we collected data on what posts a user anonymously liked or commented on we did not collect good data on if they saw or clicked a post at the time. Why is this important? If training a supervised model, we can use s