It’s not about what you know right now, it’s what you’ll know in the near future

Unless you're looking for some really specific skills, hiring somebody purely based on somebody's current skills is the worst thing you can do. In my current position, I regularly get to do job interviews, both for my current client as well as for my employer Aviva Solutions. And while evaluating potential new colleagues, I tend to mostly ignore his or her current knowledge and focus on those characteristics and skills that somebody needs to solve real-world problems in real-world projects.
Mentality and passion have a big part in this. I've met a lot of highly technical engineers with a passion for building elegant and abstract technical solutions. Passion is good because it makes you care about what you’re building and gives you the energy to continuously improve your solutions. But what I've often missed is the understanding that they have certain responsibilities towards their team; building software maintainable by the other team members, keeping track of the work that still needs to be done, or simply the sharing of information with the others. You need to have the mentality to not just make things work, but to make it work for others too.

Another very important skill is being able to quickly find the information you need to solve problems, either online or through your professional network. I would never judge somebody for not knowing certain things needed in a project, as long as they do what it takes to acquire that information as soon as possible. For instance, if you don't have any experience with Git, I would give you a link to a tutorial, article or eBook and expect you to first study it yourself. I've been surprised how much difficulties some people have finding a solution on Google where a couple of carefully chosen keywords would have giving them immediate results. Consequently, having access to the internet, your Twitter network, Github and StackOverflow are a primary need for me. Without it, a client can't expect me to bring the value they pay for. In fact, I'd probably refuse the assignment in the first place.

So what about the culture of our organization? How do you know if somebody will be a good fit with the other colleagues? Each potential candidate has at least two interviews, each with a different pair of people. The first interview is mostly about learning to know eachother. E.g. who is this person? What ambitions and drivers does he (or she) have? Any passions, hobbies or other things that tell more about a person? How well does he express his thoughts and ideas. That will tell a lot about that person. The second interview is there to determine the things I mentioned before, such as skills, structure, mentality and ways of learning. But does that say anything about whether or not that person is a fit for our culture? No, not really. But joining our annual company-wide trip to a Southern European city for a weekend of fun, drinks and reflection most definitely will.

I purposely didn't mention experience yet. But don't get me wrong, experience is extremely valuable. But it isn't the experience with a particular technology or framework that I care about. What I care about is the experience of solving complex problems, the problems you face when introducing new technologies or frameworks, and the experience with the dynamics of people working in groups. So even if you've barely left school, and you have hardly any experience, it's the things I mentioned earlier that we will value. In my opinion, those are the ones that will determine how fast you'll be building up valuable experience.

So it's great to have intimate knowledge on for example OWIN, HTTP and REST APIs, but if you miss the skills to (learn to) work in teams, have trouble communicating your solutions to both technical and business people, or don't really have what it takes to understand the challenges of commercial projects, you're not going to be of much use for us. And the same applies to our clients. Yes, they initially hire us to help them solve specific problems or build great software with the experience we have right now, in the end it's the other skills that will make the project a success. Technologies change, processes change, tools change, and projects change. Your success depends on how easily you adapt and embrace those changes.

What do you think? Does it make sense? Love to hear from you. Just comment below or tweet me at @ddoomen.