Guide to Hiring Developers

cheetah100 profile image Peter Harrison ・1 min read

Some time ago now there was an article on Slashdot about how to find good developers. Here are the primary points of the article;

Positive indicators

  • Passionate about technology
  • Programs as a hobby
  • Will talk your ear off on a technical subject if encouraged
  • Significant (and often numerous) personal side-projects over the years
  • Learns new technologies on his/her own
  • Opinionated about which technologies are better for various usages
  • Very uncomfortable about the idea of working with a technology he doesn’t believe to be “right”
  • Clearly smart, can have great conversations on a variety of topics
  • Started programming long before university/work
  • Has some hidden “icebergs”, large personal projects under the CV radar
  • Knowledge of a large variety of unrelated technologies (may not be on CV)

Negative indicators

  • Programming is only a day job
  • Don’t really want to “talk shop”, even when encouraged to
  • Learns new technologies only in company-sponsored courses
  • Happy to work with whatever technology you’ve picked, “all technologies are good”
  • Doesn’t seem too smart
  • Started programming at university
  • All programming experience is on the CV
  • Focused mainly on one or two technology stacks (e.g. everything to do with developing a java application), with no experience outside of it

Posted on by:

cheetah100 profile

Peter Harrison


Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.


Editor guide

Hi Peter,

Some of the negative indicators are debatable. For example:

Started programming at university

For many students in my country (India), there is no access to computers in schools. University is the first exposure to computers. Penalizing people for this seems counter-productive at best.

All programming experience is on the CV

This ignores people who work in industries with strong NDAs e.g aerospace, defence. For such candidates, the only way to show expertise is to mention on CV

Happy to work with whatever technology you’ve picked, “all technologies are good”

At the end of the day, a professional developer solves business problems. Tools and technologies are a means to an end, not an end in themselves. Getting fixated on particular tools may put you off track from solving the problems. It is true that some tools are better for particular situations but in many places you do not have the freedom to decide that.

Programming is only a day job

This assumes that programmers have no life outside of programming. A person can have other hobbies than coding.


So, one needs to remove some of their projects from CV and casually mention them during an interview to be a more desirable candidate?

It seems like everyone wants rock-star-hacker-ninjas developers these days. They are rare.


We are talking about projects done on your own time for your own enjoyment, projects which don't usually make it to the CV.

The article was not really intended as a definitive checklist anyway. But I've covered in other articles how as an employer practical demonstrable evidence of competence is better than a few lines on a CV.

This is less about wanting a rock star and more about wanting to work with people who have a genuine pride and passion for what they do. In my experience this is the difference between adequate and amazing.

However, individual characteristics are only part of the picture. Good people can have their spirit crushed, so as employers we are challenged to create teams that are enjoyable, challenging, fun and fulfilling.


I think his point may be that your knowledge extends even beyond what's on your CV. 🤔


This was a bit of sarcasm from my side.

I apologize - I didn't see that 👎


It really feels like these indicators are not so much measuring the likelihood of being a good developer as the likelihood that someone grew up in an affluent household and doesn’t have dependents. I’m sure these indicators have been successful in identifying and perpetuating a static and homogenous culture. These people probably are good developers! But I’d just be careful - I don’t think you’re checking for the things you originally intended.


I have to disagree with quite a few of the negative indicators mentioned here.

Programming is only a day job

There's nothing wrong with programming being a day job. People can have different hobbies outside of work and still be great at what they do. This indicator only strengthens the stigma that all developers should be geeks who live and breathe code, and nothing else.

Doesn't seem too smart

This is just common sense. You always try to hire adequate and smart people, more so in a field like software development where the primary goal is to solve problems.

Started programming at university

This is a big no from me. I started programming the summer before I started college and I believe to be an above average developer. There are tons of people around me who have started programming at college and they are also great at their jobs. Also, the reason why an individual does not learn programming before college can be literally anything. Not being guided the right way, not having access to enough resources, etc.

This list is not to determine if a developer is just good, it's to determine if they are rockstar level good, and IMO does more harm than good to anyone who reads it. I'm certain there will be developers who will feel discouraged after reading this list and feel inadequate, even though they are good developers and doing their best.

I would love to read the original Slashdot article if you have the link to it.


