I sometimes get asked about setting up a engineering recruitment / hiring practice. Most probably because I once had the opportunity to help bootstrap a business that after more than five years still had no meaningful employee churn while growing from zero to fifty people. I am talking about GoDataDriven, a professional services firm with a focus on data science (you guessed it). After GoDataDriven, I joined fashionTrade as their CTO. There we grew the engineering team from zero to twentyfive-ish over the course of less than two years. Hence there was more pressure on the hiring process and we had to have more conversations. Having more conversations creates more incentive to try and optimise parts of the process.

I am going to save the lengthy details about recruitment and hiring practices for another post, but for now, I will share what is positively the single most useful thing I have ever done to improve an existing hiring process. I wrote a ~10 page document called fashionTrade Engineering Notes.

A introductory job interview is a lot like a poorly prepared meeting. There's no agenda. There hasn't been any exchange of relevant information (one CV versus one job description). The desired outcome is that both parties learn enough about each other to decide whether to proceed to next steps in the process. Unfortunately there is no prior understanding of how that decision is made on either side of the table. So what do you do? On the interviewer side you resort to something along the lines of "tell me a bit about yourself". Subsequently, after the personal sales pitch, most interesting candidates interrogate the prospective employer on anything related to the work environment; firing of a greedy random search scratching the surface on all relevant topics until either some red flag is encountered or you run out of time. Hit any red flag and a deep dive into, for example, your way of handling merge conflicts ensues. Based on the details a candidate will either conclude that your company is full of lunatics who don't know how to build software or that you are competent and next steps are not necessarily a complete waste of time. Running out of time can earn you the benefit of the doubt. As it turns out, greedy searches are a poor approach to globally informed decisions.

As a resolution you can simply move the surface scratching to before the meeting and use the meeting for deep diving into a few carefully selected topics that are a actual priority for a candidate. Enter engineering notes: a document that concisely and honestly describes your software building practices. Cover technology, process, on boarding, and any obvious questions that your approaches may raise. Send these to a candidate timely before the introduction call or interview takes place.

Real Example - fashionTrade Engineering Notes

My successor at fashionTrade has generously given his permission to share my version of the fashionTrade engineering notes publicly. You can view a PDF version here. Keep in mind that this is my outdated version (about a year and a half old by my estimate). If you are interested in receiving the latest and greatest, please apply here.

If you read the document you see that it is basically a large collection of bullet points. This is intentional. I recommend keeping things dense and concise. You are targeting this writing at people with whom you would like to work. You don't need layman's explanation for anything that's not specific to your business, because you are not looking for layman. You are also not looking for people too lazy to do a web search for some unfamiliar piece of technology. This document is not for building an audience, it is for filtering an audience. Be refreshingly honest about everything. You are sending this to people who already decided to apply. Nonetheless it shouldn't hurt to make this public nor to provide this to anybody upon request, whether already in the funnel or not. Transparency is often rewarded.

What About Listing on KeyValues / Glassdoor / Something Else Instead?

And then what? Expect candidates to go find the content themselves? Don't confuse employer marketing or branding activities with providing information to candidates. On public employer comparison or job sites, you are competing for eyeballs. When everyone is competing for eyeballs, it's a race to maximum bullshit until the platform introduces some form of sponsored placement. Welcome to contemporary internet; your only option is to play along. Engineering notes are not for exposure, they are for creating a better experience for candidates and a better utilisation of your time spent on interviewing.

By the way for the unaware, keyvalues.com is an online space where organisations present their engineering culture by selecting applicable tags from a set of possible values. If everything on there is true, there are only 3 out of 90+ companies that consider having a good beer to be one of their top 8 values. And 19 out of 90+ who think this way of maintaining a high quality code base. But stating this is not the same as providing an honest answer to the question "how do you maintain code quality?". And you know that latter question is one of many you can expect from a candidate, so do yourself a favour and save both of you some time by sharing the answer before the interview.

Are You Next?

Do you think this is a valuable idea and are you prepared to share your engineering notes as an example? Message me at the f.van.vollenhoven alias on Gmail and I will add your notes to this post as an example.