Meet the Gem Interns Building the Future of Recruiting
We spoke with three Gem interns about their experience building production features for a B2B SaaS product
What projects did you work on at Gem and what was the impact on the end user?
Michelle: I worked on blocklisting candidate information in Gem. This allowed prospects to have themselves removed from Gem and stop further outreach from the team that initially reached out to them, or from any team using Gem. This feature was actually a frequent request from recruiters, who wanted to accommodate their prospects’ requests to be removed.
I was incredibly excited to be able to work on this project because of its focus on a clear user need. By implementing this, we prevented companies from contacting prospects without their consent, and we were able to build trust between prospects and companies looking to recruit. Companies building trust with prospects then leads to companies building trust with Gem.
Cole: Building trust in Gem was the core purpose of my project, as well. I rebuilt the infrastructure that syncs user’s recruiting emails to their Applicant Tracking Systems. We wanted to make sure that all relevant recruiting-related emails were synced. Missing an email from a candidate could cause a major headache for a recruiter, as could sending sensitive information to the wrong person.
Achieving more accuracy largely came down to implementing simpler business logic. Having simpler business logic also made it easier for our Customer Success managers to explain to customers why emails were or were not syncing in specific cases, and that itself helped to build more trust in our product.
Branko: I worked on our Chrome extension, which sourcers use alongside LinkedIn to add new prospects to their team’s Gem instance, view past touchpoints with a given prospect, and schedule outreach emails. We started with support for LinkedIn because that’s where most sourcing happens, but we wanted to drive adoption by supporting more types of sourcing. Some sourcers specialize in mapping out social networks or open source codebases, for example.
My goal was to add support for this long tail, which included GitHub, Twitter, Facebook, Workday, and AI-powered recruiting platforms like Hiretual and SeekOut. The ability to easily upload and dup-check candidates across multiple profiles also served to reinforce Gem as a single source of truth needed for all pertinent recruiting information.
What challenge(s) did you run into while delivering the project, and what were your biggest takeaways from the experience?
Michelle: Building blocklisting taught me the importance of testing and navigating stakeholder relationships effectively. There were many ways that a prospect’s information could be re-added to Gem, and I needed to test for all of these. There were also many stakeholders for blocklisting on the engineering and product teams, and interactions between their features and mine. In any codebase, especially in a large one like Gem’s, it is very possible to put out a feature that touches code for a different feature, and for that to have unexpected effects. Testing is crucial to catch these issues before they make it into production.
Talking to stakeholders before building is also critical for success. By communicating the plans and progress for all of my projects, I kept everyone on the team on the same page about what I was doing. Maintaining this transparency helped to prevent design flaws or building out features that wouldn’t actually benefit users. It also meant that if I ever needed help or guidance, folks would already understand the context behind what I’m trying to do.
Branko: I added support for 6 new sites in the Gem chrome extension. For each integration, the goal was to provide seamless interactions with Gem’s searching, uploading, and outreach functionality. Each integration was different and every site had its own caveats, so coming up with a somewhat standardized approach was a fun challenge.
For example, the main interface for SeekOut is a list of prospective candidates, in contrast to LinkedIn where each candidate has a specific profile page, so I had to conceptualize a new workflow to support this multi-candidate view.
I also learned a ton about extension development along the way, and how to effectively code across multiple concurrent chrome processes (i.e. background.js, contentscript.js, and the target sites’ native frame.) The biggest challenge here was managing the transfer of data between these processes securely and efficiently. Finally, there was work to be done on the backend to create new endpoints for these integrations to utilize, so the project offered informative full stack exposure.
Cole: Rebuilding our email syncing system was an exercise in navigating complexity. I learned how to investigate key problems and solve them. This started with scoping the project.
First I talked with Customer Success (CS) to understand the pain points they were having with customers. In essence, complicated business logic made it hard for them to explain to customers what email messages were synced, and there were also noticeable performance issues in the underlying back-end systems.
I brainstormed with CS on what a better business logic might be from their perspective, then talked with engineers who had worked on the system to ask questions, understand the motivations behind the current system, and understand the technical challenges that would be involved in various proposed solutions. I also needed to do my own investigations into existing back-end systems, infrastructure data models, and project logs, before arriving at a solution that fit all of the requirements set by customers, CS, and engineering.
In the end, that solution was to only sync email messages that were in a thread initiated by an outreach message sent by Gem. This led to better email syncing accuracy and was easy to explain to customers. As a bonus, it abstracted from our existing implementation, which was too specific to a single ATS (Greenhouse), and allowed engineering to more easily build implementations with other ATSs.
Addressing email syncing performance issues presented a different set of challenges, and taught me how to improve large scale back end systems that need to be available and performant. I discovered that our existing system was high-latency because it tried to process every single new email message from a user’s mailbox with AWS SQS. This was not scalable as more customers were being onboarded, and a lot more messages needed to be processed.
The solution here was to mark users as “needs updating” in the database and actively call an API to process messages in batches, rather than attempting to process them continuously. This also eliminated race conditions that occurred when multi-workers were used to process the high volume of messages.
Given the technical complexity of this project and the amount of collaboration it required, perhaps the biggest lesson I learned was how important it is to have a supporting environment — everyone at Gem wanted me to succeed and would offer help to me. It was critical to feel connected to the team, and empowered to solve hard problems.
