re: Guide to Hiring Developers VIEW POST

FULL DISCUSSION
 

What?

I see that you're very much into open source, based on the short bio that's visible on the post and I assume that explains the slant on your post. Generally open source attracts very passionate people and that's what makes open source what it is, but I disagree on some of your points.

I've met some very good programmers who only have coding as a day job, their personal life focus is family and other things. That's fine and they can be as good/bad as those who code on their own time, I don't think it's a strong indicator.

I started programming in uni. Before that I was going down a different academic path at school and it's only when I tried a degree in that when I realised it wasn't for me, reconsidered, and then went on to do a computer science degree. Not everyone is lucky enough to find out that programming is for them before the end of school.

While not "all technologies are good", I'd be happy to work with whatever the company is using if they've invested time into making it work. Would you rather hire someone who comes in and tries to change your entire stack into what they think is "right"?

Right, I've talked about the points I disagree with and I don't want to leave a purely negative comment. Someone who is passionate and can talk about tech once you let them is quite a good sign, it can show a fair amount of drive. Learning technologies on their own and having opinions on them shows they've gone deep enough into them to actually compare it to what they know and value to form an opinion, again something I'd consider to be useful. A breadth of knowledge/experience is what I'd expect from someone, rather than just a handful of technologies on their CV, that would seem artificial.

Anyway, I think everyone will have their own criteria for hiring and it depends on the circumstance. It's interesting to see someone post the ones I disagreed with, could you elaborate on why you think that way?

 

To begin; I welcome different views. This subject is difficult because I'm outlining a way to judge. That is uncomfortable sometimes. Also, I have worked with very good coders who didn't meet my guidelines.

While I was the President of the New Zealand Open Source Society I have also been a professional developer for all my professional career. Open Source attracts people who care about the technology, and so those who have contributed to open source projects have demonstrable skills. Further, because it is open you can review it. This means you can objectively evaluate skills. This isn't possible with private commercial projects.

I'm not saying people who pick up programming in University are poor coders, rather that this is not a positive indicator for passion.

In response to your question about developers coming in and wanting to change the stack, I actually I welcome such challenges. To me the team is equal, and if you can't justify a something perhaps you should re-evaluate. New developers are not invested in the project so they have fresh eyes. Furthermore I want people who are willing to question and challenge rather than muddle through with whatever they are told. I'm missing out detail here; obviously we don't rewrite systems just to please the new guy.

The one thing I have not discussed in this article is that good teams are more strongly correlated to success than amazing developers. Building a team might start with choosing the right people, but without a commitment to giving them the right environment it is pointless.

code of conduct - report abuse