Posted on April 18, 2020
For the past few weeks, I've been helping out a friend with some technical recruiting. This is a bit of new territory for me and with that always comes new things to learn. I've done my fair share of hiring in the past, so it isn't completely foreign but this situation is unique for me.
The process is exhausting and difficult but in the end you're bringing a new person onto your team to help your company grow. So it's worth it. You keep pushing through because that one next person can really help your company grow.
But I've never tried to hire someone for someone else's team. It feels counterintuitive in a way. But I'm wrapping my head around it so far. I'm helping talented people find a great job and that's wonderful. I'm also helping someone else build a team to do important work. I'll only be involved from afar, but the end result is the same.
The technical recruiting world is broken and awful. The vast majority of people that I've encountered doing this job are playing a strict numbers game. They blast out job postings, candidates, and poorly researched e-mail introductions by the thousands just hoping for a few suckers to respond.
From a candidate's side it's a beat down. I've long ago disabled all notifications from LinkedIn and I have a number of pattern matching filters on my e-mail addresses to keep this stuff from ever reaching my inbox. I'm not trying to be rude, but there is so much garbage out there that it's hard to find a signal in that noise. Every few weeks I'll go into LinkedIn and my message queue is filled with recruitment notes for "once in a lifetime" and "top tier" positions at great "brands". If these positions were that unique, I wouldn't get 20 of them a week.
From the company's side, it's also a beat down. Many of the companies are actually doing interesting work. They have a real problem on their hands and they have a business opportunity they could accomplish if they could just find a few good people to focus on it. Many (but certainly not all) of the hiring managers in these companies are not technical and feel unequipped to find the right people for the positions. To solve the problem there are usually both internal company recruiters and external staffing and recruiting firms. Both have their benefits and both approaches can be completely terrible.
Staffing firms have a less than desirable reputation in the tech world. For good reason too. The numbers game playing out each day is a complete turn off and gives the industry a bad name. It's not usually that they don't care, they just don't know what to do. They are tasked with hiring for a very technical position that they don't understand and don't know how to qualify people for. It's a beat down all around.
I'm not here to solve the world's recruiting problems. I'm passionate about building software and companies around that software. Recruiting is certainly one piece of that puzzle, but it's usually something I leave to others. In short, I'm not leaving my 'day' job to become a recruiter, but I can still help a little bit.
The biggest thing I think I'm contributing to this process is that I know these technical jobs. I've done the jobs myself, I've been in these roles. I've hired for them before in my own companies. I know the tech and I understand the problems the companies are trying to solve by hiring. I also know a thing or two about shipping software and actually accomplishing organizational goals. So I'm using what I know to identify people that I'd hire if I was the company.
The challenging part of finding who I'd hire is: I'm not hiring them! I am just one piece of the process and just one opinion in the room. Sometimes who I'd hire isn't the right fit for a company, and that's totally fine. It's their company and I need to defer to them on what's best. It's hard to present someone I think is great and have them rejected, but that's a part of the deal. I'm working on getting better at this.
The Interview Process
I'm learning about big company interview processes a bit too. The biggest company I've worked for was about 120,000 employees at its peak, and I've slowly moved my career into the opposite direction ever since. I prefer to work in a startup with less than 10 people. So it's a bit different. There's nothing inherently wrong with a big company, as much as it's not for me.
At a bigger company, the interview process is completely different than what I've been exposed to most of my career. For the past decade or so I've almost exclusively been hiring for companies that I own or have built. This is a very different process than hiring for a company that's been around for decades and is publicly traded, for example. I would obsess on every hire and worry about how they would affect the company's vibe and culture. I cared more about their personality and past experience than how technical they were. I can teach programming, but I can't teach someone be kind to their coworkers if they don't think that's worthwhile. With a bigger company, culture is still important, but it's very different than a startup. Hard skills seem to matter more than the soft ones.
My interview style is to speak conversationally with the person and just try and get to know them. I want to know how they think. How do they solve problems? What problems have they solved before? What did they learn from those problems? Sure, we can get technical here. If they built a cool API I'll most certainly ask how they built it. What did they build it with? How did it scale? How did you decide to use this piece of tech over this other one? There aren't right or wrong answers here, for the most part. I'm imagining this person in the role I'm hiring for and trying to see how their past experiences and best practices align with mine and those of my team.
I'm not into tricks and riddles and code algorithm puzzles. Not one bit. I don't care if you know some specific computer science term or how to best write some algorithm. Most good developers I know spend a lot of time Googling and figuring things out. I know I do. If I'm presented with a performance challenge, I'm surely not going to recall some abstract algorithm from college and apply it from memory. I'm going to search for a solution. I'm going to look at forums and read blogs about how others are solving the problem. I'll chat it through with coworkers. Then I'll devise a solution and implement it. Maybe I'll do that whole process two or three times before the best solution presents itself.
So I'd probably be terrible in a coding quiz interview. I might be laughed out of the room if I had to whiteboard some computer science algorithm from memory. I don't need to know that stuff, I just need to know that it's a thing. In the "real world" I'd Google it and solve it within 10 minutes.
But these type of things are quite common in big company land. So I'm learning to adapt. If I find someone I like, it's now part of my job to prepare them for these type of technical interviews. Once I find someone that I think can do they job, I need to also make sure they can pass the interview. These are very different things, but if the end goal is the same, it's a worthwhile effort.
As with everything in this space, I'm not sure if I'm right or wrong. I don't think there is a hard and fast 'right or wrong'. I'm just doing what I know and what's worked for me.
As I think I've articulated, recruiting is a big giant mess. It's hard for everyone. There's no perfectly correct way to do this and the only way to get better is to keep trying to get better.
I'm going to keep trying for now. It's a small chunk of my free time, but it's been an interesting ride so far.
Now back to building software.