Background: AKA, Why did we overhaul in the first place?
This year my engineering team is facing growth, our hiring process was always a bit over-bloated and not efficient, but we didn’t feel like it’s worth touching it until now…
Basically, when we realized how many more people we will need to hire and how much time we need to invest, also how much we care about hiring the right people and especially how much we value culture in our org, we realized it’s time for a change.
So, we overhauled because:
- We wanted to understand better that we hire right – meaning, we know what is important for us and we know what we look for in each interview.
- We wanted to help the candidates have a great experience! interviews are bi-directional, it’s also a window to the candidate to have a glimpse of who we are, we really wanted to let our candidates see us in our interview process.
- Interviews are expensive, especially if we do them a whole lot, we tried to streamline our process to be better and more effective – so our feature teams would still be able to produce things
How did we solve our problems?
Profile definition workshop
We decided to create a workshop, to review our current hiring process, we opened it for people in our department, people with different experiences.
Senior devs – Junior devs, Women and under-represented groups, Tech-Leads and Engineering Managers… we wanted to reduce biases and make sure we create a process that is fair for everyone, to make sure to have people from all those groups that we appreciate, so if they would give us feedback against something – we would understand that we might miss their talents…
All of us then took the time and wrote what is important for us to have from our colleagues and future hires alike, we clustered, discussed and basically defined the profile of a person we want according to our clusters and discussion of our results.
We create “Must Have” and a “Good to have” lists.
Interview Process Creation
After we defined the profile of developers we wish to have (cultural and skillset), we started breaking our interview sessions to see how can we test out all the topics we wanted to find in an efficient way, that would be fair for the candidate.
We looked at our former process and took what was already working into our new one (and tagged what each interview will find). The rest was built, to try and be productive.
SO, without further ado, here it is:
Ze’ Process (As we share it with the candidate, written in “you” language, as you are the candidate reading it)
Before we start, we don’t believe that sending a coding challenge is fair as a concept, as we believe that interviews are bi-directional, sending people tests, felt like we ask them to buy-into us, before they even spoke with us… so instead of that, we added a small technical question in our initial call, a screener question.
In this 30-45 minute call, we’ll get to know each other and we’d love to hear about your motivation to apply for the position. Participating in the conversation will be an HR representative and a hiring manager or tech lead. It will be a two-way conversation and we want to understand whether we’ll be a good fit for one another.
You will have time to introduce yourself and we will tell you about the organization, the software development department and the team you will be working with. You will be asked about your experience and some simple technical questions. During the whole interview feel free to ask any questions.
Pair Programming Session
This session will take around two hours and will be done remotely over Google Hangout. One developer will be participating. There will be two main sections: a straightforward programming session and a discussion over a conceptual problem.
During the pair programming exercise, you’ll be working together with one of the developers on refactoring a small set of self-contained legacy code. No knowledge of MediaWiki or other such specific technology is required. You will have the choice between doing the exercise in PHP and in JS.
The Pair Programming allows us to see how you approach problems, how you collaborate and how you communicate. You and the developer will pretend to work, as colleagues, on a task at a company you just started working for. This collaboration is what is evaluated, so there is no need to rush and try to get as much of the exercise done as possible. If it is not completed, which is likely, you will not be penalized for this.
The remote pairing is done via Floobits, a service that allows synchronization of code between different machines and editors. If you are using one of the supported editors, you can just install the Floobits plugin for it. If none of these editors works for you, it is possible to use the web-based editor. For the web-based editor, you also set up synchronization of the files to your device, since otherwise, you will not be able to execute the program and tests. The developer is likely to use PhpStorm (IntelliJ) as editor.
To prepare for the session, create a Floobits account and set up and test the integration with your editor of choice. To do this test you can create your own Floobits workspace and connect to it. Also, make sure that your Google Hangout is working and that you are able to execute in the language you choose for the exercise.
This will allow us to get a better understanding of your technical skills and how you collaborate and communicate with people in your team. We will also be assessing how you approach problems and your thought processes as you reach a solution.
Organized at the headquarters of Wikimedia Deutschland e. V., in Berlin. It will take around three hours and is divided into four sections:
- Interview with the Feature team (45 minutes): you and the team will be able to ask each other questions about the organization of the team, the processes or any other aspects which you are interested in. This allows you to get to know your potential colleagues and for them to get to know you.
- Team Daily’s Meeting (15 minutes): you’ll have the chance to participate in the daily standup meeting and see what we’re working on.
- 1:1 time with a developer (30 minutes): You will spend this time with one of the developers you would be working with by sitting next to them as they walk you through something they are working on. This will give you the opportunity of getting a glimpse of the codebase, ask questions and discuss things as you see fit.
- Lunch/Coffee Break (non-compulsory, max. 1 hour): if you so wish you will have some time with 4-6 department colleagues (developers and non-developers) to meet over lunch or coffee and talk about any matters you wish in a non-working environment. Please note that this step of the process is non-compulsory. If you decide to participate Wikimedia Deutschland e. V. will take care of the coffee/lunch costs.
This day you will be given as well a tour through the office and briefly meet other people from a variety of roles and teams.
For people living abroad, we may decide to reimburse their travel costs, or we choose to carry out Insight Day remotely.
We will send you the job offer based on the details agreed upon during the Insight Day.
- We got great feedback from candidates, which is a great win on our side.
- We reduced about 15 hours (combined) moving from the former process to the new
- We created a shared understanding and standardized our process, we now know what we look for, and also, what is the value of each interview
- We are really happy with the reduced stress on the feature team, last year we hired fewer people and we had months of general stress due to our former process