I was fortunate enough to spend a lot of time helping companies establish their team culture and hiring pipelines for technologist positions lately, a task that I enjoy quite a bit.
What I want to do in this post is share a few opinions and insights into what I believe a good hiring process looks like, for applicants and interviewers alike. Because I’m a technologist, my bias will be towards hiring other technologists. Maybe you will be able to take something away from this if you are hiring for other departments, but I can’t promise anything.
Now let me start with a little bit of history.
My history of hiring, tech and non-tech
When I was CTO, I spent a lot of time trying to make the hiring process at Port Zero as transparent, efficient, and little stress as possible; we didn’t always succeed: even in our small team we sometimes dropped the ball when it came to responding to applicants in a timely manner or, worse still, miscommunicated internally or externally. I’m happy to report that this got better over time, though. It also helped that we improved and documented our onboarding process, but that’s a story for another post.
Being a small team—less than 20 people for most of my stint there—, most of the colleagues I interviewed and eventually onboarded were part of the tech team. I was involved in all hiring decisions, though, because we were all connected, and we all needed to get along1.
I wrote an internal guide that I’m still quite proud of. Many of the ideals I still have made it into the guide, and most of them were not my ideas, but instead the product of a series of conversations with various people inside the company2.
Since then, I’ve worked with a few companies to help them shape the same processes. Some of the ideas stuck, some of them didn’t make it, but in the end the hiring process was always a reflection of where the company was, and where it wanted to go.
Since it all starts with a job advertisement, let’s talk about that.
Writing a job description
I’ve co-written maybe a few dozen job descriptions: no mind-boggling numbers, but enough to develop a feel for them. I’ve read way more job descriptions than I have written though, and I don’t have many kind words for most of them.
A job description is just like any other piece of writing: you can tell whether it was written to be read, or because it had to be written. This might be my cynicism talking, but if the job description mostly consists of bullet points describing the requirements the candidate will need to meet in order to be considered, it is not a job worth applying for3.
A good job desription tells me something about the company I’m applying for. A good mix of “hard” (what is our mission?, how big are we?, are we seed-funded? Post-IPO? Self-funded? Employee-owned?, etc.) and “soft” (what kind of workspace do we want to create? Does an individual contributor have leverage to shape the future of the company?) data is usually a good idea. The “soft” part is even more important in my opinion, because it isn’t just shaped by what is said, but also by what is left out. If you don’t tell me that my voice will be heard, my voice will most likely not be heard.
Similarly, the qualifications of an interviewee are important. Just as important is what they’re excited about and interested in. Someone spending many years working on machine learning pipelines doesn’t equal them wanting to do that. The reality is that most of us need jobs to survive4, and most of us will end up spending time working on things that we’d rather not touch at all. For this reason, and because it is more of a two-way street, I like to stress what a potential colleague might be excited by and put less emphasis on what qualifications they need to bring to the table.
I see writing job descriptions as an opportunity to make a good first impression, and to attract people I want to work with. Yet, what I often see are non-descript, uninteresting walls of bullet points without a trace of humanity or warmth.
I’m sure there are people who just want to know the rough shape of the job and get on with their lives, particularly in tech. But I also believe that making processes more human and warm is a worthy goal in itself, no matter whether you do it to increase productivity or just because you want to make people smile5.
Okay, we’ve finally produced an artisanal piece of prose attracting scores of promising applicants. What now? Well, whether you like it or not, we actually have to talk to people.
The pipeline
Here is where it gets complicated. Depending on company size, the department that’s hiring, the level of the positions, the company culture, and a thousand other messy factors, the process might take a few different turns. Who knew HR was so complicated it could be a discipline all of its own?
Let’s focus on technical applicants here, because it’s what I know best. I don’t have any silver bullets or programs to peddle here either, but I do have some opinions.
I usually insist on at least three separate interviews. One organizational interview with a manager, one technical interview with a peer, and finally one with someone who has the authority to talk about money and other administrative matters.
The first interview: a first date
In the first interview, the applicant talks to at least one future manager—depending on the company size that could be the CEO, the team lead, or anyone in between—and they talk about the company, the position, the team, the applicant, and, most importantly, about the process.
This serves as a first contact, and any preliminary organizational questions can be addressed. The desired outcome for the manager is to have a feeling about the person they just talked to, and for the applicant to know anything they want to know about the company and position, and what lies ahead of them in the process.
They probably won’t know the salary they can expect by then, but I like to not make them reveal their target salary either if it’s avoidable. Personally I think it’s a huge red flag if a company asks me about my desired salary early and/or persistently. Money matters, but not until you know what you’re getting for it. I understand that you don’t want to waste money on someone who is way out of your salary band, but then it should be your responsibility to put your cards on the table. If you’re not prepared to do that, don’t bully your applicant into doing it instead.
The second interview: let’s talk about technology
The second interview is a technical assessment. I don’t like algorithmic whiteboard assessments, and I have the same objections to them as everyone else has. I do believe that a practical problem is most often required. To solve this dichotomy, I like to make the problem a pairing problem: the interviewer and interviewee can work on something together, like refactoring a messy piece of code, writing a small feature, or configuring a server, depending on the position.
This solves my most important gripes with traditional puzzle questions: it makes them less adversarial through collaboration, serves as an important indicator of whether the applicant can work with the rest of the team, and it more closely resembles how a well-functioning organization might tackle problems. It might also alleviate some anxiety for the interviewee by making them feel less like a target and more as part of a team, but I think this is different across personality types and not really a cure-all.
I do think that making the experience less stressful for the applicant should be an explicit goal, and the interviewer shouldn’t try to “put them on the spot” too much. Will doing that reveal potentially useful data points? Sure, but it’s also messy—because different people react differently to that sort of stimulus, and that’s okay—and unnecessary. The reality is that even if we make the experience as seamless as we possibly can for the applicant, it will still be a stressful situation for them to overcome. So if you want to see how your employees perform under pressure, rest assured that plenty of pressure is applied. Their future livelihood is at stake.
I also think that setting an approximate goal is important—we want to get this feature done by a certain time, for instance—, but if an applicant performs well and works well with the team, not being able to get through the task in time shouldn’t be an automatic disqualifier. I interviewed people that had novel approaches to problems I knew extremely well, and we were only able to produce sketches of the solution in the allocated time. This shouldn’t be a problem, it should be cause for celebration.
The third interview: money and other trivialities
The third and final interview should talk about all the other messy squishy human things that weren’t covered in the first conversation with the applicant. This should be the salary—please tell me you didn’t ask them about their expectations in interview #1—and other administrative matters—holidays and sick leave6 might be discussed here, as well as matters like potential visa applications and a start date, if that wasn’t already touched upon.
It should be clear at this point whether you want to work with the applicant or not, and you shouldn’t try to string them along. Hammer out the details as quickly as possible.
Rejections
Up until now I’ve written exclusively about the happy path: the right candidate applies for the right position, they make it all the way through the process, and they’re eventually hired. For every hire you’ll make, you will have to reject some people, however, and ideally that can be done with integrity and grace, and with the candidate’s dignity intact.
Firstly, the candidate should be notified of the rejection as quickly as possible. If it takes you more than a few days to get back to them after you made up your mind, you dropped the ball. Don’t worry, I’ve also dropped the ball. It happens, but it shouldn’t. Tell them about your decision.
I usually don’t include any reasons for the rejection in the e-mail, but I like to offer to give the applicant feedback if they so desire and I have the time. In my experience, most people won’t actually ask for feedback, and the few that do really want to know how they could do better, and who am I to deny them that. But this is a double-edged sword: the reasons you are rejecting a candidate might be the same reasons they excel at other places. Make sure to keep that in mind when delivering your feedback, and don’t make the candidate feel bad about it. Delivering good feedback is hard, and a skill in itself that needs to be practiced. If you’re not sure you can do it in a way that is productive, don’t offer it.
Fin
Hiring should be an opportunity to meet new people and learn new things, for both parties. More often than not it feels like anxiety hell. I don’t think this is necessary or productive, and I hope that you can use some of the things I said to improve on your hiring process.
And to all of my technical readers who’d rather see programming content: I’m working on it, I promise! I have something about maps and lambda calculus, I just haven’t written it yet. Stay tuned.
Footnotes
1. Yes, this can be classified as the dreaded “culture fit” part of the interview. For me, the focus was always “can I see everyone in my team who needs to work with this person have a productive and professional relationship with them for a long time”? I don’t believe that the focus should be whether you would go have drinks with this person after work—it’s great if you are able to be friends as well as colleagues–, but what happens inside the office, emnotional and professional, is what you need to optimize for.
On the other hand, I believe that if you think your colleagues’ personalities shouldn’t matter, and everyone should just get their act together and get over themselves, you don’t know how humans work. A good work place is good precisely because it has a personality, not for the lack of it—anything else would be inhuman. You’ll sometimes need to think about the culture you have and the culture you want, and how to get from the one to the other, even if you don’t want to; humans are messy like that.
2. As such, it is very much tailored towards Port Zero. The truth is that most good interview guidelines I’ve seen have at least a bit of the company’s personality embedded into them. This means that if you adopt anyone else’s process wholesale, it will most likely not work out for you.
3. Self privilege check: even being able to say that reflects how much of a position of power I inhabit, and I understand that most people cannot just not consider applying to a job because the description is mediocre. I still want to make the situation better for everybody; looking for a job shouldn’t be as stressful as it is.
4. Landlords notwithstanding.
5. Remember: happiness increases productivity. Finally a goal coddled millenials and cut-throat capitalists can agree on.
6. Optional. Sick leave should be limitless, but I know that is not reality everywhere.