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 brings virtual behavioral and mental health care to kids and teens, with a focus on also supporting families. They have no waitlists, provide customized plans, and work with families to track progress together.

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

Docker

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

Format One

FullStory

Galileo

Ironclad

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

Mastodon

Modern Treasury

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

Monte Carlo

Multiverse

Notion

Compensation software that offers 5,000+ companies clarity for every pay decision.

OpenComp

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

Quora

Ramp

Readme

Replit

Retool

Scratchpad

Sequoia

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

Vantage

Veev

Verkada

WeTransfer

Zippin

Engineering

Recruiting

Product

Benjamin Encz

We’re excited to be partnering with Bryq! Bryq is a talent intelligence platform that helps you make faster, smarter talent management choices throughout the employee lifecycle. From hiring to retiring, you’ll hire, grow, and retain talent better than ever using objective data.
  

![Bryq candiate comparison](/images/bryq-candidate-comparison.png)

Bryq measures personality traits and cognitive skills of candidates and current employees, and tracks HR metrics to match roles and teams, eliminate bias, and help solve for inefficiencies.

![Bryq chatbox function](/images/bryq-chatbot.png)

With Bryq and Ashby working together, you’ll have more data than ever to help you make the best choices for your business, and grow your team like never before.

Check out more about Bryq [here](https://www.bryq.com/product/how-it-works/), and drop by [Ashby University](https://www.notion.so/Bryq-coming-soon-677872ae5f7941a29e9a0e991598161a) in the coming days for more on how this integration works.

Read here to learn about how Bryq and Ashby have teamed up.

Ashby Has Partnered with Bryq

Ashby is excited to partner with Searchlight - a predictive talent platform that measures and improves Quality of Hire by connecting candidate reference and self-assessment data to post-hire outcomes. Searchlight provides real-time insights that enable continuous learning to hire and retain the right people.

![searchlight information views](/images/searchlight-graphic.png)

Searchlight makes it easy to discover complex data on everything from candidate strengths to cultural alignment, and working together with Ashby, it’s all in one workspace.

![searchlight within ashby](/images/screen-shot-2021-11-05-at-11.12.18-am.png)

Ashby users can invite candidates to the Searchlight assessment process with a single click, and see the results in just two days. In addition, hiring managers can access Searchlight Candidate Reports from Ashby to make better hiring decisions that improve quality of hire and retention.  
  
Searchlight is on a people-first mission to make hiring win-win for everyone by understanding talent better, and we couldn’t be happier to be working together on those goals.  
  
[Schedule a demo with Searchlight](https://lp.searchlight.ai/demo-request-ashby) and check out how it all works in [Ashby University](https://www.notion.so/Searchlight-Reference-Checks-d84f3cc4353a44b4a9de4b6fd7fad922).

Ashby and Searchlight are now working together - read on to learn more!

Ashby Has Partnered with Searchlight

I’ve recently tried a new technique when it comes to hiring decisions for critical leadership roles, which I now call the the **“hiring memo”**.  
  
Like many companies, we have a live debrief session at the end of each interview loop to discuss the feedback we capture. While the individual feedback is very important in isolation, the live discussion often reveals themes that weren’t picked up by any individual alone. We have had a few cases in which we made a no-hire decision based on a theme that emerged during the debrief, despite consistently positive scores in each session.  
  
If you have hired for a role many times before and are well-calibrated, the live debriefs become pretty efficient and usually allow for a hiring decision without prolonged discussion.  
  
For novel roles, and especially for key leadership hires, the live debrief can become a bit unwieldy. A typical leadership interview process involves _a lot_ of interviews. Leaders are also tested across a lot of rubrics. Because of that (and because of the high bar and the high stakes for leadership hires) you are unlikely to end up with a candidate who excels in all interviews and in all rubrics.  
  
Prior to starting Ashby, I was involved in a series of leadership hires and the debriefs always felt difficult to manage. In some cases they felt rushed given the importance of the hire. In other cases a lot of time was spent but it was challenging for the hiring manager and recruiting team to synthesize the many points of feedback. Which positive or negative feedback is the most relevant? To which degree does it tie back to the actual skills required for the job?  
  

> **For novel roles, and especially for key leadership hires, the live debrief can become a bit unwieldy.**

## Writing the hiring memo

This is where the hiring memo comes in. If a clear consensus could not be reached in a reasonable time (I would limit it to 30 minutes) during the live debrief, one proceeds to writing the memo as a next step instead of making a hire/no-hire decision on the spot. During the debrief, the hiring manager should take notes on all the positive and negative pieces of feedback that were voiced. They then take time to write a document that synthesizes these points of feedback and ties them to the original requirements for the job.  
  
My memo took the following structure:  

- **A link to document with job requirements and skills we are looking for**
- **Deconstructing the negative feedback**
   -   One bullet with the feedback the way it was voiced, e.g. “It seems that this candidate lacks experience selling to SMB. They couldn’t surface good examples of that in our interview.” (No, this is not from a real candidate!)

   -   Sub-bullets that outline the hiring manager’s position on this point of feedback; how relevant is it?

- **What stood out positively**

   -   One bullet for each point of positive feedback, as it was voiced, e.g. “The candidate had strong opinions but was open to changing them through discussion, for example...”

   -   Sub-bullets that outline the hiring manager’s position on this point of feedback; how relevant is it?

- **In Summary**

   -   A couple of paragraphs discussing the feedback contributes to a hire or no-hire decision

  
This memo can be very helpful in bringing structure to what can often become a fairly unstructured live conversation. It ensures that all concerns are articulated and addressed. It also forces the hiring manager to explain why they recommend a hire or no-hire decision and how that decision relates to that feedback.  

## Distributing and discussing the hiring memo

Once written, the memo can be shared with the debrief participants. They can comment asynchronously to make sure that all feedback is accurately captured and to provide their agreement or indicate that they want further discussion. It may be that the writing of the memo adds enough clarity to get everyone on the same page. If there are still remaining disagreements a second live debrief can be run with the small subset of open issues and a much smaller group of people - that will help keep that conversation efficient.  

## Making a decision

How you end up making the final call will depend on your hiring philosophy. At Ashby, the hiring manager has the ultimate responsibility for a hire/no-hire decision. No hiring decision is certain, but at this point the hiring manager has gotten as much information as possible and it’s time for a final verdict!  
  
I believe this tool to be pretty helpful for building consensus where possible and to help people that may disagree with the outcome to understand the reasoning behind the decision.  

If you try this out, [let us know how it works for you on LinkedIn](https://www.linkedin.com/posts/benjaminencz_the-hiring-memo-a-tool-for-managing-complex-activity-6913204278950051840-1pUi?utm_source=linkedin_share&utm_medium=member_desktop_web)!

We're using a new technique in our critical hiring decisions. It's called a hiring memo - here's what it is and why it works.

The Hiring Memo - a Tool for Managing Complex Interview Debriefs

Halden Pfearsen

You’ve worked hard to find the right data reporting tool for your team. Now you just have one challenge: rolling it out and getting the whole team to use it.

At Ashby we’ve helped a lot of customers bring new data to their teams through our recruiting analytics product. We often get questions about how to roll out a new data tool within an organization - and we have a lot we’ve learned that can help you with just that. In this post we’ll walk through some straightforward steps that will make a successful rollout of a new tool on your team a lot more likely.

If you’ve ever been through it, you know that rolling out a software tool and encouraging wide adoption isn’t easy. With technical software, like data reporting, it can be even harder.

Luckily, there’s an approach you can use to tailor your rollout and give yourself the best chance of not only getting full adoption of a new tool, but genuine buy-in from everyone using it. This is that approach, laid out step-by-step, so you’ll ask the right questions and find the right answers to set yourself up for success.

This article uses recruiting reporting and data software, such as Ashby, as an example, but this rollout method applies to any analytic tool, from Google Analytics in content marketing to efficiency data for manufacturing. The data may differ, but the rollout methodology remains the same.


## Step one: Goal setting

From the start, you need to be thinking about the end. We encourage you not just to think over your goals, but to write them down formally and, as part of your rollout, share them with your team. But more on sharing in a moment.

It isn’t enough to say that you want everyone to regularly use this tool. You need to be specific. In your ideal outcome:

1. Who is using this tool?
2. What do they do with it?
3. How frequently do they access it?

You may end up writing a few different use cases. That’s a good thing, because it gives you nuance in how to approach the rollout with different groups in your organization.

For instance, your answers may look like, “Recruiters are using this hiring reporting tool to help them hire every day.” But, at the same time, they may also look like, “The Head of People is using this hiring reporting tool to see metrics and pull high level reports bi-weekly.” A single tool can do more than one thing for more than one person, and noting the nuance and the various use cases helps you explain the tool more effectively to different groups.

If you find yourself getting stuck on a question, make a note of it and return to it later. Flag who you need to talk to or what information you need to fill in those gaps.

At the end of this step, you should have a strong idea of how your team will use your reporting tool on a daily or weekly basis. Your answers to these questions will inform every other element of your rollout.


## Step two: Determining scope

A critical part of a successful rollout is knowing exactly who the stakeholders are. This step is more than an offshoot of goal setting, and should include people who need to buy-in but may not be using the reporting software themselves.

The easiest question comes first: who wants this tool and why? Let’s say the hiring managers on your engineering team are frustrated with a lack of detailed information about their hiring process. They’re the ones who it will be easiest to roll out this tool to, because they’re asking for it.

Next, think of who needs to give their approval on the tool. If this group is not also a user of the tool, they may not be the easiest to convince, but their buy-in is crucial.


Finally, consider who isn’t using the tool, but will still be impacted by it. Maybe you have a small team of interns who will be asked to pull reports, even if they aren’t doing the hiring. This group doesn’t need to be convinced, but they will need to be involved in the rollout.

If you work in a larger organization, it may be helpful to put all these stakeholders in top-down order, to highlight where you need to start to achieve full buy-in. In this case, that would be: *Executives > Hiring Managers on Engineering Team > Interns*.

Approaching these three groups in the same way won’t get you as much success as taking a look at their unique needs and customizing your pitches and approaches. Maybe the executive team wants to hear about the ROI and hiring improvements this tool will make. Maybe the interns don’t care quite so much about ROI, but will be thrilled to hear that the software is easier to use than the current system. Give each group the story they need to fully buy-in.

The easiest way for you to do this is to make a note of what they’ll need, then gather the data they need to see. Creating a sample dashboard or environment  within your new analytics tool for each group is a great way to do this. It feels more tangible and real than numbers in a slide deck. It also lowers the barriers for entry: even if they end up changing things later, you’ve given them a great place to start engaging with the tool. The side bonus of this approach is that it familiarizes you with the tool so you can answer questions more easily.


## Step three: Review your data

Prior to rolling out the tool you will want to do an initial review of your data hygiene.

They say “numbers don’t lie” but real truth in numbers comes from good data hygiene. If you aren’t consistently updating your candidate details as they move through your funnel, the best reporting tool in the world won’t be able to help you track your time to hire. Give data tools clean, clear information to work with.

But be aware that even if you feel good about your data hygiene, reporting tools are likely to find flaws anyway. All analytics tools work like a blacklight: they show you messes you couldn’t see in areas that seemed clean. That’s not a bad thing, in fact it’s almost inevitable, just use some of the time you’re investing to clean up your original data.

The good news is that the higher-quality your reporting tool, the better it will be at cleaning up your data. Make sure to ask your point of contact to see how the tool can help you make this part easier.


## Step four: Make a communication plan

Once you have buy-in from your stakeholders, don’t keep them in the dark about what’s coming next.

Create a timeline of your rollout and share it with each group. Your timeline will look different depending on what the tool is, how easy it is to adopt, and how many people will be using. it. Here are some examples of what you might include in yours:

* When will your data tool be available to check out?
* What day(s) will training take place?
* When should the team start using this tool for new info, such as incoming hires?
* How long will customer support be available?
* When will the team stop using old tools entirely?
* What’s the first day that everything needs to be fully moved over?
* What’s the last day data from older tools will be available before access is lost?
* When and how frequently will you be checking in with stakeholders?

Make a note if this timeline has wiggle room or if it needs to remain firm. This helps avoid misalignment surprises later.

A timeline may already be clear to you, but it may be less clear to others at various stages of adoption. An obvious reference document will also help answer questions for you, saving your bandwidth.

Follow-up with your stakeholders as the timeline progresses. You want to be active partners in the rollout, from beginning to end.


## Step five: Move with intention

You have a plan, you have buy-in, you know what data you’re working with. Now you need to carry that success through the rollout process.

Rushing a rollout is a good way to fail quickly. Humans have a natural resistance to change, so even the most excited new user may be a little slow to take up some parts of the software. That’s not always because the old method or tool was better, but because it’s familiar. Stay consistent and lean on your new tool’s customer success team, product documentation, and any other tools they’ve offered to help you roll out.

Stay consistent with your setup, too. You’ll likely need to tweak your software as you go, but once it’s set up, change it slowly and not all at once. Good data results develop over time. If you mess with your setup too frequently, it will take longer to see the important info. Be patient as you observe the information develop.


## Step six: Avoiding potential roadblocks

Any rollout is likely to encounter a few bumps in the road, no matter how well-planned. The best way to make even these bumps a little smoother is to consider them in advance so they don’t take you by surprise. We’ve outlined a few common hiccups and potential responses to help you troubleshoot.

**Changes in management:** Keep a paper trail of the decision-making process for your data tool, including notes about what rollout elements have been completed and when. If your leadership changes part-way through the rollout process, you’ll be ready to bring everyone up to speed.

**Detractors:** Some folks may disagree on the best tool for a job, or be resistant to change no matter how good it is. The best way to respond is to be empathetic and hear out any concerns instead of shutting them down. Make a list of the things you love about this tool in case you need to share it to win someone over.

**Data issues:** Maybe your use case is an edge case, or maybe something went wrong in the setup leading to unexpected results. Make sure you have the contact details of the tool’s providers, and check ahead of time if you’ll have access to a help desk or a specialist who can help if anything goes wrong. That’s an email you want before you need it!

Frustrating as they may be, these issues and others like them are nothing to worry about if the rest of your plan is solid. The stronger the rest of your rollout strategy is, the more easily you’ll be able to cope with surprises.


## Success isn’t far off

A good rollout is almost as powerful as a good new tool. As you may have noticed, the biggest element of a successful rollout is time and planning. You may want the material to be ready yesterday, but going slowly and thoughtfully into a big data tool change is going to make everything else easier in the long run. It’s always worth it to invest real time and thought into doing this right. 

If you liked this article, or it helped you with your rollout, bookmark it or [subscribe to our blog](https://www.ashbyhq.com/blog/recruiting#newsletter-form) for more high-level recruiting information.

Data reporting tools are so important to a strong recruiting strategy. While rollout can be a challenge, this method will help you get the best result.

The Straightforward Guide to a Successful Data Rollout

João Carvalho


Node.js is a fantastic piece of technology, and we use it as the foundation for our application servers.

There is, however, one big caveat when working with Node: our application code runs ([for the most part](https://nodejs.org/en/docs/guides/dont-block-the-event-loop/)) in a single thread (the Event Loop thread). Running in a single thread is fine when the application spends most of its time doing asynchronous I/O since each request consumes only a small amount of CPU. However, when your requests perform CPU-intensive computation, all concurrent requests will be blocked waiting for it to complete!

As the Ashby backend grew in size, we ran into some CPU-intensive code paths, either due to non-optimized code that didn't scale very well or the lack of result set limits (which could cause an endpoint to return an arbitrarily large amount of data).

Join us as we take you through our journey to identify and eliminate requests that block with the help of community NPM packages and our favorite monitoring tool, Datadog.

## The Node Event Loop: a Primer

<Hint type="info">
This section is a brief introduction to the Node Event Loop, meant only to provide the necessary context for the rest of this post. If you want to dive deeper into this topic, we recommend [Node's excellent documentation on the topic](https://nodejs.org/en/docs/guides/dont-block-the-event-loop/).
</Hint>

At a very high level, the Event Loop consists of a single thread running in a continuous loop, going through multiple phases, as described below:

![Node Event Loop Phases](/images/event_loop_blockers/event_loop_phases.png "Node Event Loop phases")

Each phase contains a callback queue of all callbacks that need to be processed in that phase. These include various tasks, such as processing timers (scheduled by `setTimeout` and `setInterval`), processing I/O events, and executing I/O callbacks (including the code that handles incoming HTTP requests).

All callbacks in the Event Loop are processed sequentially. Suppose a specific callback performs a CPU-intensive operation without yielding the Event Loop. In that case, all other callbacks will remain in the queue and not be processed until the Event Loop frees. We call these "Event Loop Blockers."

## Detecting Event Loop Blockers

When we set out to look for solutions to detect Event Loop Blockers, we found two great libraries in npmjs.com: [blocked](https://github.com/tj/node-blocked) and [blocked-at](https://github.com/naugtur/blocked-at) (in both cases, we used version `1.2.0` with Node 16). Both provide a similar interface: a threshold value and a callback that gets invoked when the Event Loop gets blocked for longer than the threshold.

One critical difference between the two, which stems from the fact that their implementations are radically different, is that `blocked-at` provides the callback with the stack trace for the Event Loop Blocker's entry point, whereas `blocked` only provides the Event Loop Blocker's duration. This extra information came at a cost: the performance hit of using `blocked-at` is significant, as indicated in their README:

> It's recommended to detect blocking exists with something without the performance overhead and use `blocked-at` in testing environment to pinpoint where the slowdown happens. Rule of thumb is you should not be running this in production unless desperate.

Let's look at how each of these libraries work and why the cost of capturing the stack trace is so high.

### `blocked v1.2.0`

The mechanism behind `blocked` is ingeniously simple (the whole library comes in at just [518 bytes](https://github.com/tj/node-blocked/blob/master/index.js)). When installed, it registers a timer (using
`setInterval`) to keep track of the time elapsed between invocations. The added delay between invocations can be a good indicator of an Event Loop Blocker since concurrent operations that block the Event Loop may delay timers from being fired. On every execution of the timer, if the drift between the desired and actual invocation times is higher than the configured threshold, the callback is invoked.

Since Event Loop Blocker detection happens in a different context from the running application (within the timer), it cannot gather any information about the source of the Event Loop Blocker. On the other hand, the work on each iteration is so fast that its overhead is minimal.

### `blocked-at v1.2.0`

The `blocked-at` library uses [Async Hooks](https://nodejs.org/api/async_hooks.html) to capture the additional
information about the stack trace. Node recently introduced the Async Hooks API to track asynchronous resources (such as Promises) within a Node process. A developer can register callbacks on asynchronous resource creation (`init`), when its callback is invoked (`before`), and when its callback finishes (`after`).

The `init` hook is called within the context where the resource is created, so we can capture the [current stack trace](https://nodejs.org/api/errors.html#errorcapturestacktracetargetobject-constructoropt). `blocked-at` does precisely that and stores the trace in a global map, indexed by the current `triggerAsyncId` (the mechanism Async Hooks use to identify asynchronous resources). Then, once the resource's callback is ready to run, the `before` hook is invoked, capturing the invocation's timestamp (and once again stored in the global
map where the trace is already stored). Once the callback finishes, the `after` hook is invoked, and the current timestamp is compared against the previously stored timestamp from the `before` invocation. If the difference is greater than the configured threshold, the callback is called, passing along the stack trace captured in `init`.

This approach, while providing valuable information, is too slow to be feasible, due to the following reasons:
- Async Hooks run on *all* asynchronous resources and may cause significant overhead. Recent versions of
  Node have improved this overhead considerably (we are on Node 16, so this isn't much of an issue).
- We can only capture the stack trace in the `init` hook, so before we know whether we need to invoke the callback, we waste a considerable amount of resources. Capturing a stack trace is a relatively expensive operation, and our code will discard it most of the time (when the Event Loop is not blocked).

## Our First Attempt

In our first attempt at finding our Event Loop Blockers, we wanted to get as much information as possible, so we started by measuring the performance impact of `blocked-at`.

After deploying it to our staging environment, we noticed that the response times for our most common GraphQL queries were a few orders of magnitude slower. Our test traffic was enough to consume all the available CPU resources in our staging instances! We also realized that the provided stack trace information wasn't particularly useful. In most cases, it pointed to the Apollo Field Resolver, which is responsible for invoking our code, instead of pointing to the code itself.

With this in mind, we circled back and replaced `blocked-at` with `blocked`. Even without the stack trace, we would at least be able to identify when the Event Loop was blocked and, with some manual investigation, figure out where the Event Loop Blocker occurred in our code.

With `blocked` successfully deployed in production, with minimal impact to performance or resource usage (we noticed approximately 0.5% increased resource usage with the timer running every 100ms), we were, as expected, able to identify critical code paths that were contributing to the blocking issues. However, each event took nearly 5 minutes to investigate, and with hundreds of blocking events per hour, this quickly proved unsustainable.

## Datadog Integration

We use multiple Datadog products in our monitoring stack, particularly [Datadog APM](https://www.datadoghq.com/product/apm/) and [Datadog Log Management](https://www.datadoghq.com/product/log-management/). When using these two products, we can [connect Logs and Traces](https://docs.datadoghq.com/tracing/connect_logs_and_traces/) and view all log lines generated in the context of a specific HTTP Request Trace in a single interface. In our short-lived experiment with `blocked-at`, we noticed that the logs correctly connected with the trace for the request that generated them.

After some investigation, we noticed that the Async Hook used by `blocked-at` allowed us to access the reference to the
"current trace" (as Datadog was also using Async Hooks to propagate its context). What if
instead of capturing the stack trace, we used the Async Hook to surface the blocker in the Datadog Trace?

We started by writing our own Async Hook with heavy inspiration from `blocked-at`. Our first version did little more
than detect when a blocking event happened:

```typescript
const cache = new Map<number, [number, number]>();

function before(asyncId: number) {
  cache.set(asyncId, process.hrtime());
}

function after(asyncId: number) {
  const cached = cache.get(asyncId);
  if (cached == null) {
    return;
  }
  cache.delete(asyncId);

  const diff = process.hrtime(cached);
  const diffNs = diff[0] * 1e9 + diff[1];
  if (diffNs > thresholdNs) {
    const time = diffNs / 1e6;
    logger.warn({
      label: "EventLoopMonitor",
      message: `Event loop was blocked for ${time}ms`,
      metadata: {
        time,
      },
    });
  }
}

const asyncHook = createHook({ before, after });

asyncHook.enable();
```

In the `before` hook, we are capturing the current timestamp (side note: we are using the deprecated `process.hrtime()` method, instead of `process.hrtime.bigint()`, as the latter has a considerable performance impact in Node 16), and storing it in the cache, indexed by the current Execution Async ID (like `blocked-at` does).

Then, in the `after` hook, we fetch the initial timestamp from the cache and compare it against the current timestamp. If the diff exceeds the configured threshold, we log a warning message (like in `blocked-at`, which is associated with the current Datadog Trace).

The final piece of the puzzle is surfacing the block in the trace itself, which we achieved by adding the following to the code path where the block is detected:

```typescript
const span = requestTracer.startSpan("EventLoopBlock", {
  childOf: requestTracer.scope().active() ?? undefined,
  startTime: new Date().getTime() - time,
  tags: {
    [tags.SERVICE_NAME]: "ashby-backend-event-loop-monitor",
  },
});
span.finish();
```

Here, we manually create a trace span named `EventLoopBlock`, which we create as a child of the "current trace." We also set the start time to be the current timestamp minus the total block time (the use of `new Date().getTime()` means we lose sub-millisecond precision, but this is acceptable for our use case). Doing this causes the span to be
rendered as part of our trace:

![Trace with Event Loop Blockers](/images/event_loop_blockers/trace.png "Trace with Event Loop Blockers")

This approach meant that the total amount of work done in the "good" case (where no blockers are detected) is much
smaller than in `blocked-at`: two API calls to fetch the current timestamp, two cache writes, and one cache read. The
performance impact of this approach was much more acceptable to us, ranging between 1% to 2% additional CPU usage (and a comparable increase in total response time) when deployed in production.

## Results

Since we deployed our new Event Loop Monitor, we have been able to identify most of the sources of Event Loop Blocking,
and have both reduced our total number of Blocker events by and p99 latency of said events by up to 80%!

![Event Loop Blocker events over time](/images/event_loop_blockers/events.png "Event Loop Blocker events over time")
![Event Loop Blocker p99 latency over time](/images/event_loop_blockers/latency.png "Event Loop Blocker p99 latency over time.")

## References

- https://nodejs.org/en/docs/guides/dont-block-the-event-loop/
- https://nodejs.org/en/docs/guides/timers-in-node/
- https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/
- https://nodejs.org/docs/latest-v16.x/api/process.html#processhrtimetime


Our application code runs in a single thread with Node.js. The thread can get blocked by requests with CPU-intensive computation and significantly slow our response times. We'll walk you through how we identify and eliminate these blocking requests.


Detecting Node Event Loop Blockers

Diversity, equity, and inclusion (often abbreviated as “DEI”, though they’re three separate things) are critical to modern hiring. Recruiters and hiring managers have a lot of power to make their companies and industries into better, more inclusive places to work.

Assessing and improving your DEI initiatives starts with effectively tracking demographic information about your candidates. Unfortunately, while you might know that this information is crucial, deciding *how* to track and measure it can be intimidating. Often, teams end up feeling paralyzed and not doing anything at all.


In this post, we'll walk you through your options for beginning to track demographic information, as well as show you how to report on it. With these metrics in place you'll be able to improve your DEI practices in no time.

## A quick history of tracking demographic data in the U.S.

In the United States, demographic data is mostly tracked via [Equal Employment Opportunity Commission (EEOC) questionnaires](https://eeocdata.org/). To be compliant with U.S. government standards, certain private employers need to track EEO-1 data. Other countries have their own versions of this info, but for now we’ll focus on the U.S. While it started as a compliance tool, more and more companies are relying on this data to assess their performance on DEI.


Using EEOC data has a few common limitations:

1. Because the questions are often just embedded in job applications, they may only be completed by applicants going through them - not current employees or applicants from other channels.
2. The survey is voluntary, and concerns of discrimination or discomfort with personal disclosures can prevent applicants from filling it out.
3. The standard questions are very limited, and don’t take into account all of the identities a single person could hold.

While EEOC data can be limiting it’s a good, clear place to start if you’ve never tackled DEI data collection before.


If you’d like to explore more advanced ways of collecting DEI data, there are plenty of ways to approach it.

## The three approaches to collecting demographic data

There are three fundamentally different ways to start when it comes to tracking demographic data: candidate self-identification (“Candidate ID”), recruiter-led identification (“Recruiter ID”), and inference. You may get a different quantity or quality of data from each approach; no one is “better” than another, they’re simply different. We’ll explore each of the options and also touch on why it’s common to mix multiple approaches.

### Candidate Self-Identification (“Candidate ID”)

One way to collect demographic data is by letting candidates volunteer information about themselves in the interview process. EEOC questions are one form of candidate ID.


Because these surveys are usually placed with the original job application form, you can run into a problem with sourced or referred candidates never seeing these questions. Some applicant tracking systems address this by supporting automatic survey requests at different stages and from all candidates, which can increase your completion rate.


An increasingly common alternative to using EEOC questions is creating a custom demographic survey where you choose the questions and answers yourself instead of relying on the government mandated form. This option is more available to companies who aren’t required to stick to and report on the base EEOC questionnaire.

### Recruiter-Led Identification (“Recruiter ID”)

The second way to collect demographic data is recruiter ID, where a recruiter manually tags candidates with their demographic information. This is the most accurate and comprehensive approach, because your hiring team will personally ensure that each candidate is represented fully and accurately.


However, the manual nature of this approach can make it very time consuming. When a recruiting team is already on a time crunch or stretched thin, this relying on recruiter ID data can add to the workload. At Ashby, we often see customers use this approach for later stage candidates (e.g. only Offers/Hires) where they want the most details on someones demographics.

### Inference

The third way to collect demographic data is using inference, where your hiring tool estimates the demographic information of the candidates who did not otherwise supply it. This data comes from census information and uses applicants’ names to try and fill in their gender and ethnicity.


The downside to this is that it isn’t perfect (Ashby's version is about ~80% accurate). The upside is that it can be applied to all candidates (including all of your historical data!) Because of that, for most teams, this is a very valuable data source to add in addition to Candidate or Recruiter ID.

### Selecting your starting point

So which starting point is right for you? That depends on your needs and your team - one is not always better than another. If you have time to devote to it and need high accuracy, recruiter ID is your best bet (as mentioned above, we often see this focused on later stage candidates.) If you want a high degree of coverage and would like to review your historical performance, algorithmic inference will help a lot.


Don’t be afraid to hybridize! You can start with inference data and add candidate or recruiter ID later. Hybrid approaches tend to be the most effective, as one method can cover gaps left by another.

## The most impactful DEI metrics

Now that you’ve started gathering data, you can dig into your performance. As we go forward, keep in mind that it’s not realistic to get all you need to know at once. Data improves and develops as it grows in volume over time. Furthermore, this information is a diagnostic tool. It’s all *quantitative*, or number-based data. To completely understand your DEI initiatives, you’ll need *qualitative* data, which will give you more specifics on how real people feel about your hiring process.


All this is to remind you not to grow discouraged if you start on DEI reporting and don’t see high volumes of perfect data in one week. Give it time, keep working on it. This is one of several tools, and you’re already off to a great start by having it set up.


With that out of the way, let’s look at the DEI metrics we recommend tracking.

### Percent of hires from underrepresented groups

The first metric we’ll look at is percent of hires from underrepresented groups. To have an inclusive frame of mind, approach this metric as “more of X” rather than “less of Y,” i.e. you want to hire *more* women and nonbinary applicants, not *fewer* men. Track this metric both overall and by department to get a more comprehensive look at your company’s diversity standing.


When setting hiring goals, reference the distribution of the current market. If 24% of engineers are women, aiming for your engineering department to be a 50/50 gender split is going to be challenging, but aiming for 30% female hires is more attainable. Aim to set ambitious but realistic goals and do it with intention.

![statistics of percent of hires](/images/percent-hires.png)


You need to track hiring percentages not only to see who you’re hiring, but to help you make sense of our next metric...

### Conversion rates sliced by demographic data

Look at conversion rates from stage to stage. You want this to remain fairly consistent from one stage to the next across different underrepresented groups. This is an extremely important metric, as it’s a good way to spot problem areas in your hiring process. You may find that you begin with a more diverse range of candidate than you end up hiring, and that’s worth examining closer.


If you notice a big drop off in any of the groups you’re tracking from one stage to the next, that’s a sign that something exclusionary might be happening at that stage. Take time to investigate that stage and the source of the drop. Just like we mentioned at the start of this section, conversion between stages is an area where metrics can tell you that a problem exists, but only qualitative data can tell you *why*.

![passthrough rates by gender in Ashby](/images/passthough-gender.png)

### Percent of initial screens with diverse candidates

We recommend tracking the breakdown of your pipeline at the initial screen stage. This metric can be tracked nicely over time, making it a good indicator of success in creating a more diverse pool of candidates at the top of your funnel.

![bar graph of gender at screening in Ashby](/images/gender-screen.png)

As with your final hiring metrics, look into industry numbers to get an idea of what goals you should set. Industry distributions are always a good place to start.

### Percent of candidates sourced from different demographics

Finally, take yourself all the way to the top of the funnel to examine the percentage of candidates sourced from different demographics. You may find that a lopsided hiring system begins further back than you think, which is a sign that you need to change where and how you advertise your job postings and source your candidates. Revisit your job posting language to spot hidden biases, and try new job boards to expand your reach to populations that are underrepresented at your company.


A great way to further improve this metric is by tracking your job marketing campaigns. If you notice a spike in the types of candidates you’re looking for, check what campaign you were running at the time to see what worked.


Be especially aware of sourcing and internal recommendations. If you repeatedly dip into the same pool of people, your applicant diversity will stagnate very quickly.


A lot of our customers intentionally focus their sourcing outreach on candidates in underrepresented groups. That’s generally a very effective way to increase the diversity of your overall talent pool.

![image of a pie chart of various candidate racial and ethnic backgrounds](/images/percent-sourced.png)

## More to keep in mind as you implement

Of course, numbers don’t tell the whole story. You could write a book about making your hiring better and more inclusive ([and many people have](https://teambuilding.com/blog/diversity-inclusion-books)!) You’ll need to be on the look out for several other things in order for your investment in your DEI metrics to pay off for everyone.


Making these improvements is going to take time. You shouldn’t expect results overnight, and even setting up the analytics is going to take some time to do right. That means that you truly need buy-in from everyone involved. The executives at your company need to be as invested and as patient as your recruiting team. Get out ahead of any issues by presenting DEI metric tracking as a worthy time investment from the start, so that everyone is on the same page before you find yourself caught up in the process.


Focusing on improving your DEI metrics will come with tradeoffs. You may find that, when you dial in on metrics like improving stage to stage conversion rates for certain demographics or increase the percentage of underrepresented groups you hire, other metrics, like “time to fill” might go up. Remember that this is part of improving your overall hiring system for the long term. Because of these tradeoffs, buy-in from all levels is once again vital.


If your company has been around for a while, you may be using unofficial metrics to track diversity and inclusiveness. Now is a good time to revisit those. If your guidelines are particularly outdated this is the perfect time to toss them out and start fresh. The datapoints we’ve outlined above are going to be more fair, accurate, and definite than vague rules of thumb.

## Ready to begin?

There’s no need to fear the numbers. Too many great companies hold themselves back from tracking DEI metrics because they’re nervous about not doing it right. Success is going to look different to different companies, and there are multiple types of diversity to consider in hiring. Don’t let that overwhelm you! Instead, let it empower you: everyone needs to start somewhere, and right now is the best time to do it.


Tracking your DEI metrics is the first step in a much larger process of making your business a more diverse, inclusive, equitable, and welcoming place to work. We hope that this guide will help you take on the challenge!


If you found this article helpful, bookmark it, then [subscribe to our blog](https://www.ashbyhq.com/blog/all#newsletter-form) for future recruiting insights, stories, and how-to’s.

You know it's vital to always work towards improving your company's diversity, equity, and inclusion - but do you know the best way to start tracking it?

How to Track and Improve Your DEI Hiring Metrics

Shannon Ogborn

A job description often calls for years of experience in a particular role. But, frequently, I’ve found that those role titles don’t have as much to do with the skills needed for the job as they sound. This often bars excellent candidates from the pipeline. Luckily, it’s a problem with a fix.

When you calibrate with hiring managers, focus on the true minimum requirements. What does a role actually entail? What “requirements” are really just nice to have? What are the competencies required to do the job well? Looking for the same minimum requirements across the board helps keep the whole process more equitable, and it gives sourcers more freedom. 

Of course, you won’t move a profile forward if they don't meet the minimum requirements. But when you’ve thought critically about the true minimum requirements, you can find someone who’s met those bars in non-traditional ways. 

If you want someone with a year of software engineering experience, maybe that could be updated to say “or technical experience or coding.” This will broaden the requirement to include folks from less traditional backgrounds. They could nail the interview, they could be the best performer on the team, but unless you think critically about what the requirements are, you are counting that person out before they can even be considered.

This type of calibration includes more people, invites more diversity of backgrounds, and helps you create a team capable of true innovation.


Are you relying on years of experience, or something deeper?

What Are Your True Minimum Requirements?

An excellent outreach strategy requires a screen-in mindset.

A screen-out mindset is where you look at a candidate profile with the framing: *“What about this person does not meet my criteria?”*

A screen-in mindset is where you look at a candidate profile with the framing: *“What about this person would match or add value to the gaps that we have right now?”*

Instead of trying to eliminate people who fall short of the ideal profile, I'm trying to find reasons people would qualify. Screening-in helps a lot with diversity and really increases that diversity pipeline. Part of why I do that is because I’m never looking for the “perfect” candidate.

> I once hired an engineer who had been an analyst for several years. He had no formal software engineering background. But I noticed that he’d done engineering coursework in college, along with a few other traits that really fit the role.
> 
> He performed the best on the interviews of any candidate I ever put through. Had I been looking for the perfect person, I would've missed out on the best fit.

Screening-in helps recruiters challenge our own biases without lowering the bar for excellence. It gets rid of arbitrary barriers, like specific role titles, or only hiring for specific companies, while focusing on the skills needed to actually do the job.

Starting from a place of screening-in can change your entire outreach mindset. If you want a better top-of-funnel, start there.


An excellent outreach strategy requires a screen-in mindset.

Screen-In vs Screen-Out Mindsets – There Is A Right Answer

Laura Li

Looking to break out of the LinkedIn bubble? Ashby’s consulting team has put together this list of sourcing locations you might not have thought of.

1.  Skill-relevant Slack communities

2.  MeetUp communities
    
3.  Github, Dribble, and other coding websites
> **Break-In Talent** If you’re open to hobbyists, you come across gems of talent that aren’t full-time engineers, but would like to be.

4.  School websites
 
5.  “First 50” groups
> **Kicking Off With a Team** If you’re hiring for an early-stage startup, there are many people who want to get in on the ground floor - first 50 groups will help you find them.
    

6.  Programs for under-represented populations
> **Great Groups** Identity-specific schools, clubs, bootcamps, and classes are a great way to source great talent from specific populations.

7.  Hackathons
    
8.  Quora
    
9.  Gyms and fitness studios
> **Go Where The Talent Is** If you have a role that requires heavy physical work an ad at a gym might do some “heavy lifting.”

10.  eSports tournaments
    
11.  Relevant subreddits
    
12.  “Jams”
> **Coding and More** While “code jams” were once the purview of just engineers, “jams” have expanded into all kinds of roles and areas of expertise.

13.  Message boards and interest groups for role-related certifications
    
14.  ResearchGate
> **True Experts** Need to hire for a scientific or research-focused role? ResearchGate is often called “Facebook for academics.”

15.  Skill, job, or interest-related Facebook groups
    
16.  College cafes for new grad roles
> **More Than Career Fairs** You’ll find students about to enter the job market in many campus-adjacent areas. An old fashioned posting on a coffee shop tackboard is a great start. So is checking to see if the campus has a career center that shares open job listings.

17.  Facebook career pages in the local market
    
18.  Specific interest meetups
> **Think Beyond Role-Focused Meetups** What does your ideal candidate do for fun? You might find excellent engineers at a robotics club or great content marketers at a writing workshop.

19.  Industry or skill-related panels and speaking events
    
20.  Running an ad in an interest-specific newsletter

We've put together this list of sourcing locations you might not have thought of - and we're updating it regularly!

Ashby’s “Less Obvious” Sourcing List

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 Bryq

Ashby Has Partnered with Searchlight

The Hiring Memo - a Tool for Managing Complex Interview Debriefs

The Straightforward Guide to a Successful Data Rollout

Detecting Node Event Loop Blockers

How to Track and Improve Your DEI Hiring Metrics

Snippets

What Are Your True Minimum Requirements?

Screen-In vs Screen-Out Mindsets – There Is A Right Answer

Ashby’s “Less Obvious” Sourcing List

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 Bryq

Ashby Has Partnered with Searchlight

The Hiring Memo - a Tool for Managing Complex Interview Debriefs

The Straightforward Guide to a Successful Data Rollout

Detecting Node Event Loop Blockers

How to Track and Improve Your DEI Hiring Metrics

Snippets

What Are Your True Minimum Requirements?

Screen-In vs Screen-Out Mindsets – There Is A Right Answer

Ashby’s “Less Obvious” Sourcing List

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