Lessons learned from one year intensive recruiting

The last year in my role as Engineering Manager at ImmobilienScout was characterized by intensive recruiting and hiring. Within 12 months we hired six iOS and three Android developers. At the end we’v built a wonderfull mobile team from 7 different nationalities. Just as wonderfull was the priceless learning about how the tech hiring process could work to achieve the best results. In this post i’d like to share with you the lessons i’v learned during the last year.

1. Hiring is time consuming

Everyone who built a team knows this fact, i just wanted to emphasize it here. In my case i spent 50% of my time for hiring. To fill 9 open position i viewed more than 100 profiles and interviewed more than 50 engineers. Almost every candidate took me more than one working day. This includes 1 hour for studing the profile and checking the references, 1 hour for the first interview, 1 hour for reviewing the coding challenge, 1 hour for preparing the offical interview, 3-4 hours for the official interview and 1 hour for internal discussions and creating the offer.

2. Be unconventional

Finding good engineers in a city like Berlin is a tough job. To be successfull you need to be faster than the others. Engineers who have a job are not necessarily felxible in their time therefore you as a hiring manager have to be flexible. Interviews at weekends or late in the night and outside the office should not look strange in your calendar.

If you have a filled out LinkedIn profile of the candidate do not ask for sending a CV. Sending a CV is annoying for the candidate and in the most cases does not add any value and is only a waste of digital paper.

3. Do not hesitate to approach developers yourself

At ImmobilienScout i worked with a great recruiting team which did an amazing job finding good fits for the open positions. Nevertheless i had good experience with contacting engineers personally. Developers appreciate it a lot when they are contacted directly from their potentially future manager. At the end we are all engineers and talk the same language. In my case 2 of 9 hires (22,2%) were candidates who i approached directly.

4. A noncommittal first interview is always a good idea

I found that a relaxed meeting at the beginning of the process worked very well to have a valuable first impression. I prefered to meet people in person, skype was my second option. Phone calls for the first interview were for me not an option. We know that the smallest part of the communication occures via spoken language and the biggest part of it is body and facial language. The information loss with a phone call is therefore too big. I prefered to do this interview in a relaxed atmosphere in a nice cafe or just during a walk if the weather was good (few days in the year if one lives in Berlin 🙂 )

In these interviews we talked about almost everything including technical stuff and peronal situation and i also answered any question. The decision about proceeding with the process was of course based on the feeling of both of us.

5. The coding challenge

A proper coding challenge could give you good insights into the programming skills and the coding style of the candidates. In my case the coding challenge was to implement a simple mobile app, which accesses a remote service and a local data storage and presents data. The candidate got two days to come back with a solution. The challenge was designed to give the developer a lot of flexibility and free space regarding the implementation and the software quality.

The most important learning in this regard was to be very careful about rejecting applicants only based on the coding challenge. There are multiple ways to write software, and a lot of them are different from the way we usually use in our team. On the contrary impementing the task in a way we did not expect gave us good material to discuss later in the interview.
When we talked about the code in the interview, i always started with the question: What would you do differently if you would had more time for the task. In the most cases was the answer a good clarification for things which were missing in the implementation.

6. The interview

Our on site interview took 3-4 hours and contained mainly 3 parts: a first part with HR talking about the orgenization, attitude and mindset, a second part about technical capability and software developement skills and the last part was a code review for the coding challenge. Of course in each part the candidate had the chance to ask questions.
It was worth it to take the time and participate to all parts of the interview. I found that this was the best way to have a complete picture of the candidate.

I also found that avoiding standard questions where candidates have anyway prepared an answer for, was a good idea. The best questions were those which served as a trigger for discussions and those which were derived from the discussion.

7. The offer

One important component of the offer is the salary. Our candidates came from all over the world and they had different salary expectation. Some candidates had a lower salary expectation than the market average. In this case it was a good idea not to accept their expectation and to give them more than they requested. There are mainly two reasons for that: the first one is that you as manager do not want to feel bad about developers in your team who are underpaid. The second reason is that once your underpaid team member has a better idea about the slary ranges in the country either you need to give him a big salary raise which might need long discussions with the upper management or the HR, or your team member would leave to take another fairly paid job. I recommend to avoid both situations from the beginning by giving developers what they deserve.

In some cases candidates had rejected our offer. Even if you made someone an offer from which you think it is a great one. It could be someone outside there who can make a better one. Accept that candidates could reject your offer, do not take this personally. Keeping good relationship with the candidates is always good. Who knows when and where you would meet them again?

8. Working with external recruiters

I prefered to keep the engagement of external head hunters at the minimum. Unfortionatly, i found that a big part of the tech recruiters out there have no idea about engineering, another part considers developers only as money bags which can code.
I am not saying you should not get external recruiting support, but you should carefully choose with whom you work. In our case 1 of 9 hires was an engineer whos profile was suggested from an external recruiter.

Endnote

Recruiting is a human centric process and should be understood as such.Each individual applicant is a human with a past and a future and did a lot of effort to be in this position, give everyone of them the respect he/she deserves!

For me, it was a very pleasant time, i met many great people and learned a lot.

Image source: pixabay number 849825