These came from a certain point in time, so I think things have changed, and so you might be right.

When I was younger I had lots of spare time to code, as I didn't have much of a life outside coding. As I've aged I've got involved with outside communities and coding in my spare time is not as attractive given my other priorities.

Still, we want people passionate about software.

Obviously we want 'smart' people, but my experience has grown i've found smartness is difficult to judge. Someone might appear bright and intelligent yet not have the capability. Quiet people who have difficulty face to face can shine.

The point about University isn't that people who go there are not smart, just that those really passionate about technology would have been involved prior to University.

The common thread here is passion; picking people who care. There are capable, intelligent people around who just don't care, and who treat development as just a job. They may actually be perfectly adequate in a functional sense, but this wasn't about finding adequate.


This strongly discriminates against people like me who didn't have the opportunity to get into software until later in life. Whatever a person's reasons are, there are a lot of good ones for not starting to program until long after university.



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.


Some of the negative points are ideas I haven't come across - but after thinking make sense. "All technologies are good" for example. Having strong opinions about technology usually do come after having experience trying different technologies and discovering which ones work best.

I think one of the biggest negative indicators are around the idea of programming only happens at your job. I get that some people don't have time outside of work, maybe, to build and learn stuff. That's fine. But the devs who do spend their time outside of work building and learning are usually more passionate and growing in their skills etc.

One issue I've come across is not testing interviewees with the actual "stuff" your business does. Who cares about tree traversal? (unless your company really does need that). Take your actual project and put the interviewee into it. Ask them questions about the real code, maybe review a small PRs to test their knowledge. I've found doing that brings out whether the person is actually knowledgable in the stack you are using etc. or not.


I hit all the positive indicator points and yet I can still go for months of meetings and never get one single client who commits to anything! I probably need to live in Seattle or something, it's cold out here on the fringes.


Great article! Unlike the other comments, I agree with all points you mentioned!

Same for the negative indicator.

All programming experience is on the CV

Good devs don't have to show off with all programming experience they might have done. You could have done a big C++ project, Java software years ago, but this isn't relevant anymore since you might have forgotten a lot if you haven't used that language afterwards, or maybe the technology isn't used anymore, or is outdated (e.g. Flash, ActionScript), so they shouldn't be mentioned on your CV.

And I would say, the technologies/languages that aren't relevant for the job description shouldn't be mentioned on your CV. Only the relevant ones and the ones you use on a regular basis.


I agree with: Smart, passionate and communicative. I'm less concerned with how you come by your experience/skills, whether it be through programming hobbies, work or school.

These indicator lists seem most useful for companies that have a consulting business model, and need eclectic programmers to rapidly deliver short to mid-term solutions across a broad range of clients and constraints. (maybe)

However, companies that are focussed on a single product or domain don't benefit as much from the dabbler personality in my opinion. Sure, having some of those personalities on the team is valuable to help introduce new ideas (is the grass greener?). And all developers should be open-minded. However, the vast majority of valuable man hours are spent on extending and refining existing components (UIs, databases, architectures). The best developers for this work are those that can tackle a single problem rigorously and exhaustively, and can stick with something through a long series of iterative improvements. That type of work is not always great resume material or the most exciting thing to discuss in an interview (or legal), but it's often the most valuable thing a humble individual contributes to the success of a product/company.

As long as the candidate meets the basic requirements of the job, then an engaging guide through a candidate's thesis work, or an informed description of complex project they've worked on, would probably gain more favor than a rundown of side projects they threw together or made minor contributions to. Now there are some superhuman developers who have worked at very high depth on multiple projects. If your company can afford them, then hiring them is a no-brainer.


Too bad no one will follow your advice, so developers ⚠beware⚠.

The following may work against you:
  • Opinionated about which technologies are better for various usages
  • Very uncomfortable about the idea of working with a technology he doesn’t believe to be “right”
The following may help your chances:
  • Happy to work with whatever technology you’ve picked, “all technologies are good”

Worst of all, it's extremely hard to judge which way these will affect your hiring, even if you know someone that successfully got hired by the company.
There are no sure signs.

P.S: I sincerely hope some hirers will actually follow your advice. Even if it adds to confusion, it will end up in more healthy and happy workplaces and better products in the long run.