Abhik Pramanik

Culture

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


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


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


How Thoughtful Communication Makes Us Unreasonably Productive

aronow.io

Astronomer

Attentive

Aven

Benchling

Boulevard

Brightline

Brigit

Calm

Census

Clever

CloudTrucks

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

Coder

Cohere

Cointracker

Color

Costanoa Ventures

Decimal

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

Deel

Deepnote

Deliveroo

Dune

Duolingo

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

EightSleep

Figma

Format One

FullStory

Juni

Linear

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

Marqeta

Modern Treasury

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

Monte Carlo

Notion

Opendoor

Plato

PostHog

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

Pragma Platform

Pulley

Ramp

Readme

Replit

Scratchpad

Sift

Snyk

Sourcegraph

Stytch

Talentful

Treasury Prime

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

VanMoof

Veev

Verkada

WeTransfer

Zippin

Engineering

Recruiting

Product

Benjamin Encz

<HeroImage>

![wellfound hero](/images/mathison-integration-2.png)

</HeroImage>

<ColumnLayout>
<Column growAmount="2">
<Date>November 2022</Date>
<MultiTonedHeader>
<Tone color="primary">Ashby Partners With Mathison</Tone>
<Tone color="muted">To Offer Additional DEI Sourcing And Training</Tone>
</MultiTonedHeader>

### Leverage Our Integration With Mathison To Support Your End-To-End DEI Goals.

## Integration Information

Mathison complements Ashby’s inferred data and analytics products with analysis and recommendations for additional candidates to broaden the range of profiles your team can calibrate against. Mathison works with Ashby by pulling from skill and training analysis, and does bias scanning of job descriptions and job boards to help flag bias language. Mathison can also support your team with training and how-to guides.

</Column>
<Column>
<CompanyProfile name="Mathison" websiteUrl="https://mathison.io/" websiteLabel="mathison.io" align="raised"
  description="Mathison is an all-in-one Diversity, Equity, and Inclusion (DEI) Operating System that builds your action plan, mobilizes your employees, and measures your ongoing impact."
>

![mathison logo](/partners/mathison_wordmark.png)

</CompanyProfile>
</Column>
</ColumnLayout>

<FeaturedQuote authorName="Arthur Woods" authorTitle="Co-Founder Mathison" companyName="Mathison" 
  text="As employers, many people still have a very narrow definition of what diversity itself is. That largely limits our ability to be inclusive in our efforts, because it hinders our ability to actually support every community.” Arthur told us that they combat this by zooming out for a big-picture approach. “Our model is to embrace a much more holistic definition of diversity.">

![arthur-woods](/images/authur-woods.png)

![mathison logo](/partners/mathison_wordmark.png)

</FeaturedQuote>

<ColumnLayout>
<Column>

### Hiring diversity

You’ll be able to more easily source underrepresented candidates and connect them to your open roles in Ashby.

</Column>
<Column>

### More data insights

Mathison adds another layer of data you can process and visualize in Ashby Analytics.

</Column>
<Column>

### Easy integration

