-
Women Techmakers Berlin Slack (Irmela has access)
-
Women In Tech Slack (Irmela has access)
-
Berlin Startup Jobs (costs 120euro per ad)
-
Indeed (a daily fee per ad - they recommend 14 euro)
-
Berlin Dev Jobs (costs 149euro per ad)
For every position or group of positions we are trying to fill we establish a small hiring team. The hiring team is a temporary team of (ideally) 3 people who review and assess the job applicants, perform the initial video interviews, suggest candidates for the main interview round and weigh in in the final hiring decision.
The hiring team should consist of the colleagues and team leads who are likely to work with the candidate later. Seniority can help but isn't required. We should strive for diversity in the hiring team to reduce bias. The hiring team has a hiring manager who is ulimately responsible for making the decision whether we want to hire or not.
The responsibilities around hiring are split as follows:
HR does:
- inital communication
- clarify basic requirements (e.g. does the candidate fulfill a hard language requirement?)
- help with visa stuff
We do:
- schedule invites to video interviews or in person interviews
- send rejection letters
- candidate review and selection
- the video interview
- the main interview
- the hiring choice
Christian does:
- join the hiring teams
- contract and salary negotiation
Our hiring process consists of the following steps:
We use personio.com for candidate screening. HR uploads every application there and the hiring team will get email notifications for every new application and every comment on an application. Recruitee is the main tool for discussion around candidates and for documenting decisions and next steps. Therefore, if you have a comment about a candidate or the team would like to go ahead with the process, add a comment in personio, rather than writing separate emails or slack messages.
2. Hiring team reviews the applications and decides which candidates to reject and which ones to proceed with.
The hiring team uses personio (or for minor discussions a parallel slack discussion) to comment on their thoughts about applications. The goal is to decide within no longer than 5 days, whether or not we want to continue with a candidate. You can use the thumbs up / down and comment feature in personio to vote on this.
After 5 days we should have reached a decision and whether to invite the candidate to a video interview or to reject the application.
What we should look out for at this stage:
- Does the candidate have the skills and expertise we are looking for?
- Do they have anything visible they can show (e.g. github projects, public reference projects, etc...)?
- Does it look like a mass application without specifically mentioning Liefery or what we do?
- Have they learned or worked in a comparable environment (e.g. too enterprise-y people might have a hard time adjusting to our process)
Depending on the amount of applications we get, it makes sense to relax the criteria or be extra picky at this stage to influence the candidate pool size to an amount we can manage.
If we decide not to continue to work with a candidate, we'll send an email to the candidate.
It payed off to use zoom for the video interviews as the setup is very easy and nobody needs to create a new account (for example for skype). In case we decide to continue with the candidate, we schedule a video interview including the zoom link and ask the candidate to install and test the app in advance. It makes sense to have the same person do all or most of the interviews to compare candidates. If you are unsure about doing an interview alone, it's totally OK to do it with 2 people, but not more to avoid intimidating the candidate.
The video interview is a 20-30 minute call in which we present Liefery and the type of work and challenges we work on at Liefery IT (about 5-10 minutes). This is important because at this point we are doing a sales job (getting the candidate interested in working with us) as much as the other way around. This also helps take some of the tension away by not putting the spotlight directly on the candidate.
In the second part we ask the candidate to tell us about themselves, about their previous projects, what their individual contribution was, the technologies they worked with, etc... This part should be mostly free form (let the candidate say what they want to say). Eventually, if they haven't said this yet, direct the question to how they worked with the technologies we want to hire them for. Ask them to describe collaboration environment and development process at their previous project and what they would have changed if they could.
Things we are looking for at this stage (not a complete list):
- do they seem to have the required skills and technologies we are looking for?
- A general impression of their competency (adjust for nervousness and introversion)
- did they know / care about why they doing what they were doing?
- do they seem like someone we would like to work with?
- do they care about the collaboration environment they work in?
- are they "just talkers"?
You should end the call by thanking the candidate for taking the time and let them know that we will have calls with a few more candidates and that we will get back to them about the next steps. If possible (depending on how far we are in the canditate review process) let them know how long it could take until they hear from us.
We invite each candidate that passes the video interview to our main interview. Please make sure to announce the interviews to the team so that everyone knows who is coming and can contribute to a nice welcome. This is a 1.5 - 2 hour long interview that digs deeper into the candidate's previous jobs and responsibilities, their technical knowledge and experience in software development practices. The candidate does a coding challenge on their own computer in a language and programming environment of their choice.
Our interview loosely follows the following 3 phases:
- (~30 min) questions to the candidate
- introduction
- questions about the candidate's prior work experience (describing previous job responsibilities, projects, ...)
- technical questions
- (~30 min) coding challenge
- (~30 min) questions of the candidate
- questions
- wrap up
This is not a strict linear sequence and it is totaly possible to jump back and forth.
An interview should not feel like an interrogation or a competition in knowledge. Ideally it should feel to both sides like a friendly, respectful and interesting conversation among peers. It is mostly our responsibility to create this kind of atmosphere. Creating a friendly and respectful atmosphere can mean to greet the candidate in a friendly way, not let them wait or sit around on their own, offer them water or coffee to drink, give them a brief tour around the office, etc... In the interview it can mean chosing a sitting arrangement where the interviewers are not all sitting opposite to the candidate, but rather create a semi-circle around them and occasionally face each other and interact with each other. It can also mean paying attention to your body language (sitting in an engaged position rather than leaning back with crossed arms) or nodding in agreement with the candidate.
Some candidates might be very nervous or quiet. In these situations it is extra important to set a friendly atmosphere to give them a chance to relax and not be paralyzed by the interview situation.
Setting a positive tone has multiple positive effects. It will leave a positive impression on the candidate and will make it more likely that they appreciate this as an environment they would like to work in and it also makes it more likely that you will learn more genuine things about the candidate if they are less nervous.
As part of the introduction we should also encourage the candidate to use the interview to ask us questions if they have any.
In general we should always prefer following the "flow" of a conversation over sticking to a scripted set of questions. However, if the flow stops, it is good to have a list of scripted questions to hang on to and to hopefully kick off a new "flow".
A good set of opening questions is to ask the candidate about their last projects:
- what were your responsibilities?
- what were your contributions?
- what was the project about?
- what was the business goal?
- how would you describe the development process?
These should ideally be easy questions to help the candidate into a "flow". At this point it can be interesting to ask them about points of frustration in their previous project and what they did to change that or what they would have changed if they had the authority to do so. A candidate that tries to address their frustrations and has improvement suggestions gets bonus points.
From the previous job we can also go back further to previous projects if they seem interesting or if the candidate wants to talk about them.
The goal of this part is to find out:
- Did the candidate work in similar environments to ours?
- Do they have experience relevant to us?
- Do they care about the development process? Do they have opinions on what a good process looks like?
- Do they try to change things that are not going well?
- Do they care about the bigger picture (e.g. business goals of what they are working on)?
After this section we typically move into more technical interview questions.
In this part it is especially important to not make it feel like an interrogation. It can help to wrap a technical question into a problem. Rather than asking a direct question "What is X" you could ask something like "Assume you are trying to do X, how would you approach that?".
When a candidate does not know the answer to a few successive questions, they will inevitably get nervous. When that happens, intersperse a few easier questions to help them regain confidence or to adapt the level of questions to their knowledge level.
Coding challenges have a bit of a bad reputation in the industry. That is because they cause a high level of stress in the candidate and they are often done poorly.
It is very important to take as much stress out of the situation. We should let the candidate know that we are aware that this is a very stressful situation and that we are taking this into account.
Make clear that the goal of the challenge is not to test deep algorithmic knowledge but is rather meant as a conversation starter about good code, different ways to implement things and how to make choices. Invite the candidate to take their time, not to rush, to speak their thoughts, use the internet and look up documentation as much as they want and to ask us questions if they are stuck.
The coding challenge should be an easy enough problem to solve that ideally has a few interesting implementation choices to make. It should be extendable with "new" additional requirements that will add complexity and potentially force to change the initial design.
We have a list of Coding challenges we usually use.
It can be that the candidate struggles and paints themselves into a corner. In this case we can stop the active coding and switch to a conversation about what likely went wrong and how to do it better.
What we want to find out during the coding challenge:
- Do they know their programming language and coding environment and use it well?
- How are their analytical and problem solving skills?
- How do they deal with the inevitable error message or failing test? Do they read the message?
- Do they make good choices?
- Can they articulate their choices?
- Would you accept their solution?
After the coding challenge we should explicitly encourage the candidate to ask us questions about Liefery, our team and our processes.
When we're done we explain the next steps to the candidate:
- We will have a de-brief and discuss the interview and let them know if we want to continue
- We are offering the candidate to come in for a "get to know the job" day where we will show them the codebase and our product and they have a chance to join the team for lunch and meet individual team members for coffee.
- Christian will get back to them about the contract
After the candidate left the hiring team discusses how the candidate was doing.
For evaluating if to hire the candidate this might be a helpful scale:
- 1 - Hire. If we don’t hire we make a big mistake.
- 2 - Hire.
- 3 - Don’t hire.
- 4 - Don’t hire. If we hire we make a big mistake.
Each member of the hiring team can anonymously write down the number and if the 1s and 2s dominate we should hire the candidate.