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

Halden Ingwersen

Like many talent professionals, Chauncey Brooks didn’t set out to be in talent. Having recently graduated from college, his biggest goal was avoiding an office job. This led him to manual labor jobs, where connections with his co-workers, many of whom were immigrants, developed a passion for immigration politics and law. He found himself at a law firm in San Francisco, there to fight the good fight, helping people secure asylum .  
  
It wasn’t quite the work he thought it would be. Here he was, in the office he wanted to avoid, mostly filling out H1B paperwork for major companies like Cisco and Yahoo. “Second day of the job,” he told Ashby, “I was thinking, oh shoot, I've made a huge mistake.” 
  
A year into gritting his teeth to force through a job that wasn’t for him, a door opened in the form of a friend inviting Chauncey to join him at Google. Though he wasn’t sure if Google would be any better of a fit, he went out on a limb and applied, and that’s where things began to change.  
  
Google’s recruiting process was intense, and the pressure only ramped up once he was hired. “On day one, they put you through bootcamp,” said Chauncey. He and twenty others in this incoming professional class studied under heads of talent from various companies who taught them about everything from what code really is to sourcing effectively to a deep dive of Google’s business model.  

> "A lot of what the recruiter's job is is understanding what does the company need?"
  
The bootcamp took people with an aptitude for recruiting and showed them the fundamentals of the craft. “I loved it,” Chauncey said. “I loved the sales aspect of it, the technical aspect of it, the technology aspect of it. It was so different from what I had grown up thinking of as work.”  
  
Since his Google bootcamp days, Chauncey has worked for small ad tech companies and industry giants like Stripe and Slack. Through it all, he’s sought the very thing he was taught to source at Google: the elusive idea of good talent.  
  
Chauncey was quick to elaborate on what exactly good talent looks like - now and over a decade ago. “The way that we and the companies now think about talent is much more dynamic and fluid than it was when I was going through this program in 2007. They were teaching us on a very blunt basis, a lot of it ended up being about lists. They trained us in how to spot a good resume, but in doing that they had a list of companies they liked, a list of schools they liked, and those were treated as signals. If they got out of the good school, that's a signal. If they got into a graduate program, that's another signal. If they worked at McKinsey, that's another signal. It was on a very calculated level where they basically taught us to think in terms of an algorithm for each role. But that's changing. Nowadays I think we realize that's quite exclusionary. The person who got to go to Harvard and work at GE and Google probably came from quite a privileged background.”  
  
Realizing this, Chauncey said, has made him into a better recruiter. But though the inputs have changed, the process he’s using and the way he thinks about recruiting has remained. “It doesn't mean that the person who did those things is not still good talent, but it means they're good in one axis. While the person who put themselves through school and got an associate's degree and then went into the military, that is a very different kind of path, but in many ways it tells you much more about them than the person who simply cleared gates in a more traditional or linear career.”  

## On "good talent"  
So which one is good talent? They both are, but, “A lot of what the recruiter's job is,” Chauncey went on, “Is understanding what does the company need? How does the company think about talent and how do I translate that to looking at someone on paper and determining if they've passed through the crucibles we actually care about.”  
  
After years in the field, and helping to get a startup all about hiring up and running, this has been one of Chauncey’s main takeaways. You can’t prescribe what good talent is, but you can create an effective plan to find it - a plan that looks very different at every stage.  

> "Recruiting is everyone’s job. It never becomes just the recruiting function's job, or just a manager's job - they are there to facilitate it and help it scale.”   

When you’re in the early days, doing Seed or Series A funding, Chauncey tells us that recruiting is everyone’s job (though the share falls heavier on the executive team.) “You need to develop your process and get clear about what your company's bar is," he said. "Get yourself a great recruiting advisor to help you build your process and teach you how to build the company." (Perhaps through Continuum?)  
  
Once your company enters Series B and C funding, and starts truly scaling, that’s when things get serious. “Hire your Recruiting advisor or someone like them,” Chauncey advises. “Scale the recruiting team. Hiring is still everyone's job but Recruiting is scaling and running the process and developing candidates. Build your talent brand and start hiring sourcers and recruiters to build scale.” When you're ready, you can take this even further. “Get an HR or Chief People advisor, and work with someone to develop some quick and dirty compensation bands to get you to the next phase.” This is also the stage to start seriously building out your recruiting operations team, not later.  
  
After Series C, moving towards pre-IPO, you should already have a robust system in place for finding good talent. By then, says Chauncey, “Executives should be focused on hiring amazing executive talent. Bring on a CPO, bring on a recruiting leader that has seen a lot of scale. Hire your comp leader. Then you can scale and start hiring pipelines of talent.”  
  