This is an out-of-the-box integration, meaning customers of both Mathison and Ashby need only connect the two with an API key. Learn how [here](https://www.notion.so/Mathison-ef81e09f8922473b870d34eeb9aa8316)!

</Column>
</ColumnLayout>

<Spacer size="small" />

<Callout>

<ColumnLayout>
<Column>

## Community Benefit

Ashby customers receive a 20% annual discount off Mathison, 1 free month trial, and 1 custom session with a Mathison Expert.

</Column>
<Column>

</Column>

</ColumnLayout>

<CalloutLink url="https://www.mathison.io/partners/ashby" >Learn more here</CalloutLink>
</Callout>

Leverage Our Integration With Mathison To Support Your End-To-End DEI Goals.

Ashby Partners With Mathison To Offer Additional DEI Sourcing And Training

<HeroImage>

![wellfound hero](/images/wellfound-hero.png)

</HeroImage>

<ColumnLayout>
<Column growAmount="2">
<Date>November 2022</Date>
<MultiTonedHeader>
<Tone color="primary">Ashby partners with Wellfound</Tone>
<Tone color="muted">to improve your reach to the candidates you want to find while saving hours each week.</Tone>
</MultiTonedHeader>

### Leverage our integration with Wellfound to post new listings to the Wellfound job board in a single click while managing candidates within Ashby.

## Integration Information

Our out-of-the-box integration makes it possible to automatically export jobs from Ashby into Wellfound. You’ll then be able to import candidates that apply to those jobs in Wellfound back into Ashby.

</Column>
<Column>
<CompanyProfile name="Wellfound" websiteUrl="https://wellfound.com/" websiteLabel="wellfound.com" align="raised"
  description="Wellfound is the world’s #1 site for matching great tech talent to startups. Job seekers love Wellfound for its niche opportunities and ease of use, while recruiters love it for giving them all the tools they need to connect with top-quality candidates."
>

![wellfound logo](/partners/wellfound.svg)

</CompanyProfile>
</Column>
</ColumnLayout>

<FeaturedQuote authorName="Ben Fahlgren" authorTitle="Senior Mgr, People Ops" companyName="Zippin" 
  text="We love centralizing all of our sourced candidates in Ashby. We're really excited to begin sourcing within Wellfound and having those candidates automatically synced into Ashby. This integration will save our team hours each week."
>

![Ben Fahlgren](/customers/champions/ben-fahlgren.jpg)

![Zippin logo](/customers/profiles/zippin.png)

</FeaturedQuote>

<ColumnLayout>
<Column>

### Streamlined job posting

Post your jobs to Wellfound seamlessly from your Ashby dashboard.

</Column>
<Column>

### Source candidate effortlessly

Source and import Wellfound candidates into Ashby in a single click.

</Column>
<Column>

### 5 minute implementation

Implementation takes just 5 minutes with the basic API key. Learn more about it [here](https://help.angel.co/category/362-ashby).

</Column>
</ColumnLayout>

Learn more about our exciting new partnership with Wellfound in this article!

Ashby Has Partnered with Wellfound

Hiring top-tier engineers is one of the biggest challenges in my role as Ashby’s VP of Engineering. I’ve learned that your careers page - and, more broadly, the way you optimize your website with recruiting in mind - is one of the biggest keys to finding the talent you want.

## What can a job description say?

Ashby was in stealth for a long time, and we had to put a lot of effort into our careers pages because people didn’t know who we were. Aside from the careers page, what else could I tell them about the company before they spoke with me?

I came up with the idea of using our  job descriptions to tell a story.

Every company has some type of role they're thinking about differently than other companies. The first consideration in the job description was how to communicate what makes each role unique. Most candidates half-ignore job descriptions. I thought, “If they're going to read it, I might as well make it something different.” Rather than list requirements and responsibilities, consider: what makes your company and the roles you're designing special?

The second piece is your manager. Your manager makes a huge difference in your job. I wanted to see how to infuse that into job descriptions. How can people figure out who I am and what I'm about?

One of Ashby’s engineers, [Ben](https://www.linkedin.com/in/benasher44/), followed Ashby’s co-founder, Benji, from their previous company. Ben felt that Benji spoke passionately about engineering management. Ben said that most managers felt like they fell into the role, whereas Benji felt like he wanted to change the game when it came to engineering management.

I wanted to find a way to capture that feeling and communicate that leadership strength from the very first contact with a potential applicant. From there I decided to write the descriptions in first person rather than write it as if I'm some corporate entity trying to explain the basics of the job.

![An example of an Ashby job description](/images/job-description-career-pages.png)

I don’t want people to feel like another cog in the wheel at Ashby. I want people to feel the excitement that we have about our work and see the actual projects they would do rather than abstract responsibilities. The career page and the job descriptions are an important piece of that.

Simplicity and using the default structure is your enemy in creating powerful job descriptions and a powerful career page. If you say you need four years of software engineering experience, that doesn't tell anyone what type of experience you're looking for. Instead, think about what you want people to be excited about in the role. Be opinionated so that you'll attract the people who are on board with the way you want the role to work.

## What are candidates looking for, and what are they taking away?

Once you have your job descriptions worked into a form that you like, you’ll find that a lot of the heavy lifting on your careers page itself is handled. From there, you can expand your focus outward to different areas, but you should keep the candidate at the front of your mind as you do.

What are great candidates looking for when they view your career page? When a candidate comes to your careers page, they're trying to understand a couple of things:

1.  Is this something I would want to work on?
2.  Is this a team that I want to work with?
3.  Is this a manager that I want to work for?
4.  Is this a set of leaders that I want to work for?
5.  Does this fit my style of work?
6.  Are these the benefits that I'm looking for?

It’s really just a few big concerns. They want a sense of what the job is, they want a sense of what they’ll gain by working with you, and they want a sense of who your company really is.

Use your careers page to try to answer as many of these concerns as you can as quickly as you can. A lot of job candidates go through the entire recruiting process, really enjoy the company, and then get an offer that doesn't match the band that they're looking for. Or their potential manager's working style isn't a fit. They realize they've wasted so much time. As a company, the more you can pull those questions up front, the more candidates are going to be willing to engage with you. We also use candidate surveys to understand what went wrong and ensure we work that into optimization of our site.

And the more important a concept is to your company, the sooner you should communicate it.

Not every engineer cares about the way they work. They may be very mission-oriented and want to go save the world. That’s fantastic, but that's not Ashby. While we’re not saving the world, we are building a company that cares deeply about its customers and executes exceptionally at making their lives better, and we put a lot of effort into doing that. And we know there are other people out there whose primary goal is to build fantastic software. So that was the perspective we went to, instead of claiming to be something we're not.

On the other hand, if you're a very mission-driven company, you need to lean into it. Focus on communicating how you're accomplishing your mission and why you're going to be the ones that solve it. It boils down to goals.

## Short form content wins

If you want an excellent careers page: drop the idea of a single page. The way I think about it is less about a careers page and more about holistic recruiting marketing. People will stumble upon your website through many different avenues. How is the candidate going through your website to understand more about the company?

When a candidate finds out about you, how will they then navigate to all the content that you want them to read? At Ashby, we wanted to have a steady stream of content about our culture, and we think of that as being under the umbrella of a careers page.
 
As an engineer, I would search for questions relevant to my work and then stumble on personal blogs of engineers who had answers. I wanted to replicate that with our blog. People need to find you. They're not going to go looking for a stealth company by name. But what they are going to do is search for things that are related to their work. And that's where our most viewed form of content came in: [snippets](https://www.ashbyhq.com/blog/engineering), found at the bottom of our Engineering blog, are small bits of things we’ve learned that are helpful in our day to day work. Short form content helps you connect with the outside world.

![An example of the snippets on the Ashby blog](/images/snippets-career-pages.png)

Every channel of communication you use, from social media to paid ads to your landing pages, should work for both your customer and your applicant.

## Other pages to optimize with hiring in mind

Think about where else your website can be optimized for your applicants.

For instance, a lot of small companies start with a team page, but just as quickly stop showcasing it. And then they show their executive team, maybe like one or two people as profiles. But I think your team page is actually super, super powerful. These are the people applicants are going to work with — why not share who they are?

Candidates don’t meet the team right away, but they want to know your team. So I thought it would be really nice to have the entire team just sitting there, available for you to get to know them a little bit more. And it's been huge. Not only do people really read it, they come into our interviews and ask the team questions about their pages. Our team is then answering those questions deeply. It’s wonderful sharing.

What the team does is impressive, so why not show it off?

Another element to seriously consider is your values.

Be opinionated. If you present a set of values like every other company is presenting, you don't differentiate yourself. Instead, think about what makes you different than every other company out there. That could be your mission, the way you work, or something else, but it's what makes your company unique.

One value might be your DEI initiatives. DEI is important to Ashby, and I wrote as much in our job descriptions. I wrote it from a kind of a personal perspective in the style of our job descriptions. Simply including that note has stood out to people from underrepresented groups who are reading these listings, and I do hear it a lot when I talk to candidates. You need to really call DEI out on your career pages if it's important to you.

You also need to avoid platitudes. If your values are to “be kind to each other,” know that everyone says that. What people care about is how you’re actually making that value a reality.

Our [thoughtful communication](https://www.ashbyhq.com/blog/culture/thoughtful-communication) is a good example of that. A lot of candidates have commented that it's actually more powerful than a set of values to them. While we haven't articulated all our values, one of our core values is excellent communication, and that comes through. A lot of companies can say that, but in that article we show candidates how we accomplish it.

## Measuring success

When it comes to measuring success, I suggest you track a few metrics:

1.  How many visitors are you getting and who are they? Here I look for top performing blog posts, understand who is viewing them and then think about other related topics we could expand on.
2.  What are your conversions to final rounds? If someone sees a job description, are they actually applying? Are the candidates applying high quality? If you build all this content, you still have to distribute it, so you want to see what distribution channels are creating quality conversions.
3.  What are people actually reading? How many people actually get from the top of my page all the way to the bottom? If they stop halfway, then I’ll either condense it or switch the content around, because you want people to read it end to end.
4.  What are your paid ad metrics? We've tried Twitter ads before for our job descriptions. We didn't get as much lift as we would like, but we wanted to see how many people would convert from that.

Treat your careers page like a product. It isn’t enough to measure your wins and call it a day. There are many things that adversely impact otherwise great career pages.

## Your listings aren’t for everyone - and that’s good

The fear that you have of being opinionated is that you’ll turn people off. And our opinionated content has turned people off. It’s a good thing. I start my email outreach by sharing our article on how we communicate. Some people love that, but some people find that isn't for them. And that's totally fine, I don't argue. Articles like that are there to help people understand who we are as a culture and how we approach engineering.

The people who aren’t a fit will eventually figure it out. And for us that was through the interview process. I would take the first call and then we'd talk about it and they might say, “Oh, you don't use Slack? This is not a fit.” I'd just wasted thirty minutes of my time and the candidate’s time taking this call.

So it's best to put those differences upfront in order to save your team, your team's time, and the candidates' time.

## Creating career page excellence

The career pages that stick out to me are the ones that are transparent. But PostHog is a notable exception. Our team spent some time with [Cory Watilo, Lead Designer at PostHog](https://www.linkedin.com/in/corywatilo/) to talk about how they approached it.

Their career page has a unique, customized feel that makes it stand out. Every element was designed around the natural flow a candidate would take as they explored the page. Every element is intentional - and communicates either something about PostHog’s culture or something that candidates would want to know about the job.

Cory used Ashby’s API to build and host their careers page, inserting fun moments that, in his words, “spark joy,” like a count of who on the team prefers pineapple on pizza and a spray of digital confetti when you submit an application. PostHog is doing things no other company is trying, and it shows.

<a id="content-download" target="_blank" href="/downloadables/posthog-career-page.pdf" css={{display: "block", fontSize: "$35"}}>Download this PDF to see an in-depth guide of what Cory’s design choices were, and what you should think about when using Ashby’s API to design your own careers page.</a>

Abhik Pramanik, Ashby's Co-founder and VP of Engineering, has mastered the art of creating job descriptions and careers pages that convert amazing talent. He's shared his approach, plus a downloadable guide from PostHog's Cory Watilo on designing a careers page that builds up your brand.

Career Pages | Building Your Employer Brand to Attract the Right Candidates 

Halden Ingwersen

When Daniel Grayson sat down with Ashby, he jumped right in, and we couldn’t start recording fast enough.

“When I was trying to break into tech,” he said, “There was this really intense level of skepticism that potential employers had about my background, particularly around whether I was equipped to think through recruiting issues at scale, because there's a perception that the only people who know how to think about problem at scale are tech companies. And my experience so far is that what I've seen done in industry recruiting, both in my current company and at others, is less deliberate, less strategic, more transactionally focused than anything I ever did in higher education.”  

From the moment he started speaking, Daniel had a lot to say about recruiting, every bit of it valuable. Daniel started his career in higher education, doing admissions for universities before making the switch over to tech recruiting. Academic admissions and recruiting have their similarities. But they also have areas where they drastically differ.  

“How companies decide who's worthy of joining is less strategic, less methodologically sound, less interrogated, and less scrutinized than what we did in education,” he said definitively. “For the most part assessment of candidates and their skills, particularly at the top of the funnel, is an exercise in outsourcing to what everybody else has decided is worthy. So how do you know if someone's strong enough to interview? Where did they go to college? Where did they go to university? Where do they have their graduate degree? What is the assessments that all these other schools make about them, and where else have they worked? They think that *if Google has assessed a candidate and deemed them worthy of a job, they must be strong enough to work here*, rather than relying on your own internal assessments or figuring out how to make a set of assessments at scale.”  

## From higher ed to recruiting ops

As we see so often, Daniel’s path to recruiting wasn’t linear. In college, Daniel planned to become a lawyer, but conversations with active attorneys warned him away. “I graduated," he said, "And really didn't have a plan.” 

He spent the summer after graduation tutoring students at an SAT prep camp, where the head was a college councilor. She suggested that Daniel might like admissions, so he gave it a shot. “I started applying for college admissions jobs, got one and then discovered not only did I really, *really* like it, I was also pretty good at it.” He remained at that job for years, eventually working his way up to much greater responsibilities.  

“I was acting as the product manager for any digital work that we were doing, virtual tours, our website, all these other things, and then eventually started directing international recruitment. And that exercise was really, how do you build relationships with people who will never set foot in your physical space? If you're talking to kids in Vietnam and Nigeria and France, they're not seeing you in person. How do you create the infrastructure that allows these people to build deep relationships with their own aspirations? Across thousands of people all at once? I found that to be really interesting, fulfilling work. I was able build a lot of things there. ”  

It was a puzzle Daniel was interested in solving. But the challenges were about to end. “I got to the end of my eight year run. Year nine was just making the trains run on time, instead of figuring out where the tracks should go. And so I left.”  

He ended up falling back on a set of consulting opportunities that eventually grew into a small solo consulting firm for institutions working with human capital, helping them to operationalize relationships, marketing, and recruiting processes. While he enjoyed the work, consulting fell into much more planning than implementation.  

“I missed the iterative nature of coming up with a plan and then putting it into practice. I knew I wanted to go in-house. I started two years of really core professional networking and knowledge building.” Daniel notes that his first job in recruiting came because the company needed talent enough to hire an untested newcomer. But they gave him a chance all the same.  

Over a year and two roles on the other side of that switch, the things Daniel learned in higher ed come through on the job every day, both in the similarities and the differences.  

“Education recruiting is like highly cyclical,” Daniel told us, “There's a period of time where you're building the relationship. *This is when you're assessing, and this is when you're closing*, and those moments are fixed in time rather than rolling across candidates. Although even then there are universities that do that in rolling sense, but the number of prospects we were cultivating in any given year was in the order of tens of thousands. The number of applications we were receiving and actioning on was in was around 15,000 to 20,000 a year. And we received all those applications in the span of a month and a half or so, and actioned on all those applications in the span of two and a half months.”  

It was a pace that required robust internal processes in order to reach their goals, Daniel pointed out. “We needed systems set up so that we could move through 20,000 applications in two and a half months using just 20 professional staff. The scale of what we did in that space was a lot more intricate and a lot more complex than the scale of what I see in the talent industry. We needed to be able to build relationships with and give them reasons to choose us both pre-close and close. And we need to be able to do that at scale because we were going to be making 3,000 offers, essentially simultaneously, and we'd have a month to offer to those 3,000 people and close about 1,500. So we were closing 1,500 people in a month using 20 professional staff.”  

## Advancing the human capital supply chain

Higher ed recruiting involves a level of operationalization that many tech recruiting set ups simply don’t have. This difference in methodology has directly impacted Daniel’s approach now that he’s in recruiting.  

“If a company worked in manufacturing,” he explained it, “If you're The Gap or Tesla, you're selling physical things to the world. You'll have gigantic teams who are given strategic remits and capital inside the organization to think about how to improve the quality of outputs and reduce the cost of inputs. These are really, really important teams at these companies.” The classic question, for so many of these product-based businesses, is as simple (and yet as complex) as increasing the value of the product while reducing the cost to create and sell it.  

“However,” Daniel went on. “If you work in tech, the only input you have is human. Yet you really can't find a company that thinks about human capital with the level of rigor that Tesla thinks about its supply eye chain.”  

The idea was so radical that the Ashby team took a moment to absorb it before pressing Daniel on why that might be. “Some of that is because it's more difficult to do,” he said. But that wasn't the only reason. “The kinds of people who are typically drawn to work in human resources and recruiting are usually the kind of people who don't like thinking about numbers, they like thinking about people. There's a sense of self-selection in terms of who ends up in those spaces. If you're the kind of person who likes operations and data, there are better paying and more prestigious fields to go into than HR or recruiting. So there's this gap between the level of rigor companies should be bringing to the way they think about people, versus the level of rigor that they have or are interested in using. And that relationship is recursive. Companies don't usually think of people ops or recruiting as a center of strategic excellence, they don't invest in the salaries of people in those spaces.”  

He has evidence for this impression. “In an economic downturn, the very first businesses to get hit are those who provide HR tools because the first function in a company to get cut is recruiting. And before you cut the people in recruiting, you cut the budget for their tooling. And so there's this pretty big strategic gap.” It's a gap that shouldn't be there, and companies would be much better off if that gap was bridged. “I think there's a recursive relationship between who's drawn to the space, what the space is then allowed to do, and then who gets drawn into the space.”  

> You really can't find a company that thinks about human capital with the level of rigor that Tesla thinks about its supply eye chain.

Daniel might have a fix for that. But it’s going to take a radical shift in perception across the recruiting industry.  

## Conventional input, unconventional output

In spite of his wealth of experience, Daniel hasn’t always had an easy time showing others his unique recruiting perspective. The prestige so often associated with academia falls flat in tech - a space where the drive to execute on great ideas is lauded more than time spent in a classroom. Daniel suggests that part of the issue was the perception of academia as a slow-moving, antiquated dinosaur, lightyears away from the “move fast and break things” attitude popular in startups. Over two years, it took Daniel many interviews and more applications before he got his foot in the recruiting door.  

“I worked enough in the business of rejecting other people long enough to know it's not personal,” he laughed. “But I also know that there's a lot of incentive to de-risk in who you hire. If you make a wrong choice in hiring, there are really substantial costs involved in both time and money. And the feeling that I had articulated to me over and over and over again was that the recruiting I did in higher education is not deeply relevant to the recruiting that done in industry.”  

The problem, however, is clear: how do you manage volume and assess risk while still being open to unconventional talent?  

“If you work at a startup, the goal is to achieve an unconventional outcome. And if the only input that you have is human hours you have to manage that through the lens of de-risking. You end up hiring the most conventional people because though the people who de-risk the most.” The paradox stands out. “You're trying to produce this very unconventional outcome by hiring the most conventional people available to you, which doesn't really make a lot of sense to me.”  

It isn’t unfair of recruiters to focus on the elements that they already know work. “You need a way to deal with volume,” Daniel admits. “You have to create some dimension early on in the process that allows you to very quickly weed out a large portion of that volume so that you can focus on something smaller. If you're trying to make one hire, and you have 400 inbound applications, you need a way to triage. The fastest way to triage is look if the company they came from does work that looks like the company that I'm at now. Because if their role aligns, then I can be reasonably certain that the structure of their current work looks like the structure of our current work.”  

But this method cuts out those trying to enter the tech world, including Daniel himself.  

“It's not a criticism of the approach,” he said. “Because it *is* the easiest way to deal with the volume. But it speaks to my point about the level of sophistication I saw in higher education, and how we evaluate candidates and what I see in industry. This is not a sophisticated approach. It's not an approach that allows you to find really powerful minds, really powerful actors who don't look how you expect them to. It exacerbates the DEI problems that exist in tech.”  

Daniel likened the reliance on referrals and tendency to replicate in tech hiring to [survivorship bias](https://en.wikipedia.org/wiki/Survivorship_bias) - an error in which one considers the qualities only of things that made it through a challenge, rather than considering the qualities of things that did not. A compelling comparison for anyone interested in making their recruiting strategy stronger. And it’s linked to the biggest issues that Daniel has observed in recruiting.  

## What are you looking for, really?

“The biggest obstacle I see in recruiting,” Daniel told us, “Is that it's very hard to know what you're evaluating for. Do you actually need a candidate to be good at what can you train quickly? What *can* you train quickly? That's a hard question to answer. And then let's assume that you can answer that question accurately. And here are the skills we need to evaluate, because these are the things that are important to the job, and that we can't train quickly. Now, what's the assessment for that?”  

The problem is already daunting, and it only grows bigger. “Even if you can build that assessment and you build it well, let's make that assumption need hiring managers and people in the company who are skilled at assessing the responses to the assessment. And that's really hard to teach, too!”  

He seemed to realize what a major conundrum he’d presented, and paused for a moment. “This is one of the things that I think makes human capital really interesting as a problem space and, frankly, it's why I'm interested in it. The problem itself is really hard and not easily quantifiable. Data and operations are hugely important, but data and operations are *tools*. They are arrows in your quiver that allow you to solve a problem. They are not the *solution* to the problem. I use Ashby's stuff all the time and there are very few reports, if any, that I can build an Ashby that tell me what the actual answer to a problem is. More often what recruiting data points you towards is what the question you need to be asking is, and then you have to use your own quality understanding of what's happening in the space and your own sense of empathy to find the solution to that problem.”  

That telescoping back and forth between qualitative and quantitative is what makes the recruiting space so challenging, but it’s also why Daniel thrives here. “What do you actually need to be measuring? Can you measure it? How can you measure it? What are you using to measure it? How do we understand the results of the tool we're using to measure it? Each of those things is really difficult to do, and you have to do all of them well in order to construct an interview process that actually gets you what you want.”  

## Learning from higher ed

Recruiting operations has learned so much from sales and revenue, Daniel said. These are industries that have undergone huge changes in the last two decades. “Sales used to be about finding the right most charismatic sales people that you can and allowing them to use brute force charisma to achieve deals. And so many early stage companies, that's the way they approach recruiting. They find a high charisma, brute-force recruiter who goes in and uses that charisma to close candidates.” But it doesn't need to be a brute-force activity when data and analysis could take the field so much further.  

“It’s understanding cohort analysis,” Daniel suggests, “Understanding customer life cycles, customer journeys. Marketing can calculate a customer’s lifetime value. And if you understand customer lifetime value and the factors that go to it, then you can find segments of the market that are cost efficient to go after and acquire. Because if you know what the cost of acquisition is, and it's low enough, and you know what their value's going to be over time, you know, exactly which deals are worth pursuing and which are not. The same thing could be done in recruiting on the op side. Can we assess an employee's lifetime value to the company? Do we achieve a higher employee lifetime value by going after someone who is well-seasoned, who will pop into the role and get bored after a year and a half and go elsewhere, or do we find a higher lifetime value by finding somebody who's junior, bringing them in, having a longer ramp period, training them up, and then retaining them for longer?”  

Though he’s asking big questions, Daniel doesn’t claim to have all the answers. “I actually don't know which of those outcomes is better or worse for which roles at which companies. But neither do the companies in question! But an organization of any real size or scope has a marketing or sales team that understands exactly what those metrics are for the people they target.” So why not recruiting, too?  

“Programs like recruiting acquire debt, the same way that your technology acquires debt, and there are trade offs that you make between long-term vision and short-term gains. And if you optimize for short-term gains over long-term vision, you accumulate more debt. And that's not to say it's a bad outcome, but companies need to be mindful of the system they use and which debts they acquire.” But, Daniel says, companies are making a mistake by thinking they can wait.  

“Lots of companies wait until they get to 150 or 250 people before where they start thinking about what the structure needs to look like in HR and in recruiting,” he said. “If you wait until you get to that size point, you've accumulated a lot more debt than if you start thinking about what that work looks like early. Earlier stage companies, if you believe in your own success and you have enough faith in your own success, then you have to be thinking about your systems. What kind of systems allow for us to have a recruiting engine that supplies itself efficiently, effectively? Well, with high quality, high caliber talent, where our success and failure in this function does not rely on a single person, their historical knowledge, and their individual charisma based ability to close candidates.”  

You can find Daniel on [LinkedIn](https://www.linkedin.com/in/danielgrayson/).  

Enjoyed this article? [Subscribe to our blog](https://www.ashbyhq.com/blog/all#newsletter-form) or read others like it:  

* [Continuum’s Chauncey Brooks on Startups, Recruiting, and What It Means to Find "Good Talent"](https://www.ashbyhq.com/blog/recruiting/chauncey-brooks-interview)
* [Marqeta’s Stephanie Baysinger on Letting Your Recruiting Ops Team Shine](https://www.ashbyhq.com/blog/recruiting/stephanie-baysinger-interview)
* [Mathison’s Arthur Woods on the Right Way to Approach DEI](https://www.ashbyhq.com/blog/recruiting/arthur-woods-interview)

Ashby sat down with Astronomer's Daniel Grayson about the ways academic recruiting has the potential to rock the tech recruiting status quo.

Astronomer’s Daniel Grayson on Why Academic Recruiting Can Be Tech Talent’s Secret Weapon

Emma Cushman


Shipping is scary. 

Doing our jobs as engineers requires going to work every day and pressing a big green button that could, in principle, break everything. For Ashby to succeed as a company, we must press that button as often as possible.

The systems we employ to make pressing that button safe — static types, automated tests, code review, et cetera — weren't invented here. They are the legacy of decades of software engineers who made terrible mistakes, learned from their failures, and documented what they learned to build a safer environment for all of us.

Ashby's postmortem process is crucial to continuing that legacy of improvement through failure. But just as importantly, our collaborative and blameless postmortem culture also helps us feel safe, knowing that we'll have the team's support when something inevitably goes wrong. Together we'll work through the problem, understand what failed, and build resilient systems that will stop it from happening again.

Google's [SRE Book](https://sre.google/sre-book/postmortem-culture/) summarizes the basic concept of a blameless postmortem: "A postmortem is a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring." If you've worked as an engineer, you're undoubtedly already familiar with this idea.

In this article, I'll talk about the collaborative postmortem process we use: 
1. How we organize postmortems across time zones
2. How we decide who should run a postmortem (and when)
3. How we apply blamelessness to root cause analysis
4. Where we still have room to grow

## Postmortems Are Living Documents

At Ashby, a postmortem is a document created in our internal wiki (we use [Slab](https://slab.com/)), after resolving an incident. It serves as a record that outlines the nature of the incident and provides a timeline of relevant events. It is also the central location for collaborative discussion of the events, root cause analysis, and any learnings or next steps.

Our postmortems live in shared documents. This allows us to contribute to the timeline and evidence collaboratively and use comments to tag participants and discuss root cause analysis. Collaborating through a document helps us avoid costly meetings while ensuring that every stakeholder has a chance to contribute to the process —even those working asynchronously from a different time zone. (For more on our collaborative philosophy, see [How Thoughtful Communication Makes Us Unreasonably Productive](https://www.ashbyhq.com/blog/culture/thoughtful-communication)!)

To kick off the postmortem process, an engineer starts by making a copy of our postmortem template. They'll gather initial evidence, fill out a basic timeline, and tag any participants in the incident. Then, they send the draft around to the team. From there, we work asynchronously to complete the timeline, ask the questions necessary for root cause analysis and document any learnings or next steps.

Once we identify next steps, each one is ticketed as a GitHub Issue and added to our Postmortem Action Items GitHub Project. Then, we link each ticket from the postmortem document to easily see that everything was ticketed. The tickets go to an engineering manager to triage, prioritize, and assign. 

Quick fixes, such as adding a lint rule or a DataDog monitor, are often performed throughout writing the postmortem as soon as they're identified. Often these were already done during the incident response. In that case, we note that the task has already been done and does not need to be ticketed.

## Postmortem Owner Rotation

Who's responsible for doing all that? Ashby's flat organizational structure and focus on autonomy help us move faster with fewer resources than our competitors. Still, it presents a problem for postmortem analysis: we don't have a dedicated SRE team that can afford to investigate and document every incident. To write a postmortem, some engineer needs to take on the task.

In the early days of Ashby, this would often mean the engineer "responsible" for the incident would write up the postmortem. There are a few issues with that habit:

1. To know who should write the postmortem, we need to know what caused the incident. But determining the root cause of the incident is the purpose of the postmortem!
2. These postmortems would often start with a lot of "I" statements: "I shipped commit ead673a", "I misunderstood the documentation," and so on. "I" statements go against the basic tenet of blamelessness, as noted in PagerDuty's [The Blameless Postmortem](https://postmortems.pagerduty.com/culture/blameless/?utm_source=google&utm_medium=cpc&utm_source_platform=gads&utm_campaign=Global-Tr-FreeTrial-PdSrch-Google&utm_creative_format=dsa-tryitfree&utm_content=guides_dsa-1664588210868&utm_term=&matchtype=&network=g&utm_device=c&utm_marketing_tactic=dsa&gclid=Cj0KCQjwrs2XBhDjARIsAHVymmSafg6AQ-wXyiDX1JbzqmQv1MXnSwjLj6d6LmW_njoIReGA6jPmBhcaAiRNEALw_wcB): "The goal of the postmortem is to understand what systemic factors led to the incident and identify actions that can prevent this kind of failure from recurring. A blameless postmortem stays focused on how a mistake was made instead of who made it."
3. We take pride in the quality of our work, and when we ship broken code, it's natural to feel some guilt and personal responsibility for the consequences. Being responsible for organizing the postmortem adds a burden to the person who is already most psychologically affected by the incident. As the [SRE Book](https://sre.google/sre-book/postmortem-culture/) writes: "Writing a postmortem is not punishment —it is a learning opportunity for the entire company."

To address these issues, we decided to switch to a round-robin system for distributing postmortem ownership. When an incident happens, the next engineer in the rotation is responsible for gathering initial evidence, creating the Slab document, and facilitating collaboration and root cause analysis within the team. That helps us distribute the load of organizing postmortems while also engaging more engineers in the postmortem process. 

That has a few additional benefits. For one, it helps us combat confirmation bias —["the tendency to look for and favor information that supports one's own hypothesis"](https://www.infoq.com/articles/postmortems-etsy/). For example, in one recent incident, the on-call engineers noticed suspiciously timed anomalies in our Postgres metrics and concluded that a database issue was likely the culprit. Other evidence supported that theory. During the postmortem, another engineer discovered that the root cause was a network split in our Redis provider, and the database issue was completely unrelated. Often a theory of the root cause is built by first responders during triage, and having a third party reevaluate the sequence of events with fresh eyes can be invaluable.

Furthermore, involving more engineers helps us share knowledge, including specific information about our infrastructure and basic SRE skills. That helps us prepare for future incidents and enables any engineer to help during a response to an incident. The more skill we spread across the team, the better.

## When to Write a Postmortem

Each postmortem involves several engineers gathering evidence, analyzing, and assigning follow-up tasks. We want to reserve postmortems for serious and complex incidents that warrant the investment of engineering time. At Ashby, we don't formally assign a severity level to incidents (unless it's a security incident, which involves the security team and has its own SLA). For incidents that don't have security implications, any member of the team can request a postmortem for an incident. We use some guidelines to help determine when we'd generally want to write a postmortem:

* Incidents that involve loss (or potential loss) of customer data
* Incidents involving substantial or long-lasting degradation of core features, or any app downtime
* Incidents that block key workflows for multiple customers
* "Incidents" that turned out to be false alarms but still paged or caused extra work for the on-call engineer

When a postmortem isn't warranted, we still encourage engineers to write retrospective documents and distribute learnings to the team. However, out of respect for the postmortem process, we consider these documents "Retrospectives" rather than "Postmortems." The word choice makes it clear to everyone when we follow our exact postmortem process.

## Root Cause Analysis

A good root cause analysis should answer the question, *What could we change to prevent a similar incident from happening in the future?* The answers to that question become our follow-up tasks.

We often start our analysis with the [Five Whys](https://en.wikipedia.org/wiki/Five_whys): after answering each question about the incident, ask "Why?" again until you arrive at a root cause. However, we're also sensitive to the tendency for such a linear series of questions to terminate at "first stories," i.e., stories revolving around human error. As John Allspaw writes in [The Infinite Hows](https://www.oreilly.com/radar/the-infinite-hows/):

> "When it comes to decisions and actions, we want to know *how it made sense for someone to do what they did*. And make no mistake: they thought what they were doing made sense. Otherwise, they wouldn't have done it."

So, we don't strictly follow any formal approach. Instead, we ask open-ended questions that seek diverse narratives, digging into the superficial causes of a problem to find the systemic or procedural failures which allowed the problem to become as serious as it did.

Finding the root cause is always a collaborative process. We help each other to arrive at a deeper understanding of the incident by being curious, asking good questions, and using blameless language that allows engineers to acknowledge their mistakes comfortably.

## Blameless Language

Since the purpose of a postmortem is to build better processes, focusing on the actions of individuals can be distracting at best. At worst, it can make engineers feel unsafe when making changes to the codebase or taking decisive action in an emergency.

To combat this, we make a deliberate effort to use blameless language in a postmortem. That means using language that implicitly assumes the good faith of all participants and focuses on failures of systems and documented processes rather than the actions of individual engineers.

In particular, the body of the postmortem never contains the names of individual engineers. Instead, we keep a list of people involved in the incident in a separate *Participants* section. Rather than saying "@person shipped 2aab2c9", we say "2aab2c9 was shipped". The difference may seem inconsequential —anyone who cares can look up which engineer shipped 2aab2c9. But it can make a big difference to that engineer and help them shift from a defensive posture to a collaborative one. 

The goal is twofold: to focus on improvements we can make as a team and provide individuals with a visible sign that their actions will be interpreted in good faith. Using this language tells everyone involved that the team will always support each other in our response to mistakes and emergencies. 

That support is essential for engineers who are early in their careers; shipping a major bug for the first time can shatter the confidence of a new engineer, severely hurting both their productivity and well-being. Careful language choice makes it natural to reframe their mistake as a learning opportunity and can even build their confidence to take measured risks in the future.

## Room to Grow

Like everything at Ashby, our postmortem process isn't set in stone, and we're constantly updating it in response to feedback from stakeholders. For example, our QA team recently communicated that it wasn't always obvious which issues weren't purely infrastructural and could have been prevented by improvements to our QA process. To help, we've added a section to our postmortem template that describes how the incident manifested to users.

One major ongoing work in progress is how we prioritize issues from past postmortems. Usually, the most urgent improvements are made by participants during the postmortem process, if not during the incident itself. Less urgent issues are often moved to product area backlogs to be addressed by individual teams according to their bandwidth. 

But many issues uncovered during postmortems are things that aren't critical *today* but will likely become urgent or even dangerous in the future —maybe after we scale or make a planned migration to a new piece of infrastructure. For those issues, keeping a close eye on them, and allocating the right resources at the right time, is crucial to preventing incidents. That's a part of the process we're still working on getting precisely right.

## Impact

Before formalizing this process, our postmortems were conducted ad hoc and inconsistently. Whether we wrote a postmortem and documented (and completed) follow-ups varied greatly depending on who was involved in the incident.

As a result of a more consistent process, we've implemented many improvements to the systems that protect us from our own mistakes —improvements to developer experience, CI, infrastructure, documentation, and more. At the same time, our blameless culture has provided comfort and psychological support to several engineers who have gone through the rite of passage of shipping their first major bug and being at the center of an incident. 

Shipping is scary. It won't ever be entirely safe to push that big green button. But at Ashby, we're always working to make it *feel* a little bit safer.

## Appendix

### "Blamelessness" in Aerospace and Medicine

The origins of the concept of a "blameless postmortem" are well known in engineering lore, as the [SRE Book](https://sre.google/sre-book/postmortem-culture/) states: 

> "Blameless culture originated in the healthcare and avionics industries where mistakes can be fatal. These industries nurture an environment where every "mistake" is seen as an opportunity to strengthen the system. When postmortems shift from allocating blame to investigating the systematic reasons why an individual or team had incomplete or incorrect information, effective prevention plans can be put in place." 

However, it's worth noting that the concept of "blamelessness" applied in aviation and medicine differs from what we practice: mistakes often have personal consequences. 

The National Transportation Safety Board, or NTSB, conducts a [detailed investigation](https://www.ntsb.gov/investigations/accidentreports/Pages/Reports.aspx) of every aviation accident in the United States, and their reports and recommendations are widely credited for the incredible safety record of US airlines. But where human error is a factor in an accident, [it's fairly common](https://www.govinfo.gov/content/pkg/GAOREPORTS-T-RCED-98-253/pdf/GAOREPORTS-T-RCED-98-253.pdf) for the FAA to revoke or suspend that individual's license to operate an aircraft. 

Likewise, in medicine, where the term "postmortem" has a literal meaning, the role of human error is more nuanced. Preventing future mistakes is essential, but so is punishing negligence or wrongdoing: 

> "Although a culture that does not place blame was a step in the right direction, it was not without its faults. This model failed to confront individuals who willfully and repeatedly made unsafe behavioral clinical practice choices. Disciplining health care workers for honest mistakes is counterproductive, but the failure to discipline workers who are involved in repetitive errors poses a danger to patients. A blame-free culture holds no one accountable and any conduct can be reported without any consequences. Finding a balance between punishment and blamelessness is the basis for developing a [Just Culture](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5424837/)."

As with most software engineering teams, the stakes at Ashby are never life or death. These low stakes allow us to lean into a radically blameless culture that prioritizes psychological safety, risk-taking, and high velocity. Mistakes are an acceptable tradeoff for shipping more code faster.


How Ashby's collaborative postmortem process adapts industry best practices to a global, remote team and helps us move faster, learn from failure, and build a healthier engineering culture.


Async Postmortems in a Global, Remote Team

Did you know that Ashby is partnered with [Glassdoor](https://www.glassdoor.com/index.htm)? Glassdoor is the website for insights, reviews, and all the intel to help job seekers find the right company for them.

This integration allows you to post your Ashby-powered job listings directly to Glassdoor’s jobs pages. It’s fast and easy to do, saving you time and clicks.

Learn more at [Ashby University](https://www.notion.so/Indeed-Glassdoor-fcbbad0082e24d92ae08866703940ab3).


Ashby has partnered with Glassdoor to connect you to their jobs page quickly and easily.

Ashby Has Partnered with Glassdoor

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 Partners With Mathison To Offer Additional DEI Sourcing And Training

Ashby Has Partnered with Wellfound

Career Pages | Building Your Employer Brand to Attract the Right Candidates

Astronomer’s Daniel Grayson on Why Academic Recruiting Can Be Tech Talent’s Secret Weapon

Async Postmortems in a Global, Remote Team

Ashby Has Partnered with Glassdoor

Snippets

Continous Deployment via a GitHub Actions Reminder

Type Safety with ES2022's Array.prototype.at

Querying JSON and XML with jq and xq

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

Testing Using Jest Table Syntax

Using Generic Arrow Functions in .tsx Files

Product

Resources

Company

Developers

Ashby Partners With Mathison To Offer Additional DEI Sourcing And Training

Ashby Has Partnered with Wellfound

Career Pages | Building Your Employer Brand to Attract the Right Candidates

Astronomer’s Daniel Grayson on Why Academic Recruiting Can Be Tech Talent’s Secret Weapon

Async Postmortems in a Global, Remote Team

Ashby Has Partnered with Glassdoor

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