At Pusher, we take great pride in making developers’ lives easier. Making messaging APIs simple means they can focus time and resources elsewhere. So it’s slightly ironic that our interview process is designed to make prospective engineers’ lives a little more difficult, if only briefly. In the three months since I started here, and after \[…\]
At Pusher, we take great pride in making developers’ lives easier. Making messaging APIs simple means they can focus time and resources elsewhere. So it’s slightly ironic that our interview process is designed to make prospective engineers’ lives a little more difficult, if only briefly.
In the three months since I started here, and after interviewing dozens of software engineers, I’ve only reinforced my view that the perfect objective recruitment process doesn’t exist. But, I wanted to share a few observations on what we have learned about one of the most important processes for any growing company.
Our main current Pusher interview challenge is based on a real problem we’ve faced in the past: recording events in our client libraries at massive scale in a shared nothing architecture.
Just recently our team had to solve another problem in our platform that was closely related to the problem we address in the test. This is a great sign for us. It means the challenges we are asking candidates to tackle reflect those they will encounter once they are on board.
The Pusher tech interview is not a test of right and wrong. It’s more about compatibility and getting a complete picture of how someone operates, and we like answers that make us think. Indeed, one of our most interesting candidates began by questioning the very premise of the challenge we’d set based on a previous experience from her career.
We expect almost anyone who has made it to the interview to be able to take a good crack at the challenge, but the real things we are looking for are all around the edges. Are they pushing up against the edge of their knowledge but with plenty of potential to explore? Are they opening our eyes to new skills or experience the team lacks? Are they suited for the next phase of our growth as a company?
The best candidates often raise more questions than they answer.
A good process is one that is specific enough to put off as many people as it attracts. We don’t want to hire everyone. We want to hire great people who are a good fit for these kinds of challenges and will fit well with Pusher’s culture and future.
Every interview that ends with a negative result is every bit as valuable as those we then hire; it’s all part of the process of finding the right match. Not to mention the fact that we all know others who may be looking for talent and could be a better fit.
Startup Interviews must adapt to support your requirements. A start-up needs people who work across every part of the product and who continuously explore new opportunities in the business. But as time goes on, requirements change. Growing companies like us are more likely to be looking for a “T Shaped” person, a specialising generalist who has an area of deep expertise but can work outside that as well. For example, we are developing a different interview process for our Product Engineers, because although they are broadly similar to our existing team, they have a more specific focus on the libraries and technologies we build around our core platform.
We’re also looking at how to keep the test relevant. This might mean splitting it up or testing interviewees in teams with complementary skills, and we’ll continue to make sure the test reflects some of our ambitious plans for the future.
One important thing about our test is that it lets all the elements of a candidate’s experience that exist outside of the interview room come into play. An encouraging sign: if you’re reading this, you’re already doing a good job on that front.
If you want to see how you perform on the next step, and if you’re up to the massive challenges that Pusher has ahead, we’re hiring.