Hiring sucks. Here's how we found two exceptional employees. (Part 1)

Written by Andrew Askins

Have you ever had a feeling of pure elation, the kind that makes you literally jump up and fist pump the air?

Have you ever had it immediately followed by a gut check, the kind that makes you feel like gravity just tripled?

It’s a weird combination. In Spring of 2018, I worked on closing three big projects. After weeks of uncertainty, we got word that two of the projects signed...on the same day! Meaning we closed $180,000 in new business in one day.

I literally started dancing. 

Then some serious nerves kicked in. To get the work done, we’d need to hire—something we’d never done before. And we’d have just over a month to do it. 

Hiring is effing hard 

A few things were clear. First, we’d need a job post, and then we’d need to do some interviews. We read a lot of articles, talked with a ton of founders, and had a bunch of friends review our ideas. 

Even then, if I had to sum up the whole process, I’d say this: Hiring is really, really hard. 

It’s difficult to find candidates, and it’s hard to know whether anyone you find is good. And it’s not like you can take a break from running your business while you do all this either. No matter what way you slice it...hiring is a difficult process. 

Searching for a job is no cakewalk either  

Matthias Hager, one of our top candidates, talked about this after we finalized our hires. We didn’t hire Matthias, because we decided to hire locally, and Matthias would’ve been remote. But he still agreed to talk to us about what we did and how it was different from the normal experience. 

He pointed out that in most cases, “Companies have very little incentive to treat you like a fellow human. Doing so takes time and money, so common human courtesies are completely eliminated.” This is totally demeaning and discouraging to applicants. 

He also pointed out some common pitfalls to the typical process for hiring developers:

  • Startups expect applicants to put hours of unpaid work into the process. 
  • Many companies list insane qualifications: 7 years experience for a software product that is only 6 years old. Plus a bachelor's degree. Plus knowledge of half a dozen mostly unrelated software products...all for a "junior" position. 
  • The job description is usually inaccurate and incomplete. 
  • Applicants don’t receive status updates for the position, and they’re left wondering whether they got the job or not.

This isn’t just Matthias’ experience either. He said, “Reading stories from others tells me this is a ubiquitous, ugly affair.” You don’t have to dig deep to find those stories. 

Hacker News screenshot

“How to Pass a Programming Interview” is all about hacking the broken hiring process. With 1020 points and 552 comments on Hacker News, it’s clear many programmers feel strongly about this.

This picture of technical hiring isn’t an encouraging one, and it’s no wonder applicants are wary of postings and the hiring process. But that doesn’t mean your hiring process has to play out in the same way. 

Ours certainly didn’t. 

We made plenty of mistakes, several of which Matthias helped us see, but he said that overall we were, “upfront, straightforward, and...human about the entire process.”

How you hire says a lot about your company culture, by the way

Your job post, how you structure the hiring process, and the way you conduct interviews all say something about your culture. That’s because those steps all involve action from you, the founder. We've written before about how your actions (and the beliefs that drive them) influence your startup’s culture more than anything else. 

Culture definition

Your actions and beliefs—including how and who you hire—have an enormous impact on your startup’s culture.

Beyond that, each new hire has a really big impact on culture. Especially on a small team. Hiring someone is a form of praising them, of saying you value what they bring to the table. Your team is going to pay attention to that.

From the job post to onboarding, be aware what your actions are saying.

Getting started with an honest, interesting, and accurate job post 

Talking about your company is always difficult, and that’s especially true when it comes to hiring. I have lots of insecurities about how we’re not perfect, and overcoming that has been a challenge.

What was hugely helpful during this stage was leaning on friends and mentors. Six different people, who don’t work at Krit, read our original job post and gave feedback. Their input helped me face insecurity and strengthen the job post. Here's what else we learned.

Tip #1: Consider a transparent salary  

Several reviewers thought it was a bad idea to share our salary upfront. They had valid opinions, but we had a clear idea of the role we wanted to fill and what we could afford to pay someone who fit it. Since one of our core values is transparency, this also felt like the right thing to do.

One of our values is transparency

Listing the salary, right there in the job description, was a chance for us to practice the third value on our website.

Turns out, it paid off. Several people told me they found this approach refreshing, and it made the job seem more appealing. I’ll call that a win!

Positive feedback about transparent salary

This kind of response isn’t unique to us. When Fog Creek (now Glitch) posted the salary for a Sales Engineer Role in 2017, they saw great feedback as well. 

More positive feedback on transparent salary

Keep in mind that salary negotiations can create an unfair salary gap. Research indicates that women and minorities are less likely to negotiate their salary. And a lower starting salary can compound over time to create big pay differences. If you care about establishing equal pay then either:

  • Eliminate negotiations, but make sure you stick to this. 
  • Allow negotiations, but state that in the job post. 

We stated the salary in the job post, and we also said we don’t negotiate on salaries. That way everyone could see that they’re being treated fairly.

Tip #2: Don’t overdo the requirements

You’re walking a fine line with criteria. You want to disqualify people who are absolutely a bad fit, but you want to encourage people on the fence to apply. Why? Because you can still screen them at the next stage. If they don’t even apply, you might miss out on someone great.

