Abhik Pramanik

Culture

Kyra ran our first holiday book exchange, and it's been a hit with the team (to the point people mentioned it in our 1:1s). I added some photos from our recent meetups.


Ben added some improvements to our Slack guidelines. Sylvie added a way for us to learn more about each other in our weekly standup. We've been using both for over a month, and the team has been enjoying the changes!


How we use efficient and deliberate communication at Ashby to keep Slack notifications and meetings to a minimum, focus 36h out of a 40h week, and have fun along the way 😀.


How Thoughtful Communication Makes Us Unreasonably Productive

aronow.io

Astronomer

Attentive

Aven

Benchling

Boulevard

Brightline

Brigit

Calm

Census

Clever

CloudTrucks

Coder is a remote infrastructure development platform that makes working with code easier than ever. Coder enables everyone from industry rookies to experts to develop code faster than ever before, using templatized starting points and ultra-secure workspaces.

Coder

Cohere

Cointracker

Color

Costanoa Ventures

Decimal

Deel is payroll for modern business. No matter where you're hiring, Deel helps customers run payroll, supporting 150+ countries with hundreds of worldwide experts. Deel helps their customers know that hiring, paying, and managing stayed compliant and easy in their all-in-one platform.

Deel

Deepnote

Deliveroo

Dune

Duolingo

EightSleep is more than a mattress company - it's a suite of products devoted to sleep fitness. Their goal is to make sure that your sleep is as high-performing as you are, helping you meet and exceed the bar for excellence in your waking life. Athletes and scientists alike love their range of highly customizable sleep tech because it helps them live healthier.

EightSleep

Figma

Format One

FullStory

Juni

Linear

Marqeta is a modern card issuing platform dedicated to empowering innovators to launch their products to the world. They have over a decade of experience as a trusted, high-tech solution for builders who need simple, scalable payment solutions.

Marqeta

Modern Treasury

Monte Carlo is a Series D data observability company helping its customers accelerate the adoption of data to eliminate downtime. 

Monte Carlo

Notion

Opendoor

Plato

PostHog

PostHog is an open source analytics platform. Their product is used by product, engineering, and marketing teams to understand user behavior, including product analytics, session recording, user paths, a/b testing, heatmaps, and more. The suite, founded through Y Combinator in 2020, has since been installed by over 10,000 companies.

Pragma Platform

Pulley

Ramp

Readme

Replit

Scratchpad

Sift

Snyk

Sourcegraph

Stytch

Talentful

Treasury Prime

VanMoof is a Dutch e-bike company creating stylish, feature-rich city bikes. They're the fastest growing bike company in the world, with an active community in over 50 cities worldwide.

VanMoof

Veev

Verkada

WeTransfer

Zippin

Engineering

Recruiting

Product

Benjamin Encz

