A new way to hire
Datalogue is automating data preparation using deep learning. Datalogue is also iterating on the startup hiring process. If you want to give it a shot, Datalogue is hiring!
There was some recent controversy over the whiteboard interviews. They were inherently flawed in the way that they filtered candidates, prioritizing people who think quick and speak quicker, rather than awesome technical candidates that would work well in a team.
From day one at Datalogue, we knew we wanted to do something a bit differently.
And we love open source.
This is how we open sourced our hiring process.
Goals
We are a new, high growth company. Our success depends on finding the best people faster than anyone else can.
So we have to make sure that our hiring process is lean, but still allows us to filter out the best candidates.
What we are looking for in our hires:
- intellectual curiosity;
- ability to work in a team;
- work ethic; &
- technical expertise.
Our goal in hiring is to be able to filter for the above in the fastest possible way, whilst causing the least inconvenience to the applicant (and gathering enough data to continually improve our hiring method).
How we used to hire
We are huge believers that even the most thoughtful hiring process merely approximates the candidate’s performance at work. That really, the only way to test fit is to see how people actually work.
The closest we thought of at the beginning was a coding challenge. Ours were pretty high effort, generally taking a week or so to complete.
This let us dive deep into our potential hire’s coding and problem solving style.
And we got some great hires out of this method.
But, it was hugely time consuming for the candidate.
We tried to mitigate this by letting the candidate know that any thing they wrote for this challenge was theirs, and if they open sourced their work, we’d be totally ok with that.
This played quite well by our candidates, and we had some write blog posts about their experience and write their blog posts into their portfolios. So even if they didn’t land a job with us, it wasn’t a complete waste of time.
But, we couldn’t solve the problem of having no idea how the client works with our team. And interviews can only hint at this.
So, we tried to kill two birds with one stone: Open Source Hiring.
Open Source Hiring
Our open source hiring model has two stages: a technical challenge and a team fit challenge.
Technical Challenge
Our technical challenges tries to pull the good stuff from our old model of coding challenges, while allowing us to learn a bit more about our candidates and feeling less like busywork.
It goes like this.
For each open position that we have, we specify some open source projects that we love. E.g. (for the full list, see our hiring page):
- for our Backend Scala Engineer position, we recommend projects like Akka HTTP; IntelliJ Scala; Quiver; Scala and Scaladex;
- for our Deep Learning Engineer position, we recommend projects like Keras; Matplotlib and Tensorflow; and
- for our Typescript/React Engineer position, we recommend projects like Moment.js; Redux and Typescript.
These are open source projects that we love, and that members of our team have used. (Have I mentioned that Datalogue ❤ Open Source?). We hope that our candidates love these projects too!
Then we give our prompt:
Choose an open source project from our list, or that you are passionate about, and meaningfully contribute to it.
And we ask the applicant to email us a link to their contribution’s pull request, their resume and a brief spiel why they want to work at Datalogue.
This pull request allows us to learn the same things that we would have learned in the coding challenge: how technically skillful is our candidate in their respective field.
But it also gives us a wealth of new knowledge.
We learn what open source projects the candidate likes, and what they are comfortable contributing to.
We learn what the candidate considers to be a meaningful contribution to a piece of work — giving us a glimpse at their motivation. Do they fix a low hanging fruit issue on the issues list? Do they fix a few? Do they fix a complex issue? Do they go the extra mile and implement a new feature?
We learn what the candidate considers to be a meaningful contribution.
We learn how production ready our candidate’s work is. Do they merely solve the problem, or do they solve the problem beautifully, paying attention to the style of the repository they are contributing to.
And, perhaps most significantly, it shows us how our candidate works with others. In the open source community, the pull request is the beginning of the story. With the Open Source Hiring model, we can see how our candidate interacts with the code review process, whether they get defensive, or make the appropriate changes, whether they see their project over the line.
We learn how the candidate works with others.
This is all new information that we can use to make the hiring decision.
But the benefits aren’t just for us.
We get to encourage contribution to open source projects we love, and to encourage a culture of open-source participation.
And, of course we’d love to hire each applicant, but if the candidate doesn’t end up working for us, they aren’t left with a useless coding challenge repo, they are left with a meaningful contribution to a public, open-source project. They build their reputation with the community and have something awesome for their portfolio.
So, after the first stage of the hiring process, we know a little bit about our candidate, and about the work they do, and they start to know about us, and the work we do too.
But we’ve still got to learn about whether we’ll have a cultural fit with our candidate. This part tough. Tougher still when you are still working our your corporate culture.
The Main Course
So we invite the candidate over for dinner.
It is how we learn about whether our candidate is a cultural fit.
We tell them about the dinner. But what we don’t tell the candidate (and it’ll be our little secret here on Medium), is that they’ll be cooking with us.
Cooking is a huge part of our corporate culture. During a sprint, we work hard. But then we’ll cook together and celebrate our work. Sous vide steaks, Japanese pancakes, molé, Israeli food cooked over a bonfire. We throw a lot of heart into our food.
Tim steering the dinner. Nicolas sous-cheffing. Sonia and I chopping veggies for sides. Bryan mixing cocktails. The candidate is thrown right into our family.
This lets us get to know the candidate as a person.
And, it is also delicious!
Just as an aside, we totally do this with some prospective clients and investors as well!
We’re still cooking up the perfect hiring recipe
We are happy with the way that our hiring process has begun to develop. We are learning more and more about our candidates in less and less cumbersome processes.
But we are even happier with the trajectory our hiring process is taking. Because a company is only as good as the people they hire.
And we know that this cooking with every employee might not scale. But it gives us enough of a glance into our candidate’s culture fit with our company that, for us, it is totally worth it while we are at this nascent stage of our company.
The open source hiring challenge will scale. Our dinner might need to scale too.
Datalogue is thinking about new ways to hire. If you want to try the process for yourself, we’re hiring! Check out our open positions here!
Post script: stories from our hiring process
The challenge was REALLY tough. But, it let me jump out of my comfort zone, learn something new, implement crazy things and present it in a way that someone else can understand. Building that workflow goes beyond getting hired for the job.
My assigned challenge was educational and worthwhile without being stressful. It was a great opportunity to show both myself and the team what I can do and was much preferable to the typical game of recycled coding questions in a high-pressure short interview.
— Aarash Heydari
I felt the enthusiasm of the team from the very first email. The team at Datalogue let me go as wild as I wanted during my trial project, giving me feedback and encouragement along the way.
I laid out my thoughts and research over the course of my project in a monster Google Doc, and it felt really good to be able to demonstrate how I think and work when faced with a real-world problem.
— Ethan Hickman
