A story that I frequently share when speaking at conferences is the one when I finally re-hired Ania. Once she agreed to rejoin us, I was so ecstatic to share the news with everyone. And then Tomek and Marcin popped up at my desk with sad faces to tell me: “Pawel, it’s not how we hire here anymore.”
One thing I realized back then is how successful we were with distributing autonomy. After all, two developers telling the CEO that he had no right to make a call about hiring a new employee tells quite a story. Another thing though was how much our hiring process had evolved up until then.
Since that awkward conversation, evolution has continued. While I think that by now we have a fairly stable hiring process I do expect it to be subject to change in future. After all, our experience in recruitment, as well as awareness of what we are looking for in candidates, improves as we get more and more chances to practise.
What We Are Looking For
First things first. What we are looking for when we talk to a candidate. As the lead text on our job page suggests technical skills are only a part of the story, and not even the most critical one. Don’t get me wrong. It’s not that you can slip through hiring after finishing a couple of online courses for software developers. In fact, the technical bar is set fairly high.
You can, however, be a damn good developer and still fail. I told you: engineering skills are neither the only nor the most important skill set that we seek.
By the way, while in the examples I will use an archetype of a software developer as this is the most common role at Lunar, the story is true for graphic / UX designers, testers and all the other roles too.
The lens we use to look at engineering skills of a candidate is craftsmanship. I tend to phrase what craftsmanship is by saying that it’s taking pride in the quality of work that we do and continuously looking for better ways of doing things.
In a way, it is fuel to our personal learning vehicles. We want to get better at what we do because that’s who we are.
And that’s crucial as whenever we hire a person we don’t hire them for what they know right now; we buy their long term potential. That’s why a craftsman with lower technical skills will most likely win with someone who is already damn good but who doesn’t share that attitude.
Then we have the most important set of traits that we look for. Team skills.
I guess the meta-trait that we seek, and you’d find a hint in our job page, is that we want people who join us to notice and help a troubled colleague.
It means an understanding of teamwork as collective effort as opposed to an independent race for everyone involved. We are only as fast as the slowest person on the team. This rare trait basically makes everyone else on the team better. It is the true north for us. Interestingly, it doesn’t matter that much whether that person is the most technically skilled engineer in a team.
It means perception of others. How they are feeling. How they are acting. How they are behaving. It may be through empathy. It may be through sensitive perception. It may be through conscious effort. Whatever the means, we want team members to notice others.
It also means acting on what you see. It’s not only a willingness to help others but also how one helps. Inflicted help is often counterproductive. We need to understand others enough to know what kind of help they look for and what kind of help they are willing to accept.
It takes a lot of soft skills and awareness to excel at that. While we don’t look for perfection on this account, we need people who show the potential to excel as team members and leaders. Interestingly enough, the way we understand leadership means that we expect everyone to be a leader in a fitting context.
Oh, there’s one more skill that I keep forgetting about. You can score high on everything else but if you don’t speak really good English then it’s a no. For us, communication in English is like a driving licence for a driver. We. Really. Need. That. No. Kidding.
There is also something that is fairly vague but super-important. We look for a cultural fit. This one requires a little bit of explanation, though.
Most frequently when I hear about cultural fit and I have a chance to ask what people think when they say “cultural fit” I end up disheartened. The most typical notion of cultural fit is people who we would get on well with. Well, there’s a huge problem with such an approach.
In general, we tend to like people who are fairly similar to ourselves. Folks who have similar interests, similar walks of life or similar characters would likely be those who will make us feel most comfortable. The problem is that they are culturally very similar to us. In other words, if we defined cultural fit this way it means that we’d end up with a very homogeneous culture.
We’d feel comfortable at the office. That’s for sure. Would it help us to be more effective? Not at all. Conversely, we’d risk a close encounter with a phenomenon called groupthink, that leads to conformity and lack of critical evaluation. Nothing that you’d want to see in an industry that has solving complex problems at its core.
The way we understand cultural fit is that someone fits our (very broad understanding of) culture, shares our values, but at the same time would stretch that culture in a way. We want people who won’t introduce too much friction. But some tension is actually a plus.
We want people to have the potential to lead us in at least one of many dimensions which we want to improve. Be it how we learn, a technology skill, interpersonal dynamics, atmosphere, organizational stuff, empathy, respect, etc. It doesn’t have to be something specific. It should be something, though.
In other words, ideally, we look for people who would be thumbed up by most of us (a signal of fitting into the broad culture) and thumbed down by few (a signal that we’d likely feel pulled out of our comfort zones by a candidate).
Now you know what we look for, here’s how we look. We kick things off with technical evaluation. Yup, you hear me. I mentioned that technical skills are neither the most important nor the only part that we focus on and yet we start with this.
The reason is very simple. We want to make sure that a new hire won’t be a burden for their team. In other words, wherever the bar is for a specific role, we want a candidate to be above that. Now, depending on the context, we’d expect different expertise levels. We don’t expect interns to be ready to instantly jump into a commercial project (even if it has happened here before). We don’t want developers to have a half a year learning curve before they are ready to get the ball rolling on a billed project either.
Anyway, the critical part of that stage is that as long as a candidate is above the bar it’s fine. It doesn’t matter whether it’s slightly above the bar or it’s more like “phew, that was left-handed” kind of case.
Ultimately it’s a kind of a filter. Depending on the context it may consist any of these three elements.
We trust referrals made by Lunar folks. If one of us knows someone and strongly believe that they’re a good fit then it’s a pass.
A short, typically around a half an hour long, interview with a couple Lunar engineers. In other words, a candidate would be talking with fellow developers, designers or testers and not a manager (we don’t have one so that would be hard anyway). We focus mostly on technical stuff but the most obvious personal characteristics will be evaluated too. Normally the interview is done at the office but it occasionally occurs on a video call too.
Most likely practised when it comes to internships but we may also try it in other cases. We give a candidate homework to do and then evaluate the result. A follow-up to the homework will almost always be an interview. Homework may mean writing a bit of code, which is the most common case, but it can be as weird as asking candidates to read a book.
Once a candidate makes it through the initial filtering, which may require literally nothing on candidate’s end in the case they had a strong recommendation, we’re down to the last part. We call it Happy Hours and originally it was dubbed Demo Day.
Happy Hours means spending a few hours with us, typically between 4 and 6, during our regular workday. The goal is twofold. First, we want a candidate to develop an opinion whether Lunar Logic is a good place for them to work at. Second, we want to give all Lunar folk an opportunity to develop an opinion about the candidate. The latter part is not mandatory, i.e. everyone at Lunar is invited to take part in Happy Hours but nobody is forced or even encouraged to do so.
The activities that happen during Happy Hours would vary from those focused on craftsmanship (e.g. pair programming), though those that validate how one thinks (e.g. design workshop), to those that tackle soft skills (e.g. a chit chat about candidate’s stories of teamwork).
Happy Hours are not structured so it feels a little bit like passing a candidate from one person’s hands to the others. There’s quite a lot of loose discussion in the kitchen in a bigger group too. Ultimately these kind of interactions would be happening on a regular day at Lunar.
After Happy Hours, we collectively make a decision. It follows the Decision Making Process pattern so there’s a broader discussion among everyone who took part in Happy Hours. Then someone makes an autonomous call whether we make an offer or not.
We don’t seek consensus in these discussions. However, for a positive decision, a significant majority for “yes” is typically required. In other words, a set of fairly evenly distributed opinions (some for “yes”, some for “no”, some for “meh”) most likely means a “no”.
The last step is figuring what a financial offer for the candidate would be. To simplify things we typically run a super quick salary process, exactly the way we do it for ourselves when we discuss raises. This makes the offer fair in relation to current salaries at the company.
It does mean that, while we obviously are interested in how much you expect to earn, we will propose a salary. Since the offer aims to keep our payroll fair it is highly unlikely that we’d be open for heavy negotiation. As one famous football coach said: no player is bigger than the club.
That’s it. It may sound like quite an elaborate thing but in some cases, it boils down to fairly informal, few-hour long visit at the office.
I’d like to write something like “Since we adopted that technique…” but it wouldn’t be true. There wasn’t a single point when we started hiring this way. It is more an outcome of how this process evolved over time. Throughout this evolution, we’ve been making fewer and fewer hiring mistakes, which seems to validate how well the process works for us.