It happens impromptu. I see a pull request or an interesting project someone built with us. If they stick around and seem interested in the project, I reach out via direct message and see what their goals are. I half heartedly ask them if they'd like to do this full time. If they seem interested, we setup a minor call and we talk about current projects they're working on, and what we're working on at the company.
We compare notes and see if interests line up. From there it's negotiations.
I've already seen their code and interacted with them for a few weeks by this point, so the interviews are painless and obvious.
One thing I make sure to do is be very clear/direct that we're a business. Here's how we make money, here's who our customers tend to be.
Usually it's a just a quick phone conversation to talk about interest. The technical interview actually happens the second you enter my open source channel and contribute code or show off something cool you built.
This demonstrates a few things to me:
1. You know our codebase
2. You can build things we need
3. I've already collaborated with you
4. You're proactive and interested in solving problems we
would have for you.
5. You're able to collaborate with others remotely.
I like this. Interviews are supposed to be proxy of how successful / valuable the team member is going to be on the job. Since the person is already contributing, makes sense to cut out the "algorithmic quiz".
We also do a lot of c and scala :D. That was the idea.
One of the things I wanted to do was avoid using a degree or "pedigree" as an indicator.
I myself dropped out of my undergrad at a no name university in the midwest. I don't have "pedigree".
I'm also not a large believer in the way things are done in the valley (did 2.5 years, that was enough for me..).
This is my opinion, I don't claim this is fact, but I know again, this may offend some:
A lot of the emphasis on pedigree, but there are a lot of dead startups with people who have degrees from stanford,mit, harvard etc.
It's a self perpetuating echo chamber with a lot of money flowing through it. The group think is so thick you can cut it with a knife.
I love the valley, and there are a lot of good things about it, but the perpetual group think with the larger part of the population is a problem.
That being said, I don't think I would found a company anywhere else. I tried 3 times in Michigan, and it's just a lot harder. I learned a lot quicker in the valley. You have to learn what to watch out for though.
Anyways:
I also live the same life style we hire by. I mostly travel.
My cofounder is in san francisco. I travel all over different parts of APAC with an established office in tokyo. There's only 2 of us in japan right now though. A lot of us are in the apac "time zone".
Do you plan to include python in your roadmap in near future (I can possibly help if you don't have in-house expertise on it ;), or choosing to avoid competing with Tensorflow?
I suspect Python would be fairly popular amongst companies looking to build deep learning based products.
That will allow us to benefit from what that community is building in terms of neural networks. We want to be the "deployment path" for those kinds of models while we focus on making c++ on the jvm as fast as possible.
We basically focus on the hadoop and spark crowd. We're already the industry standard in java/scala:
interesting - this seems like perhaps a "good enough" solution for the age old problem that many creative-type career often encounter these days where employers don't want to pay to hire someone before knowing if they can work, while employees don't want to work before knowing they'll be paid. your method seems to basically say, we won't hire you unless you've already done work for us, and we expect that you are self-motivated to do that work and not at our behest so you can't blame us if we don't consider your work good enough to hire you. that's actually pretty clever, although i wonder if this is something that can be applied for other companies.
A lot of companies employ this strategy with some sort of open source presence on github.
The key for the hiring on the open source component is, we use this in our daily work, and it's directly useful when people work on it.
The open source project itself is fairly popular though.
The easiest analog here might be something like a react js.
I definitely don't claim to have this generalize well, only that it's worked for us, and some companies do this to an extent. I'm not sure how many companies hook their hiring in to this though.
If more hiring engineering managers were aware of their open source presence, and who did what on there, it could make hiring more efficient.
We've had very good retention over the last few years, because there's some pre vetting that happens at the very minimum.
I'm currently looking at formalizing this in some form, but there's a trade off to how much formalization you do vs making the process inefficient.
We compare notes and see if interests line up. From there it's negotiations.
I've already seen their code and interacted with them for a few weeks by this point, so the interviews are painless and obvious.
One thing I make sure to do is be very clear/direct that we're a business. Here's how we make money, here's who our customers tend to be.