At this stage there’s a mental shift. Your leaders are no longer hiring for their teams, they’re hiring for the company. And, this far along, there’s no time to waste. “If a candidate meets the bar, get them an offer as soon as possible. You can figure out which seat to give them later.”  
  
We asked Chauncey what else founders tended to miss in their search for good talent. “Recruiting is everyone’s job,” he re-stated. “It never becomes just the recruiting function's job, or just a manager's job - they are there to facilitate it and help it scale.” And what else? “Stop interviewing when you know what you need to know. Be hyper focused on what you need each hired person to accomplish in the next year.” To achieve this, “try to envision a stellar annual review conversation - what are you telling them they did well?” Next, “Until your business has strong product market fit, hire great "general athletes" rather than deep specialists. And make sure they're good, because the caliber of your early talent dictates the caliber of your future talent."  
  
It’s a lot of advice, but founders have a lot to consider when hiring. “Startup hiring is a brawl, Chauncey joked, “not a boxing match. There are no rules except that you better win. So you have to be willing to hustle and do unnatural things to get that win. You don't want to do it all the time, but be clear when you need to break the compensation band or change the organizational structure to accommodate game changing talent.”  
  
One more major part of what makes good talent, that founders need to know, is what kind of company you truly want to build. For instance, a lot of founders will say they want a great engineering team. But Chauncey says that isn’t what they really want. He asks them, “What kind of companies have you worked at, what kind of cultures have you liked? What kind of companies do you look at and say, ‘I love what they've built'-? Saying you want a great team is too easy. A great engineer at Google could be a terrible engineer at a five person company because the mindset and the things you have to do to be successful are so different.”  
  
Instead, Chauncey wishes that more startup founders would start with a vision of their culture. “What kind of culture do these founders want to build? And then you cascade that down,” He said. and after that they can focus smaller. “What are the challenges? What are your headcount plans? Then you can start building things like the talent philosophy and the interview processes. And it’s the recruiting team that all actually builds that up and, and scales it out to be able to accelerate.”  
  
Once again, the value of an amazing recruiter shines through. But being an amazing recruiter takes hard work, which Chauncey has learned all too well.  
  
“I think one of the challenges that I've had in my career is that I'm always either at the biggest job of my life or I'm at the smallest company. Either way, I'm always at the steepest end of my learning curve. I've reported to everyone from the General Counsel, to the VP of engineering, to the CFO, to the COO, and very rarely do people in recruiting report to someone who's actually ever sat in your seat and done your job. And that's interesting, because they give you a lot of leeway to figure things out, but it's also challenging in that they don't usually have answers for you.“  
  
“One of the challenges of recruiting is that you get this place where if everything is high priority, then nothing is high priority.”  
  
Chauncey’s method of tackling that lack of answers might seem dark, but it’s undeniably been effective for him. “I've always sort of tried to think what's the thing I get fired for? If I don't do this thing, they show me the door. You can also think: what are the biggest challenges facing the company and how can I have the most impact on that with one blow? I’ve tried hard to understand what’s top of mind for my boss, what keeps them up at night. Even if it’s totally unrelated to hiring or my job, it helps me to distill to my team what they should be thinking about and what's important for the business.”  
  
These questions are good for more than getting into the boss’s head. “It also helps me to prioritize the work that comes to recruiting. One of the challenges of recruiting is that you get this place where if everything is high priority, then nothing is high priority. Many businesses are bad at identifying the real highest priority things, so it’s up to the recruiting leader to actually decide what that is.”  

## What recruiters should know... and what founders miss  
Other advice for those in recruiting? “I like to be prepared for all meetings,” he said enthusiastically. “I'm one of those people that really likes to pre-read, so I can kind of anticipate where things are going to go and understand how I want to direct things. That really helps in having a strong grasp of the metrics and mechanics of your business, and it lets you answer questions that might be pointy or challenging on the fly.”  
  
“I don’t trust people who don’t have scar tissue... if you haven't failed, it means you didn't try hard enough.”  
  
“There's always deadlines,” he told us. “There's always candidates that say no. To some degree that's just part of a game, and you have to accept that. In my twenties and early thirties, I would just respond to things at all times. But I work at an eight person company now. I'm always either taking care of my kids or I'm working. It's important to have boundaries and a functional process. For me, from five PM to eight AM I'm not available. It doesn't matter if you're the CEO himself, because that's the kid's time. The boundary-setting and compartmentalization helps a lot.”  
  
