I’m reading a lot about how to turn organizations to agile, but there is one thing which is rarely considered: fluctuation. Not everybody likes working in an agile way, so they might eventually decide to leave the company. If you have to keep up the number of resources, you have to recruit, which is kind of hard with the traditional tests and talks.
I talked to a colleague a couple of days back about how we recruit at the moment, and I remembered the thing I did during job interviews 2 years ago. At that time, we had a hard time finding good agile co-workers, because the candidates not only lacked agile skills, but technical skills also. So I decided to send out some technical questions in advance, because I was tired of struggling with basic Java questions. I wanted to know how the candidate thinks, not teach him about stuff he was already supposed to know.
If someone really wants to work at the company and can be pro-active, he will definitely look up the questions sent out, and also may look up the referenced documents. The questions were really simple, like the difference between sets and maps, why to override hashCode() when overriding equals(), etc. The basic idea is that when someone gets a question and looks up the answer, they may look deeper. If someone manages to do this, you can be almost sure that they are interested in their job and will walk the extra mile to improve themselves. For building agile communities inside companies, we need guys thinking like this, not ones who are learning tools, but don’t understand the ideas behind.
I did send questions out for seven candidates at that time, and only one of them had taken the time and had looked up the answers to the questions. Surprisingly, he had even looked up some of the references, too. That interview was one of my bests; finally, we could talk about real things, not struggle with basics. We hired him, and as far as I know, he still works at that company.
This idea is not only for saving time - although my company time is really valuable -, but you can find very clever junior colleagues, too. For example, currently, you cannot expect a candidate who just finished the university to know anything about dependency injection. It is sad, but unfortunately true. The education is a bit behind the new waves in software development. But if I send out some links about dependency injection, and the candidate looks it up, I’ll know one thing: I’ve met someone who has technical curiosity, even if he or she does not understand everything. I’m not interested in whether they know spring, because we can teach them to use it. I’m more interested in whether they understand why we are using it. Having questions about it is even better, because sometimes I think a person is known better by his questions not his answers.
My advise: have a look at your recruiting strategy and adapt it to your agile vision. The idea above may help you, and I’m sure that you can find other ideas as well. One important thing: forget about the traditional ways. They just don’t work in this case.
comments powered by Disqus