Ashby has partnered with [MeVitae](https://www.mevitae.com/) - a tool that helps you mitigate biases in your recruiting process.

Biases are hardwired into the human brain, but they can frequently be harmful. Technology like MeVitae is a great way to circumvent biases in hiring, helping improve the diversity of your hiring pipeline by over 30%.

![screenshot of MeVitae within Ashby](/images/mevitae-screenshot.png)

This integration automatically redacts candidate details viewed from within Ashby, blinding your applicant pool for your recruiters in no time at all.

To learn more, visit [MeVitae’s help center](https://www.mevitae.com/ashby-helpcentre).


Ashby is partnering with MeVitae to help you decrease recruiting bias. 

Ashby Has Partnered with MeVitae

Halden Ingwersen

Should you cook dinner or order out? Should you buy a turn-key house, or have one designed for you? Should you buy a ready-made software or build the system in-house?  
  
Both building and buying can have benefits and downsides, and it can be hard to know what the right choice is for you and your business. If you’re considering building a reporting solution for your talent and recruiting team, you probably have a lot of questions. What will it look like? Who will have access and will they be able to update the reports themselves? Does every team member get the same reports, or can you customize results depending on the function? _Who_ will build the reports, and _how_ will they get built? Can you change a dashboard after it’s been made? How often does the data update? Do you get reports for sourcing activity? How about coordinator scheduling activity?  
  
This is a two-part series, and this article centers on building. We’ll answer the questions above, as well as go over a few key areas like:  

-   The elements of a standard data reporting solution
-   The the cost of a reporting solution
-   The biggest benefits that come from an in-house build
-   Potential complications and downsides to building your reporting software

Though we’re using Ashby Analytics as our primary example, the information in this article is just as relevant to other products. Of course we’re Ashby Analytics fans, but we’re examining the “build vs buy” decision as a whole. You might be just as interested in comparing [Looker](https://www.looker.com/) or [tableau](https://www.tableau.com/) to building an in-house tool.
  
Let’s begin by breaking down the upsides, complications, and costs of an in-house building solution.  

## The traditional data team solution

When you’re looking at improving how data-driven your business is, your first stop is often to build out your data team. Here, you have two immediate choices: do you have a [**centralized data team** or an **embedded data team**](https://medium.com/@mikldd/data-team-structure-embedded-or-centralised-f179aa231108)?  
  
The **centralized** **data team** tends to take on a service model, where a core team of data engineers and analysts maintain both the data infrastructure and data analysis requests that are fielded in an approach similar to support tickets. The core data team is often responsible for standardizing corporate metrics as well as maintaining systems that make analysis results and reports available across the organization’s various teams.  
  
Although some very large organizations maintain and operate under a centralized data team model, after a certain size (typically at least four or five team members) some organizations opt for an **embedded analyst model**. In the embedded approach, each analyst will work within a given product area or function (e.g. the marketing analyst, the core product analyst, etc.)  
  
If your organization is large enough to have a data team, one of these approaches may sound familiar. Which one works for your company will differ, and doesn’t always impact the build or buy decision. But regardless, **neither tends to serve the recruiting function well**. The centralized data team model by its nature (and to its critique) is request-based and results in only periodic, intermittent reports delivered. And even for large organizations that can afford many embedded data analysts, it’s rare that one is dedicated to the recruiting team exclusively.  
  
In the rare and fortunate case that your recruiting team has a dedicated analyst, that’s great! It makes building an in-house recruiting analysis system a much more feasible and attractive option. At this point, you’ll need to make decisions about the analysis tooling and infrastructure itself, which brings us to our next topic.  

## Breaking down cost

The elements of building out an analytics tool is completely inextricable from the cost. Every element that goes into the design, construction, and upkeep of a large, complicated internal application adds to the cost. We’ve broken down what you’ll need to account for by stage, so start here, then jump to the stage that _best_ describes your business_._  
  
Which data maturity stage is your organization in? Here’s a rough guide to check against:  

-   **Early stage (~seed to series A startup):** No central data warehouse, no standardized reporting infrastructure or tooling, reports are done in a one-off basis, reports are hard to share broadly and require a lot of custom rework if the results are to be updated
-   **Beginning stage (~series A to B):** Central data warehouse and standard data sources are integrated across business and product systems, typically one data engineer and at least one data analyst, a standard reporting tool used to regulate and share common reports
-   **Established stage (~series C and beyond):** Your data team has a manager, two data engineers, and a number of analysts such that most corporate functions are covered through a service or embedded model, standard metrics and regular reporting are mostly standardized, your product is mature and growing with a majority of analysis efforts spent on optimization and new feature development

Got your stage? Then let’s break down what you’ll need to build out effectively.  

### Early stage considerations

If you’re at the early stage you’ll be facing the challenging of starting from scratch. These foundational efforts will be tied to the time scale of hiring your first data expert, but it will also bring up a number of technology decisions. At the very least, you’ll likely be faced with the following steps:  

-   **Hiring your first data domain expert** - Founding hire; [salary may range between $66k - $200k](https://www.glassdoor.com/Career/data-analyst-career_KO0,12.htm)
-   **Purchasing a data warehouse** - For data storage; may range from $10k - $90k yearly
-   **Purchasing data integration technology** - To continuously sync and maintain data records across business and product systems; may range from $2k - $90k yearly
-   **Purchasing your reporting infrastructure** - There are open source options here which come with the cost of building and maintaining; off-the-shelf reporting solutions may range from $50k - $100k yearly

In addition to the starting costs, there is still the time cost of establishing each of these components  

### Beginning stage considerations

At this point you likely have the foundations of data team and reporting in place. The question at hand typically becomes _where is the data team’s time and effort applied?_ As mentioned above, small data teams have to operate on a request basis, as they are not large enough to pursue an embedded analyst model. At this point it is likely that some departments or specific challenges receive solutions, while others are left unattended.  
  
The questions most pertinent at this stage are:  

-   Can your recruiting team get dedicated attention from the data team?
-   Do you have reporting infrastructure built? If so, does your team have access to it, to ensure everyone is looking at the same results and metrics?
-   Is your ATS data integrated into your data warehouse and has it been modeled by analysts already?
-   How urgent are your reporting needs? Do you need results next week, or is a month or longer acceptable?

It’s common at this stage to see a company investing the data team resources into a backlog of corporate and product reporting. It’s also normal to see bandwidth divided between multiple areas, such as product usage and engagement across your customer base, marketing efforts, sales and success planning.  
  
You’ll want to make a sober assessment of your recruiting analytics needs relative to the demand the data team is under to assess whether you’ll get the assistance you need at the cadence you need it. While it’s normal to see a queue forming, that doesn’t mean the queue is unavoidable or that it’s the best option.  

### Established stage considerations

If you’re at a large organization with a well-established data team there is more of an opportunity for talent and recruiting teams to get dedicated analysts. At this point, it becomes an internal conversation about setting bandwidth and budget. Many of the beginning stage considerations above do still persist, and implementation still takes time, but an enterprise-level business may have more ability to address the costs and complications.  
  
At the established stage, the scale and importance of a reliable solution becomes more evident. In the absence of standard-built solutions, teams have likely learned to live on their own, using partial solutions and spreadsheets. Though the point solutions may exist for various needs, the ability to train new team members or perform broader analysis across teams veers towards the impossible.
  
At this scale, the important thing is finding a strong solution quickly, be it built or bought, as the time and energy atrophy of these ad hoc solutions can create some serious havoc in the talent acquisition process.

### “Hidden” cost

There’s a baseline cost to any data solution that comes from hiring a data professional and investing in the infrastructure technologies they require to do their job. Those initial investments really are just the beginning of a data solution.  

>> Businesses of all sizes should keep an eye out for different pricing structures when comparing in-house vs. purchased options. For instance, [Looker charges a $5k/month fee](https://www.techrepublic.com/article/looker-vs-tableau/) that may be inaccessible to a small business, while [tableau's $70/user/month](https://www.techrepublic.com/article/looker-vs-tableau/) rate may be unfriendly for large companies. When crunching the cost of a potential build, make sure you're running an accurate comparison!
  
Here are some common additional in-house build costs to consider:  

-   **What is the time to your solution?** This is an opportunity cost. Some Ashby customers have reported taking more than six months to get a reliable reporting system established prior to making the switch to Ashby.
-   **What is the cost of ongoing knowledge transfer?** Recruiting is a complex business, and you need to ensure that your data analyst understands it. Many teams find one of the primary time delays is having to explain the recruiting business and operations to non-recruiter analysis.
-   **Is your solution resilient?** Recruiting is a dynamic field where the strategies and tactics often change. One of the most common outcomes we’ve seen is a business intelligence-based solution that’s _brittle_: it reports useful metrics but doesn’t afford slight modifications that are required to drive further insight. Further insight demands additional requests and more time from your data team.
-   **Are you able to self-serve your own reporting needs?** Many recruiting teams are handed reports they’re unable to adjust as needed. This relates to the brittle BI solution above, but it’s important to address whether you have the autonomy to drive your own reporting needs, not just adjust pre-existing reports.

You may already be familiar with some of these situations. In any in-house software build out, hidden costs are completely normal, and are really only a big problem when they take you by surprise.  

## What you get for the price

In-house software is expensive, but what else is it? There are several benefits to building an in-house solution.  

-   **Project control:** Building in-house means that your business is in control of every single aspect of the solution. You get the final say on where to focus resources, who is managing the data, what’s done with the data, and what the user interface ends up being. This might be a requirement for businesses with extremely high security or privacy demands.
-   **Pivot:** Due to that level of control, you’ll be able to pivot your methodology as quickly as the data itself will allow. The learning curve is built along side the system itself.
-   **Specificity:** Having your own personal analysis system means you can get heavily granular with your information, data, and reporting in a way a purchased ready-made solution often isn’t. If there’s something especially specific that you need to dig into, that’s unique to your business’s recruiting, this alone may make it worth it.
-   **Long-term cost:** If you already have a robust data integration tool, warehouse, and data experts on staff, it may be worth the time cost to see the long-term savings an in-house built system will offer you.

## Recruiting analytics-specific complications

If you’ve made it this far, you might be wondering why typical data solutions seem to fail to address recruiting analytics needs.  That’s a good question, and the short answer is that *recruiting analytics done well is a difficult data problem*. But there’s more to it than that simple statement.  
  
**The underlying data is dynamic in ways that reflect the real world.** Unlike, say, a product analytics environment where engagement measures are well defined, recruiting touches the real world. Interviews are created, cancelled, rescheduled, canceled again, and rescheduled. Then one of the three interviewers doesn’t show up, and only one of the two submits feedback. The candidate takes a vacation, so you get back to them at a later date, and when they come back they want to apply for a different job so you transfer them. A different hiring manager takes over, your in-house recruiter goes on leave, so a different recruiter gets involved. This is a very real portrayal of the paper trail of data that gets created in the recruiting environment. Answering a simple question like _"How many people did recruiter X hire?"_ gets complicated pretty quickly.  
  
**Recruiting data is prone to quality issues and requires a lot of data modeling and filtering.** It’s always necessary to clean and prepare data. Recruiting data and the complexities of the real world are _particularly_ prone to quality issues. This is where powerful filtering, data exploration, and underlying data modeling comes in. Building this in-house takes a lot of domain familiarity, and maintaining the system as recruiting efforts evolve is far from trivial. New sources, agencies, team members and recruiting efforts all act to continuously complicate the reporting landscape.  
  
**The scope of analysis focuses on the individual all the way up to broad, long-term trends.** Recruiters need to pay attention to the details, know where individual candidates are, and get timely alerts and reports for day-to-day operations. Managers like to see weekly summaries, while executives need to see broader aggregates and be able to drill down into the details. There are variety of stakeholders, each of whom have separate requests. This isn’t hard per se, but it is a lot of work!  This is where the amount of time to stand up a recruiting analytics solution and ongoing maintenance costs factor in.  
  
**Self-serving reporting is critical to maintaining recruiting velocity.** Some of the most critical metrics in reporting relate to time: time to fill a position, time in process, and time to hire. When a recruiter needs to make an external request they’re almost certainly looking at additional days of delay. Those days add up and hiring efforts slow down in aggregate, which trickles down to your organizations progress against the hiring plan. Self-service is a mission critical aspect of any recruiting analytics solution. The requisite filtering, grouping and customization needs to be readily available to the end user: a recruiting team member, not a data analyst. This is a hard data design problem, and the standard BI dashboard with fixed reports does not meet recruiting team needs.  
  
Recruiting analytics are simply different from other types of data analysis. This alone complicates recruiting data system significantly. While building in-house isn’t impossible, and may remain the right choice for your business, it’s uniquely difficult in a way that other in-house systems are not.  

## The bottom line

Building an in-house data analytic system for recruiting is a massive undertaking. Once you pull it off, it can offer a lot of additional control, precision, and specificity that many bought solutions can’t match. However, it’s time-consuming, expensive, and may prioritize what stakeholders _think_ they need over what they _actually_  need.  
  
Building in-house is most likely right for you if:  

-   The type of work your business does and the type of recruiting you undertake is exceptionally specific
-   Intense recruiting data privacy is a must in your field
-   You’re at an enterprise level or are established enough that building more data systems isn’t a large additional cost or lift
-   You’re willing to wait longer and spend more money to create something completely unique to your business

Even if this sounds like you, building still isn’t your only choice. Join us in part two of our article to learn more about the pros and cons of buying recruiting analytics tools.

Choosing to build an in-house recruiting analytics tool or purchase an out-of-the-box solution is a major business decision. In the first half of a two-part series, we've weighed the pros and cons of each to help you make the best choice for you.

Hiring Analytics Tools - Is Building or Buying the Best Choice for You?

Ashby has partnered with [CodeScreen](https://www.codescreen.com/)! CodeScreen is a testing platform that allows you to create unique assessments for potential engineers. Design your own assessments, or select one from CodeScreen’s library to get a sense of your candidates’ coding skills.

![a codescreen assessment in ashby](/images/codescreen-in-ashby.png)

With this integration, you’ll be able to send CodeScreen assessments and see the results without leaving your Ashby app, saving you time and clicks.

Check out [CodeScreen’s documentation](https://docs.codescreen.com/#/integrating-ashby-with-codescreen) or visit [Ashby University](https://www.notion.so/Setting-Up-Assessment-Integrations-7d393af4eb0e4259af97425411495e79) to learn more.


Ashby and CodeScreen have teamed up to make engineering assessments easy. Learn more here!

Ashby Has Partnered with CodeScreen

If you want to know who is applying to work at your company, or if you’d like to cultivate a more diverse and inclusive workforce, you’ll want to track demographic data. In order to start tracking that data, you need to ask some questions first. That’s where a lot of people hesitate; how can you know that you’re asking the right things in the right ways to get the information you want while being as inclusive as possible?  
  
If that sounds familiar, this guide will help you figure out what to ask and why, to take the stress out of designing diversity surveys for your candidates.  
  
Note that, for this article, we’re focusing on candidate and hiring diversity surveys, rather than surveys for current employees, which is a topic for another day. We’ll be focusing on candidate diversity surveys. We’ll cover reasons to track candidate diversity, the best things to ask (and how to ask them), and briefly touch on how to track your results.  
  
If you want to be better about tracking diversity information, but don’t know what to ask, this article is for you.  

## Why to track candidate diversity

An inclusive, equitable, and diverse workplace starts well before an employee signs on. It starts as far back as how hiring is approached and thought of by those in leadership. It moves into how you write job descriptions and where you share them. By the time someone applies you already have a lot of moving pieces that impact how that person is likely to identify.  
  
Tracking diversity at the hiring stage can tell you who is applying to work at your company and where your organization is falling short of market representation, as well as revealing the stages of hiring that help or hurt your diversity goals.  
  
If you want to make your company into a richly diverse place to work, tracking DEI data is the most informative place to begin.  

![an example of an EEOC survey](/images/ashby-eeoc.png)
  
You may already be using [Equal Employment Opportunity Commission]([https://eeocdata.org/](https://eeocdata.org/)) or EEOC data, either because you’re required to or because it’s a good base from which to start tracking candidate diversity data. And it _is_ a good base! But the EEOC survey set up can present as non-inclusive to applicants. Additionally, you may want more detail, or to track an element of identity that the EEOC questions don’t cover.  

## What not to ask

The knowledge that there are questions you simply cannot ask a candidate may hold you back from running a diversity survey. Asking questions that could lead to discrimination is illegal in an interview. However, surveying for inclusiveness is critical to building a diverse workplace, and even required in some cases. Following the [The Uniform Guidelines on Employee Selection Procedures](https://www.shrm.org/resourcesandtools/hr-topics/talent-acquisition/pages/clearing-up-misconceptions-uniform-guidelines-employee-selection-procedures.aspx) is a good way to avoid any issues as you design your survey.  
  
**It’s important to make sure these questions are always voluntary for the candidates.** They should never be required in order to submit an application. They must also be uniformly asked and not related to a specific role in any way. Adding a note to the survey-taker that these questions are for furthering your DEI strategy, and will have no impact on their application, is a good idea.  
  
Additionally, ensure that this data is anonymized to those who are involved with hiring your candidates. This data is great to collect, but only if it’s being used _after_ all hiring decisions are made. It must never impact the choice itself, even accidentally.  
  
Check your hiring software to see what your options are for working with EEOC and diversity survey data. Ashby captures this data in such a way that it cannot be viewed on an individual basis, but can be analyzed in aggregate. You won’t be able to see the data per person, even accidentally, but generating reports and analyzing your DEI survey data overall is extremely easy.  
  
Once you’re confidant in your approach, the way you ask your questions is the next important consideration.  

## What data do you need?

To figure out what questions you’ll ask, pull back and look at your goals. Are you looking to improve where and how you source candidates? Are you hoping to uncover unconscious biases in your hiring process? Set your goal first, then consider which metrics that can help you make progress towards that goal.  
  
For instance, if you’re working to improve diversity via candidate sourcing, you may want to track which candidates come from which sources. So you may ask some questions about how they identify as well as how they heard about the job. Then you’d see if those things have a correlation. Frequently, inbound applications and referrals skew less diverse, but being able to identify that trend helps you show that you need to expand where you source new candidates.  
  

> Keep in mind that there are many types of diversity. Racial and ethnic identity, gender identity, LGBTQIA status, disability status, and veteran status are some elements you might want to consider, and you may have other elements of identity that you’d like to track instead or in addition.

  
It’s much more effective (and easier!) to tailor your questions to your goals than vise versa.  
  
While clear single-choice answer options will keep your data the cleanest, open-response boxes will give you the most inclusive answers. We suggest merging both. **In academic and scientific surveys, the best practice is to ask participants to click on the best multiple choice answer _and_ specify further in a write-in box.** This helps you get both clean data and a full spectrum of answers, including ones you may not have considered.  
  
![survey setup in ashby](/images/success-diversity-survey.png)  
  
In Ashby, diversity surveys are completely customizable. You can start with EEOC questions or skip right to devising your own. And you can customize the type of question to match the information you need, so don’t feel pressure to stick to multiple choice ranges.  
  

## Metrics and effective tracking

As you focus on improving your recruiting pipeline’s diversity, you may see other metrics go down a bit. This is a temporary issue, and the focus shift will be worth it in the long run, but you’ll want to make sure all your key stakeholders are aware of this up front and are ready to see those metrics shift.  
  
We talk more about that in the next article in this series, [How to Track and Improve Your DEI Hiring Metrics]([https://www.ashbyhq.com/blog/recruiting/track-and-improve-dei-metrics](https://www.ashbyhq.com/blog/recruiting/track-and-improve-dei-metrics)), so read that next if you’d like to know how to watch the results and make them better over time.  
  
Think about how you want to send these surveys to your candidates. A big risk to optional surveys is survey fatigue, when a participant is tired from filling out multiple surveys or answering more questions than they have the energy to pay attention to. Survey fatigue can result in incomplete or skewed data.  
  
Ashby offers very powerful tools for survey delivery automation - you aren’t stuck giving them to candidates after they’ve filled out the rest of your application. Instead, you’re free to collect the data at a later stage in the interview process. Check to see if this is an option for you.  
  

## Designing for your hiring future

It's ok to feel nervous about pursuing DEI and wanting to get it right, but following these best practices will help to alleviate stress and uncertainty while seeking to build out a more diverse and inclusive team.  
  
Once you feel like you know what to ask, head over to [How to Track and Improve Your DEI Hiring Metrics](https://www.ashbyhq.com/blog/recruiting/track-and-improve-dei-metrics) to learn more about tracking and analyzing what you’ve learned.  
  
Liked this article? [Subscribe to our blog](https://www.ashbyhq.com/blog/#newsletter-form) for more.

How can you know that you're asking the right questions to get the DEI survey data you need? Ashby has combined best practices from recruiting and scientific data collection to help you perfect your applicant diversity surveys.

How To Design a Better Diversity Survey

[SourceWhale](https://sourcewhale.com/) and Ashby are teaming up! SourceWhale is an engagement platform that allows you to automate the tasks you do every day, freeing up your time and attention for the more human parts of recruiting.

![sourcewhale’s logo](/images/sourcewhalelogo.webp)

With Ashby and SourceWhale, you can source talent with multi-channel sequencing, diversity insights, and AI analytics.

If you’d like to learn more, visit [Ashby University](https://www.notion.so/SourceWhale-1c11df53e4aa4052bc22db3d0110f79b).


Read on to learn more about Ashby's partnership with SourceWhale!

Ashby Has Partnered with SourceWhale

There was a time when Ted Kleber was making upwards of 75 cold calls every single day just to make a hire.  

“It was a lot of trial and error!” he told Ashby when we sat down with him. “You were given a job description and a hiring partner. And then you had to learn your own way through it.” He had to rely on his candidates themselves to learn what his own interview questions meant. “A lot of it was on the phone with candidates. I would ask them to explain to me what they did and, thankfully, I met a lot of people who were kind enough to take the time to talk to this junior recruiter to explain, _this is what I do and this is what you mean when you're asking these questions_.”  

As introductions to the world of recruiting go, it was a rough one. But it did inform Ted’s hiring philosophy. “You just have to not take it personally if you have a rough call or somebody decides not to take the job you're offering. Because it isn't personal. But that said, it pays dividends to be collaborative and to have a kind and honest approach.”  

These days, Ted isn’t making nearly so many cold calls. He’s the senior manager of recruiting operations over at [Nylas](https://www.nylas.com/), boasting a well-earned decade in the technical recruiting field working for companies like Uber and Twilio.  

“About two and a half years ago, I made the transition into recruiting operations,” Ted said. “And I've been doing that since. At Nylas, the role is kind of unique and it's taking shape even as I'm developing it.”  

## **What recruiting operations** **_is_**

If most recruiters wear a lot of different hats, Ted has a particularly impressive collection. “Part of it is ensuring that our systems are configured correctly and that we have the right tools and software and systems. Another part of it is data analytics and understanding what activities are going on and, and how we’re setting goals. Another piece of it is enablement and training materials, so some of that is building training for the business. That’s so they can feel comfortable with our recruiting process and internal enablement materials, so that the recruiters know how to use our different tools, where to go for resources, and how to interact with the business expectations. There's also an element of employer brand; I'm also helping with our presence on social media like LinkedIn, Glassdoor, AngelList, and contributing a little bit to like our website and making sure that our job posts are all branded correctly.”  

Though Ted is building out a team to help shoulder the work, he mentions that these duties came up organically. “I went in expecting one thing and I just found all these opportunities to expand and help out. That's one of the nice things about being part of a startup, you can really set whatever scope you want to.”  

> "As a recruiter, your focus is really on your client. And there's all this other stuff that needs to be thought of, set up, and built to support that function."

That’s an unsurprising function of the recruiting operations role. In a space so new, definition is a constantly evolving work in progress.  

“Recruiting is such an interesting division to be in in HR, and the recruiting operations function as a subset of that is an emerging space,” said Ted. “If you think about the traditional roles in recruiting, you have recruiters who need to focus on their clients and focus on making good hires for the business. But then there's all this other activity that has to go into recruiting. Think about it as a business within a business. You need to be a bit of a marketer, a bit of a lawyer, a bit of a sales person. On top of that you need to understand how to build a good experience for your candidates and for your hiring managers. As a recruiter, your focus is really on your client. And there's all this other stuff that needs to be thought of, set up, and built to support that function. Recruiting operations can be a bit of a catchall, but it's also an opportunity to fill in those gaps.”  

## **Startup recruiting isn’t made for robots**

After years recruiting for startups, Ted had noticed that many of them repeatedly miss the same marks when it comes to their talent acquisition. “There are some startups that do an incredible job at hiring,” he clarified. But of those that don’t, the mistakes are often the same: “Recognizing the value add that recruiting is.”  

He went on thoughtfully. “I've talked to some chief people officers that have said, _well, I just sort of view recruiting as an overhead_. _It's a function that consumes money from the business and I don't see the value in it._ But then there's other startups where hiring is _so_ critical! People call it the war for talent, and I don't know if I love that term. But the competition in recruiting to get the right people into the role is so key at the startup baseline. If they don't have the right people that has that cascading effect of not being able to ship products or hit revenue goals and eventually that doesn't look great to investors or the public.”  

It’s two very different approaches to hiring that impact everything else a startup is.  

“What really good startups do,” he said, “is recognize the value that recruiting brings as a function to grow the business. They also see a recruiter as being a strategic partner to hiring managers and helping them do organization planning. Everything from thinking about their job profiles and how to build a healthy team, to what the right balance of senior to junior folks on the team is.”  

It isn’t enough to hire often, Ted pointed out. It requires dedicated, full-time thought. “These good startups don't just stop at a job profile, they need an individual that's gonna contribute in a certain way. Recruiters can add a lot of value by taking that consultative approach and influencing that manager to think about the best long-term growth strategy for their team. That goes into headcount, planning, and conversations that they have with HR and finance to stick to that strategy.”  

>"What really good startups do is recognize the value that recruiting brings as a function to grow the business. They also see a recruiter as being a strategic partner to hiring managers and helping them do organization planning."

“I think the best startups view recruiting as more than just _I turn the crank, I point my recruiter coin-operated robot, and they get me the people_,” he went on. “They add so much more value than that. That's the difference between recruiting at a successful startup and recruiting at just a regular one.”  

Of course, it’s easier to speak of the recruiter who can keep up with that than it is to find them.  

## **The right skills for a unique job**

It’s a complex time for recruiting. COVID-19 continues to impact the world, companies are deciding between remote or in-person work, and news outlets struggle to name the ongoing wave of quitting and hiring and recruitment confusion. But Ted points out that we’re still in a candidate’s market.  

“Everything that you do,” Ted told us, “Either front of mind or back of mind, should be providing a good candidate experience. Every call you make, every email you send, every follow up that you need to do, all of that has a direct impact on your ability to attract top talent. It’s in the communication cadence, and the importance of making sure that you’re giving somebody the right kind of attention. Even though there's tons of opportunities out there, the job search can be a very personal and vulnerable thing.”  

Falling short on experience too often is damning to a small startup. “It can start to build a reputation. There's a ripple effect that accumulates out there in the market. It makes it a lot harder to attract talent if people are not saying great things about your company.”  

The best way to combat this, advises Ted, is to understand, “It's a numbers game. You need to know your clients and your managers, and the profile that you're looking for. You have to provide a solid experience for each candidate, regardless of whether or not they're moving all the way through the process. You never know who you might need to call again, and you never know what people might leave you on a public review site.”  

The other key for anyone making the jump into recruiting operations is prioritization, the harsher, the better. “As a recruiter and now as an operations manager, there are so many things that need to be done. Being pulled in so many directions at once can be really daunting. Sometimes it can be to the point where you're a bit paralyzed and you get nothing done because you have 16 things to do and you feel like you have no time to do them, or you can't do all of them well.”  

Ted fixes this by making firm calls and committing to them. “I borrow one of the values that I learned at Twilio: ruthlessly prioritize. Taking a step back from the waterfall of the things that you have to do and saying, _what can I fill my bucket with?_ I'll stick my bucket out and I'll catch the things that I know are going to have the most impact.”  

Even the best don't always make the right calls. “Sometimes you let the wrong things slide. Sometimes you execute on something that doesn't necessarily really have as big of impact as you expected. But if you start to think about your role in that sense and focus on the wildly important things, it will help you manage the rest.”  

## **The structure makes the success**

An excellent manager helps with all these skills, of course, and can be the bridge between a recruiting team wanting to do their best and startup leadership seeking to hire top talent.  

“For career growth and for opportunity, never underestimate the value of a good leader and a good mentor,” Ted told us. “Being able to recognize that quality as you're interviewing, and finding someone that you want to work with and you feel has your best interests going to go a lot further than just the name of the company you might join.”  

As for his own managers, Ted hesitated to limit the praise to a specific person. “I wouldn't point to any one single person and say this is the person that changed my career forever. I learned all sorts of different things from different people along the way. I learned a lot of discipline from some mentors in the agency. I learned a lot of general process knowledge from people in operations. Even my peers have been mentors in some respects. I really believe anyone you can learn from is a mentor, and I think you can have multiple mentors that serve multiple mentoring purposes. It all comes down to communication and being genuine and kind to your colleagues and offering what you can. Because you may view them as a mentor, but they also might view you as a mentor too.”  

With all the progress he’s made in his career, the kind and honest approach Ted learned doing hiring agency work has not changed. “I've met a lot of recruiters and tried different tactics in my day and I've often found that what people best respond to, both colleagues and candidates, is honesty and being genuine. As long as you're being upfront and genuinely yourself when you're talking to people and when you're collaborating or recruiting, it builds that foundation of trust. That's gonna' be important later on in the process.”

You can find Ted on [LinkedIn](https://www.linkedin.com/in/ted-kleber-47124143/).

We spoke to Nylas's Ted Kleber on getting into recruiting, and why a thoughtful approach helped him succeed.

Nylas’s Ted Kleber on Bringing out the Best in Recruiting Operations

Ben Asher


At Ashby, we leverage GitHub Actions for lots of small automated tasks. We recently introduced a reminder to deploy changes to production when the number of commits in the deploy passes a specified threshold.

For some background, we deploy by merging `develop` into `master` (via a merge commit). `develop` consists of commits squashed from pull requests. We default to smaller pull requests, so commits may pile up on `develop` if nobody needs to deploy to production right away. Suppose a production issue happens after a deploy and the deploy has lots of commits. In that case, it's harder for our team to roll back (e.g., it has database migrations) and harder to identify the commit(s) that caused the issue. 

To avoid letting deploys accumulate lots of commits, we wanted to figure out a continuous deployment strategy that would keep deploys small. We considered several strategies and, for now, landed on this automated reminder. The reminder has several benefits:

- Deploys are always attended. We wanted to avoid issues where an automated solution might deploy right when everyone signs off for the day in North America or Europe.
- No changes to our deploy process were needed. We're hiring [roles to dedicate more time to improving our deployments](https://jobs.ashbyhq.com/ashby/?departmentId=2c32d70f-d7cb-4a06-bd87-048084e3eb10), but we wanted to reduce deploy size while minimizing immediate effort.

Here's our GitHub Action in its entirety:

```yaml
name: Please Deploy
on:
  push:
    branches:    
      - 'develop'

jobs:
  please-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository code
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - name: Maybe Ask for Deploy
        run: |
          if [ "$(git rev-list --count origin/develop ^origin/master)" -gt "$MAX_COMMITS_BEFORE_NOTIFY" ]; then
            curl -X POST \
              --data '{ "channel": "C02D678LP29", "text": ":rotating_light: The deploy is getting too big! Can someone (on-call?:pray:) please deploy? https://github.com/ashbyhq/Ashby/compare/master...develop :rotating_light:" }'\
              -H 'Content-Type: application/json; charset=utf-8'\
              -H "Authorization: Bearer $PROD_NOTIFY_SLACK_TOKEN"\
              https://slack.com/api/chat.postMessage 
          fi
        env:
          PROD_NOTIFY_SLACK_TOKEN: ${{ secrets.PROD_NOTIFY_SLACK_TOKEN }}
          MAX_COMMITS_BEFORE_NOTIFY: 4
```

The GitHub Action sends an automated message to our #ping-engineering channel when `develop` is behind `master` by five commits, ensuring that we keep the ship shipping throughout the day!

![Slack Message Screenshot](/images/gridhub-actions-deploy-reminder/slack.png "The automated message in Slack")


An automated reminder to deploy as an effective way to keep deploys small and safe.


Continous Deployment via a GitHub Actions Reminder


ES2022 introduces `Array.prototype.at` and we've come to love using it. `Array.prototype.at` can replace using the standard index operator `[]`:

```typescript
const arr: number[] = [];

arr[0].toString();

// Same as above!
arr.at(0).toString();
```

In the example above, even though index 0 may not have anything there, Typescript is happy to allow us to to call `toString()`. With `.at()`, we get a compiler error:

![Typescripts Compiler Error](/images/array-at/compiler_error.png "Typescript's compiler error.")

`Array.prototype.at` is not officially supported in all versions of Node. Check [node.green](https://node.green/) to see if you can use it!

Array.at provides better type safety than the standard index operator, and it works with Node 16!


Type Safety with ES2022's Array.prototype.at


[`jq`](https://github.com/stedolan/jq) is a tool I use at least two to three times a week (maybe daily when it's my week to investigate sentry issues in production), so I thought I'd write about it and its XML offshoot, `xq` (via [yq](https://github.com/kislyuk/yq)).

A lot of our day-to-day work involves reviewing API request and response data in structured text formats, whether it be debugging, reviewing input or output formats for vendor APIs, etc. Often, I find I have a question about a JSON blob, and that blob is too large to inspect by just giving it a "once over." Enter, `jq`. In it's most basic form, `jq` lets you query JSON documents, but it's also useful for linting and formatting minified JSON.

## Basic Usage

Let's say I have the following JSON blob:

```json
{"firstName":"Ben","lastName":"Asher","email":"ben@example.com"}
```

Copy this to your clipboard and run the following command (after you install `jq` with, for example, `brew install jq`<Footnote>Some other ways to install `jq` are [here](https://github.com/stedolan/jq)</Footnote>)

```bash
pbpaste | jq '.'
```

This prints the following:

```json
{
  "firstName": "Ben",
  "lastName": "Asher",
  "email": "ben@example.com"
}
```

What we did is pipe the output of our clipboard into `jq` and use the `jq` command `.` to print it with better formatting (and colors!). If the JSON were invalid, it would tell you where it's invalid. I've found this immensely useful for quickly fixing issues in our public API documentation since our API documentation vendor requires valid JSON in our sample responses that we present readers.

## Querying JSON

Things get even better when you need to query JSON. I often find myself investigating a Sentry error and debugging an issue that requires inspecting JSON involved in the error. Let's say I have a list of people in JSON format:

```json
[
  {
    "firstName": "Ben",
    "lastName": "Asher",
    "email": "ben@example.com"
  },
  {
    "firstName": "Ronald",
    "lastName": "Martin",
    "email": "ronald@example.com"
  }
]
```

If I want see just emails, I can do `jq '.[].email'`. That `jq` command string tells it to look at each array element (you can also do `.[0]` to select just the first one, for example), and from each one, select the `email` attribute. This prints:

```txt
"ben@example.com"
"ronald@example.com"
```

For a recent issue, I had data like the JSON above, and, if one of the object fields were missing, the backend code threw an error. The amount of data was too large to inspect manually. With `jq`, I could query each attribute, and, if `jq` couldn't find it, it printed `null`. So, to find which attribute was the culprit, I did `jq '.[].email' | grep 'null'` and replaced `email` with each sibling attribute until I got a `null`.

## Querying XML

`jq` is super powerful, but recently I wanted to do something like the example above, but with XML. Our customer job feeds for vendors are in XML and often contain thousands of jobs. I found out a new vendor would not ingest jobs that didn't have a valid two digit country code. Before we launched with the vendor, I needed to figure out how many jobs would be impacted. I figured there must be an equivalent for XML, right? There is, and it's a [tool called `yq`](https://github.com/kislyuk/yq) that wraps `jq` and supports multiple other formats. It ships with a tool called `xq` that you can use for XML.

Back to my task, I needed to figure out how many job postings in the feed would be dropped by the vendor. For simplicity, I'll use the snippet below as our "feed" and walk you through what I did. You can install `yq` with `brew install python-yq`.

Let's copy the feed to our clipboard:

```xml
<?xml version="1.0" encoding="utf-8"?>
<source>
  <publisher>Ashby</publisher>
  <job>
    <title><![CDATA[Product Engineer]]></title>
    <country><![CDATA[US]]></country>
  </job>
  <job>
    <title><![CDATA[Full-Stack Engineer]]></title>
    <city><![CDATA[Remote]]></city>
    <country><![CDATA[CA]]></country>
  </job>
  <job>
    <title><![CDATA[Pilot]]></title>
    <city><![CDATA[Remote]]></city>
    <country><![CDATA[PT]]></country>
  </job>
  <job>
    <title><![CDATA[Software Engineer]]></title>
    <city><![CDATA[Remote]]></city>
    <country><![CDATA[DE]]></country>
  </job>
  <job>
    <title><![CDATA[VP of Sales]]></title>
    <city><![CDATA[San Francisco]]></city>
    <country><![CDATA[United States or Canada]]></country>
  </job>
  <job>
    <title><![CDATA[Data Analyst]]></title>
  </job>
</source>
```

Then save the contents of our clipboard to a file:

```bash
pbpaste > feed.xml
```

From here, I want to query countries. Countries are at the path `.source.job[].country`. I can do the following to quickly check them out:

```bash
cat feed.xml | xq '.source.job[].country' | less
```

Looking at that output, I see some `null`s and some country codes, so I know I'm in right place.

Stepping back, our vendor only accepts two digit country codes. The way our feed code works is that we look up the user-inputted country's country code (for example, via [node-countries](https://www.npmjs.com/package/node-countries)). If we can find the country code, we use it, and, if we can't, we use the original value (people sometimes input invalid countries like "Remote" or "United States or Canada"). Also, some won't have countries, so we see some `null`s.

## Operators

To know what the vendor is going to drop, we can use the length of the country field (only ones of length two will work), which `xq` (and `jq`) can calculate! To get the length of all country codes, I can do this:

```bash
cat feed.xml | xq '.source.job[].country | length' | less
```

That's right! `xq` and `jq` have their own operators, which you can pipe output to within the command. The operator above will output the length of each country, and looking at the output, we can see that we're getting `0`s where we had `null`s before, and `2`s for most things (phew!). To get our final answer, we can run the following command:

```bash
cat feed.xml | xq '.source.job[].country | length' | grep -v '2' | wc -l
```

This takes that output that we were viewing in `less` and pipes it to `grep`. With `-v`, we tell `grep` to only give us output that doesn't match, so that gets us all of the "bad" countries. Piping that to `wc -l` will count the number of lines and give us our answer.

## Conclusion

`jq` and its offshoots are super powerful, and I use them all the time, even if it's just the basic path-based searching of JSON files (or formatting to make smaller ones nicer to read). For everything else, I can usually find a useful operator (via Stack Overflow or [`jq`'s docs](https://stedolan.github.io/jq/manual/)) that'll help me put together fancier queries.


How I use command line tools to inspect JSON and XML data that would be impossible to do by eye.


Querying JSON and XML with jq and xq

Graham Murdoch


In Typescript, when defining a type, it's nice to use a union of [literals](https://www.typescriptlang.org/docs/handbook/literal-types.html):

```typescript
type Sizes = "sm" | "md" | "lg"
```

This allows developers to quickly enter a valid value without having to import and expand an enum. In an editor like VSCode, you get a nice autocomplete prompt with the possible values.

However, sometimes you want a union of literals plus some flexibility for custom values. In this example, we want to allow CSS length units (e.g. `"100px"`). 

A simple solution is to combine the literals with a generic type that is a supertype of the literals:

```typescript
type Sizes = "sm" | "md" | "lg" | string
```

Adding the generic type weakens the type coverage since you can enter something potentially invalid that compiles (like `"lgg"`). You've also broken autocompletion for this type. VSCode, for example, won't show the literals as options in a useful way anymore.

One possible approach is to use a generic type that doesn't match the literal values (e.g. an object):

```typescript
type Sizes = "sm" | "md" | "lg" | { custom: string }
```

This restores autocompletion, some type coverage, and preserves a fallback option. However, it isn't quite what you want for CSS length units (and requires some superfluous decoration). 

## LiteralUnion

Prior to Typescript 4.1, a better solution was to use the `LiteralUnion` utility from the [`type-fest` package](https://github.com/sindresorhus/type-fest):

```typescript
import { LiteralUnion } from "type-fest"
type Sizes = LiteralUnion<"sm" | "md" | "lg", string>
```

While it still allows invalid values, autocompletion of the literal values works again!

## Template Literals

As of Typescript 4.1, we can do better. Using [template literal types](https://www.typescriptlang.org/docs/handbook/2/template-literal-types.html), we can more accurately model (and restrict) the range of values:

```typescript
type Sizes = "sm" | "md" | "lg" | `${number}fr` | `${number}px`;

const size: Sizes = "sm"     // ✓
const size: Sizes = "1fr"    // ✓
const size: Sizes = "100px"  // ✓
```

### Working with Enums

At Ashby, some of our older code uses enums and, for consistency, we continue to use them as the basis for possible values.

Historically, you couldn't really combine the approaches:

```typescript
enum DesignSystemSizes {
  sm = "sm",
  md = "md",
  lg = "lg"
}

type Sizes = DesignSystemSizes.sm | DesignSystemSizes.md | DesignSystemSizes.lg

const size: Sizes = "sm"     // 𝒙 - no literals in autocompletion
```

With template literal types we can!

```typescript
enum DesignSystemSizes {
  sm = "sm",
  md = "md",
  lg = "lg"
}

type Sizes = `${DesignSystemSizes}` | `${number}fr` | `${number}px`

const size: Sizes = "sm"     // ✓ - autocompletes literals and DesignSystemSizes!
const size: Sizes = "1fr"    // ✓
const size: Sizes = "100px"  // ✓
```

## Conclusion

With Typescript 4.1 and later, you can do some pretty interesting things to construct accurate types using literals and template literals. Exciting stuff!

Use template literals to create flexible types that accurately check possible values at compile time and support autocomplete in common editors (like VSCode).


Flexible Types that Support Autocomplete with Template Literals (Oh My!)

Arjun Nayini


When writing tests, especially longer integration tests, sometimes you want to run _nearly_ the same test, but with a few key variables changed. Instead of copying and pasting your integration test into another `it` block and changing the small details, you can use the `.each` table syntax [provided by Jest](https://jestjs.io/docs/en/api#describeeachtablename-fn-timeout):

```typescript
describe.each`
  variable1             | variable2
  ${"mystring"}         | ${true}
  ${"otherstring"}      | ${false}          
`(
  "Testing a variety of cases",
  ({
    variable1,
    variable2,
  }: {
    variable1: string;
    variable2: boolean;
  }) => {
    // Test content...
  }
)
```

The `.each` table syntax<Footnote>You can also define the table as an array of arrays or array of dictionaries.</Footnote> allows you to paste in a string that represents the different test cases you want to run.  The first row defines the names of variables that will be passed to each run of the test.  Each subsequent row represents a test run where the provided values will be bound to the variable names.

In example above, two tests will be run where:

1. `variable1 = "mystring", variable2 = true`
1. `variable1 = "otherstring", variable2 = false`

This technique can make tests a lot more readable. Note that in the above snippet, you'll have access to the variables in the body of the test content.

In using `.each`, I've noticed that it is often best when you don't want to change too much of the test logic based on the variables.  If your test ends up having a lot of `if/else` logic based on the variables, especially throughout the entire body of the test, I think it's better to just copy-paste as the additional complexity to read the test isn't worth it.


How to write similar Jest tests without copying and pasting code.  


Testing Using Jest Table Syntax

Ronald Martin


In standard Typescript, you can make an arrow function [generic](https://www.typescriptlang.org/docs/handbook/2/generics.html) by declaring the type variable before the arguments:

```typescript
const identity = <T>(arg: T): T => arg;
```

However, if you try this in a React `.tsx` file, the compiler tries to parse the type variable as a JSX tag:

![Typescripts Compiler Error](https://static.slab.com/prod/uploads/l73blu9g/posts/images/ysOnK_8JL2tvLGuUSS6I__Rh.png "Typescript's compiler error.")

To help the compiler know that this is actually a generic type variable, put a comma (`,`) after the type variable:

```typescript
// Note the comma 👇
const identity = <T,>(arg: T): T => arg;
```


How to fix Typescript compiler errors from generic arrow functions in .tsx files.  


Ashby Has Partnered with MeVitae

Hiring Analytics Tools - Is Building or Buying the Best Choice for You?

Ashby Has Partnered with CodeScreen

How To Design a Better Diversity Survey

Ashby Has Partnered with SourceWhale

Nylas’s Ted Kleber on Bringing out the Best in Recruiting Operations

Snippets

Continous Deployment via a GitHub Actions Reminder

Type Safety with ES2022's Array.prototype.at

Querying JSON and XML with jq and xq

Flexible Types that Support Autocomplete with Template Literals (Oh My!)

Testing Using Jest Table Syntax

Using Generic Arrow Functions in .tsx Files

Product

Resources

Company

Developers

Ashby Has Partnered with MeVitae

Hiring Analytics Tools - Is Building or Buying the Best Choice for You?

Ashby Has Partnered with CodeScreen

How To Design a Better Diversity Survey

Ashby Has Partnered with SourceWhale

Nylas’s Ted Kleber on Bringing out the Best in Recruiting Operations

Snippets

Continous Deployment via a GitHub Actions Reminder

Type Safety with ES2022's Array.prototype.at

Querying JSON and XML with jq and xq

Flexible Types that Support Autocomplete with Template Literals (Oh My!)

Testing Using Jest Table Syntax

Using Generic Arrow Functions in .tsx Files

Subscribe to Updates

Product

Resources

Company

Developers