Heavyweight approach to hiring for agile teams


As mentioned in the original article How to hire for an agile team I aim to provide examples of alternative hiring approaches. In this article, I will discuss the heavyweight approach, as an example of another side of the spectrum compared to Lightweight approach to hiring for agile teams.

Recently I had a really interesting discussion with a friend of mine, Ruben Knol, who works for a German company MovingImage. They are a Berlin-based company specialized in video management solutions.

He had observed existing hiring process and was annoyed with the pitfalls of the recruitment test. After a serious consideration he came up with a proposal for completely overhauling the test. At that time, company had several stages of recruitment process, and as a final stage, they had an assignment in form of 1 sheet printout, which is pretty much common for the tech companies who have skill tests. His proposal was to replace the existing test with a half-day developer test. He wanted to turn it into an agile mini-sprint and it turned out to be a success.

So, what did they do?

The format was a half-day assignment with a lunch break in between. All the candidates were met with the same agenda:

Instead of having a single assignment, the workload was split into user stories which were too big to be completed in a single day. The goal was not to see the end result of someone’s entire day of working on a test, but also to get insight in how a candidate approaches work. For example, the questions they immediately got answered were:

  • does the candidate split up the tasks?
  • does he see straight away that it’s too much to finish in one day?
  • when does he discover that? is it on the planning or during the standup after lunch?
  • will he say something about his discovery?
  • if he doesn’t finish everything, how will he prioritize the work and why?

You can already see the potential and different questions valid for your context, that could be answered by this approach.

Here are some sample user stories and actual work assignment:

  

Usually individuals were assessed, but sometimes, there was more than one candidate on trial on the same day, so they grouped them together. This grouping provided another perspective – you can immediately see the emerging collaboration assessment opportunity.

To maximize assignment effect, they compiled a list of questions to be asked during rituals:

  • Questions to ask during planning:
    • Do you understand the assignments?
    • Are the designs clear?
    • How will you approach this organizationally?
    • What technologies/frameworks do you think you will use/apply?
    • Do you think it is doable to finish all this stories? Why not?
    • Do you have any questions / is anything unclear at this point?
  • Questions to ask during standup:
    • What have you done so far?
    • What do you still have to do?
    • Did you encounter any obstructions/blockers? What are they?
    • Do you think you are on track / do you think you can finish?
    • (if no) How would you prioritize the remaining work? What do you feel confident you WILL finish / is there anything you know you will not finish and why?
    • Do you have any questions?

One of the main reasons why they came up with such an approach was that previously they had only been looking for people who were super technically skilled. But Ruben wanted for his teams to focus on hiring people that:

  • knew how to work collaboratively
  • were able to prioritize according to business needs, and
  • were willing to learn technical skills in areas where they were not as strong as their teams would like them to be.

One potential pitfall of this approach might be in its length. Not all the candidates might be willing to participate in such a lengthy trials. However, Ruben says that most people that are genuinely interested in a long-term engagement, don’t mind taking a full day to do the trial day. In fact, there were some examples of people snatched away by other companies during the process, but it was generally due to too much time between two rounds of interview and before the trial day. Now they are working to improve this by acting quicker from start to finish with the process as a whole. Generally, after the trial day you are pretty sure if you want to make an offer the next morning or not.

Overall, their conclusion is that the information they got about candidates during the trial day, have greatly improved with this new format.

In the near future they are looking to incorporate some elements of pair programming, to see how good someone is at working together with others. There are challenges to come up with a “fair” way to do so, though – e.g. how to not give a candidate the feeling that he is sitting next to someone that knows the answer and is just waiting for them to catch on.

If you have such a capacity, exercises like this one are really valuable for identifying the most suitable candidates by shortening the feedback loop as much as possible. You get the most relevant information even before you start investing into someone.

With these two examples (both lightweight and heavyweight approaches) which mark the opposite sides of the spectrum, you can always look for the most suitable approach for your context. Don’t be afraid to experiment, since there are no pre-made recipes for every single context. But be persistent, because environment might not be that keen on your enthusiasm. However, with results comes trust. And with trust you can do anything.