Studies also show that women and minorities are more likely to self-select out of job posts if they don’t meet every requirement. So trim your requirements down to only what’s necessary for an applicant to excel; make sure anything you’ve listed under requirements is actually a requirement and not a nice-to-have

You’ll encourage a more diverse talent pool that way. 

👉Miss the actual posting last year? We’ll be sharing it in the The Technical Hiring Handbook. More on that below! 

Tip #3: Focus on skills, not experience

Most developers agree that years of experience is a poor metric for someone’s skill level. Everyone learns at a different pace. And a year in one setting rarely equals a year in another setting. 

If someone only has two years of experience, but can do everything you need, why would you turn them away? I challenge you to search your job posting for the word experience. Ask yourself, “what are the skills I’m looking for with that experience?” Replace experience with skills.

Tip #4: Words matter...don’t mention drama in your post

We originally had a section header in our job post that said, “All the perks of a startup, without any of the drama.” 

One reviewer commented that almost every company who mentions drama in a job post...has a super dramatic workplace. Sure, that’s one person’s biased experience. But I definitely didn’t want to risk that impression of our company. 

So we decided to flip it. In the final post it said, “You’ll enjoy the perks of a startup AND a balanced life.” 

We also ran the post through a handy tool called the Gender Decoder for Job Ads to check for unconscious gender bias. 

Gender Decoder

Subtle biases are tough to recognize. This tool helped us uncover a few blind spots.

Even after running it through multiple inclusivity advisors, our post was still male-biased, and we took steps to fix that. 

Not convinced words matter? Buffer used to call their engineers “Hackers.” They suspected this title might alienate some applicants, so they changed the title to “Developer.” They went from receiving less than 2% female applicants to 11% female applicants. 

So you have a job post...now go promote it

If you were thinking things got easier once you have a job post, then I hate to break it to you—this part is challenging too. Just because you write an awesome job post doesn’t guarantee anyone will see it. If you want to attract high caliber applicants, you’re going to need to figure out where your candidates are and promote the post in those places.

Here’s everything we tried with this job:

👉Want to know where developers hang out and where to post your job ad? We have you covered in The Technical Hiring Handbook

While that isn’t on par with the hundreds of applicants that some companies get, I consider it a huge success for our first job post. 

The channels that were the most successful for us were the Tech Slack (I’ll be compiling a big list of tech slacks all over the country in the handbook), reaching out to influencers, posting on remote-friendly job boards, and sharing the post with our own audience. We got two awesome applicants from our small newsletter of 1,800 people. 

ZipRecruiter did send us a large volume of applicants, but overall the quality was very low. Next time we’ll be experimenting with some more niche job boards, and staying away from the big players. 

We also plan on reaching out to code schools and professors at local universities next time. One of the people we hired was a recent code school graduate and has been an incredible team member. We’ve started building a relationship with Lambda School in preparation for the next time we hire. 

I do want to be transparent that the applicants we got were not particularly diverse. While we did get some strong applicants from countries like the Dominican Republic and Jamaica, every applicant was male. I have some theories on why this was:

  • We didn’t do the hard work to begin recruiting in underrepresented communities before hiring. Posting on minority-focused job boards isn’t the same as building relationships and getting to know people unlike you. This is still something I need to get better at. 
  • At the time our entire team was young, male and white. 
  • The salary we were offering was on the low-end of market rates, so it may not have been as appealing to a wide range of people. 
  • We made it clear we would prefer people in Charleston, which may have prevented some people from applying. We’ve since moved more in the remote direction, so we’ll be less worried about this in the future. 

What next? Hiring part 2 coming soon 

It’s a huge win once you have applicants. Now you need to figure out how to screen and interview them. 

In Part 2 I’ll cover: 

  • How we set up phone screens 
  • Some of the questions we asked 
  • Our scoring system for the initial call 
  • The technical interview (that didn’t involve reading applicants' code!)  
  • Mistakes we made 

I’ll also talk about how we hired two incredible developers, without looking at a single line of code they’ve written. That’s right. We hired two highly-qualified, exceptionally skilled developers, and we did it without reading a single line of their code. 

Hire your next developer with The Technical Handbook  

This series is inspired by the Technical Hiring Handbook. You don’t have to be technical to run a software company, and you don’t have to know how to code to hire a developer. 

You read that correctly. 

You do not have to know how to code to hire a developer. 

With some structure and guidance, you can identify, vet, and hire highly-qualified developers. Without writing or reading a single line of code. Without taking programming courses. And without losing your mind. 

Sound crazy? We might’ve thought so too--if it hadn’t actually worked for us. If it hadn’t helped us hire not one, but two, incredible developers who have led big projects for us in the past year. 

The Technical Hiring Handbook explains exactly how we did it. 

It teaches you how to speak the language, ask the right questions, apply our proven tests, and identify good answers. It guides you through sorting applicants and identifying what makes a good developer. Because a bad hire? That can cost you thousands of dollars and months of work. 

Don’t create your hiring process from scratch. Check out The Technical Hiring Handbook now, and sign up for the mailing list to get a few sample chapters for free as we write them.

The Technical Hiring Handbook

Andrew is our fearless leader. If you want to chat about startups, football or cooking shows you can hit him up on Twitter. If you enjoyed this post it would be a huge help if you shared it or signed up for our newsletter.