That doesn’t mean it’s always been easy for him. “At every place I’ve worked, I've made mistakes,” he told us, not quite laughing. “The key thing is: what do you learn from them and how do you move forward? I don't trust people that don't have scar tissue, that haven't failed; if you haven't failed, it means you didn't try hard enough. If Silicon Valley has a problem, it's that people don't talk about their failures enough.”  
  
Failures like risking your job, and the jobs of everyone in your company, for instance. For most people, the boss stopping by your desk to threaten to fire you would be the source of a heart attack. For Chauncey Brooks, it was the source of inspiration.  
  
Just a few years into recruiting, he was doing sourcing work at his second company. His boss at the time, Martin, was a fantastic mentor and leader, but Chauncey noted that he was not especially technical about recruiting, and the numbers were slipping as a result. That was when the CFO came to town.  
  
“We had just landed our series C funding and the company was about to double or triple,” he told Ashby. ”Our CFO was this guy from Google, a real New York City, tough as nails kind of guy. I've had like two conversations with him, ever. He swings by our desk and he leans over and says look, you all miss your numbers every single quarter. If you don't hit your numbers this year, I'm gonna fire everyone on the entire organization. Then he just walks away!“  
  
Some recruiters would buckle under that kind of pressure. But not Chauncey.  
  
“Martin and I grab a meeting room and say, okay, we gotta’ figure this out. At this point we were just two or three people trying to get it all done at a hundred person startup, shortly after the recession. What we realized was that we needed some way to determine what inputs were needed to get to the outputs that we wanted. Prior to that we had a rough finger-in-the-wind approach, approximating sort of what we need to get there. In that meeting we distilled down what we needed and built a timeline. And what we found was that, if we need to hire X a number of people in six months, then that actually means we have to have Y number of interviews and Z number of, of, uh, phone calls. And to do that, we would have to have at least like five recruiters, but they’d have to be already on board now. So in reality we should have hired them six months ago!”  
  
“We presented this and I remember the CFO said: Cool! If you're wrong, you have to fire these people. It was the first time that I really realized how important process and strategy was. I was like, oh. This is real.”  

> "If you haven't failed, it means you didn't try hard enough.”  

Chauncey has carried this lesson over into a much bigger philosophy on strategy and planning as a recruiter. “I don't think many recruiters and recruiting leaders like to truly understand the numbers on a fundamental enough level. I think that is largely because they don't look closely enough at these deep links. The idea that if you get your forecast wrong people lose their jobs. And it's really difficult to do that in a scaled organization that understands its headcount. In a company that has shifting finances and changes their head count plan every six months, it's like landing a plane on an aircraft carrier. That was one of the most instructive experiences in my career in terms of understanding how important it was to actually understand the job that we do and how operational it really was. Before that, I sort of thought of it as oh, I talk to people, I find the best candidate, and then I put 'em through! And then I realized, no, this is math.”  

## The changing world of recruiting  
Like so many recruiters, it was the team and the people that made those failures worth it. And with the future of work looking so remote, Chauncey made a note that those entering the field now we're facing a very different set of challenges than those who came before.  
  
“I think it must be really hard to be new to recruiting right now, because I learned so much being in an office and just overhearing what was going on. At Google we would sit in a pit and listen to each other's pitches constantly, and we would tease each other and compete every morning to see who could do the most outreach. And that was fun and it was energizing. And I don't know if I would've liked this industry if I had not started with something kind of like that. So I do think it must be tough right now. You have to find a way to make it entertaining and fun, and make it into a group sport. I actually got this line from [John Vlastelica](https://www.linkedin.com/in/johnvlastelica/), who's an amazing recruiting guru. He said you run to the fire. Find the hardest thing, the thing that no one wants to work on... and go make it work.”

If you’re interested in connecting with Chauncey, you can find him on [LinkedIn](https://www.linkedin.com/in/cbrooks1/). You can also check out [www.joincontinuum.com](https://www.joincontinuum.com/about) to see how Continuum is disrupting the status quo.

Chauncey Brooks is a talent rockstar who has experience recruiting for Slack, Stripe, Google, and, most recently, Continuum. We sat down to pick his brain about recruiting, founding, and what "good talent" really means.

Continuum’s Chauncey Brooks on Startups, Recruiting, and What It Means to Find "Good Talent"

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

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

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.  


Continuum’s Chauncey Brooks on Startups, Recruiting, and What It Means to Find "Good Talent"

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

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

Continuum’s Chauncey Brooks on Startups, Recruiting, and What It Means to Find "Good Talent"

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

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