Tag Archives: Recruitment

Screening graduates for technology roles

Graduation time again. Newly minted grads will be taking to the streets looking for a job and many may well have applied or being looking to apply for graduate programs at companies both large and small.

These programs may look to rotate recent grads through the different departments over an 18 month to 2 year period to allow them to find their ideal niche or just be a direct pipeline into a single department. Given the current economy, even a half dozen spaces on a graduate program are going to have several hundred application for each space.

This raises an obvious question for a technology company looking to recruit into their development organisation: how the hell are HR, who we all know lack the understanding of what makes a good technologist, able to winnow this ridiculous volume down to something where developers can get involved? At my current client we would love to be able to interview every candidate. Given that we like to spend at least half a day doing an initial assessment, that just won’t scale. Because of this I was asked to help come up with a solution that could be completed by the candidates and/or the HR folk to generate a way of ranking candidates. So: non-technical people assessing technical people? It’s going to have to be some sort of list.
Continue reading

Developers – You are not just the sum of your technical skills

I’ve been pondering the fact that when I started out on a career in development, I focussed on the technical side of it almost to the exclusion of all else. This was especially true for me since I was coming from a non CompSci background after spending years sticking electrodes in people’s heads and doing biological research. This made me painfully aware that in an industry like programming, if you don’t know your stuff you are useless to your team and your company. Worse, you run the risk of ending up a Net Negative Producing Programmer and reduce your team’s output to less that it would be if you weren’t there.

Thus the first few years of a my career as a developer were spent focusing entirely on technical matters. I fought hard for the expertise in the areas that I worked in: Java, JavaScript and C, web development, back end services and multi-threading… the list is long and mostly distinguished (EJB’s… blergh!). I wanted to be that go-to guy for all thing technical and do my part in making my team the best in the company. As a contractor, my skills were the yardstick for how I was judged for new roles so of course I was interested in keeping them up to date.

After a relatively short time it became obvious that this wasn’t enough. Being technically adept is the foundation of our job but certainly not the totality. Even before you get your first job you realise the importance of communication. Not just in communicating your skills to get that first job but then once you’ve got it, then communicating with the rest of your team including the non technical members. This is especially true in an Agile world where you have to be able to tell others what is going on in a way that they will understand.
Continue reading

The Characteristics of a Good Developer

The recent rash of interviews have made me think a little more about what makes a good developer and more importantly, which of these qualities can you try to spot during the interview process. After having a conflab with a couple of other devs and one of the few recruiters I know that isn’t a shark, I came up with this list. Of course this is going to be a personal list but some of the points seem to intersect with some other resources out there so I don’t think I’m too far out there:

  • Polyglot in outlook
  • Able to learn quickly, and happy to learn
  •  Open to new ideas but capable of defending their own
  •  Technically able
  •  An Influencer
  •  A Producer
  •  Not too proud to ask for help
  •  Knowledge across a broad spectrum of topics
  •  Determined

Polyglot in outlook
One of the Java devs I work with recently coded up one of the most elegant solutions to a complex problems that I’ve ever seen. When asked how he came up with it, he mentioned that he based it around some of the structures that Make uses internally. Too many developers only live within the walls of their favourite language and never see what else is out there that they could take advantage of. As a Java house, currently I would have to say that anyone with Scala or Clojure on their CV will be seen far more favourably than someone with just Java and someone with half-a-dozen languages is almost always going to be going places. In fact during interviews I will deliberately ask questions on concepts in languages that aren’t on the candidate’s CV since I want them to at least be aware of these concepts even if they have never used them.

Able to learn quickly, and happy to learn
As a self-confessed knowledge junkie, I love learning. In fact I find it hard to comprehend what other developers do not. Given that we are in a knowledge industry, those that do not have a thirst to learn will find themselves going the way of the guys who thought that punchcards and ticker tape would last them a lifetime.

Open to new ideas but capable of defending their own ideas
What is the point of having great ideas if you don’t have the ability to defend them. Developers tend to have robust opinions about how things should be done so you have to be able to defend what you think is right. Otherwise you are condemning yourself to work on projects where you spend your time muttering to yourself “this could be done so much better”.

Technically able
You have to bring skills to the table. You can be the greatest person in the world but unless you have the technical chops to be able to develop you will just be a drag on the rest of the team. Don’t be the Net Negative Producing Programmer

An Influencer
This is the pro-active side of being able to defend your own ideas. You need to be able to change or at least shape the ideas of others and have the communication skills to do so. Especially at the level of senior developer or above, you have to start spending time educating and influencing others. If you fail to do this, all you are doing is making your job harder. You have to be able to prevent small problems blowing up into big ones and if that means you need to sell your ideas, then that is what you do. If you are a Senior Developer and above, I expect you to influence your workplace. For example, if your current employer does not use a Continuous Integration Server like Hudson/Jenkins or Bamboo, you have failed in your responsibilities if you cannot convince them that they should.

A Producer
Seeing someone’s work on something like Github gives me one of the best insights into what sort of programmer they are. Ultimately, it’s the Quarterback problem, it’s practically impossible to judge someone’s ability until you see them in action. The closest thing you can get to seeing them in action is to see the results of previous work and this is why we have a technical test as part of our interview process. And before you roll your eyes, we’ve made sure that the test is directly related to what we do and isn’t just some random logic puzzle. If you are already on a team, make sure that you take time to look at your work and check to see if there is anything your should be doing or anything you should not be doing that would improve your productivity. I knew of an Architect at a recent company who was obviously very bright but was unable to produce anything.  He literally produced nothing but ghosted around on his domain knowledge and reputation when he actually contributed nothing to the teams in his area.

Not too proud to ask for help
If you get properly stuck on something, no one will think worse of you if you ask for help. You will drive your team mates mad if you disappear off and take days with a problem, especially if one of them immediately gives you the answer that would have saved days. Your colleagues will quickly realise that the people who have to cover for you getting stuck is them.  The only time people will think less of you is when you get stuck and don’t even bother to try to figure it out yourself before you start asking for advice.

Knowledge across a broad spectrum of topics
Depth of knowledge demands breadth of knowledge. It is impossible to be an expert in one area without having a degree of expertise in others. The ability to link concepts is hugely important and if you already know something similar, even in an unrelated field, learning something else will be so much easier.

The tired old saw of ‘when the going gets tough, the tough get going’ aside, you have to have a certain cussedness to succeed in programming. Spending hours trying to pin down an elusive race condition or tracking an issue through layers of network infrastructure, web servers, caches, web services and database code means that you can’t be someone that throws in the towel early. Also, there are always going to be times when you are going to have to put in some extra work. Whether it is an approaching deadline or a sudden change in project priorities or roles, no one is going to thank you if you can’t manage your focus. If you are known to meet challenges head on, your team mates will always be there with you and will always have your back. If you have any tendency to slack off, you colleagues will leave you high and dry and I wouldn’t blame them at all.

I should also say that this also applies to situations where management are asking you to do ridiculous things. If the higher-ups have you on a Death March, I don’t want someone that meekly caves in an agrees to late nights and weekends in the office without seeing if it is the right thing to do. Determination is not the same as working insane hours and sometimes people need to remember that.

I was also going to put in something about leadership. This is a hugely important skill but you can be a very good developer without it so I felt I could leave it out without it being to big an issue.

Anyway, that’s my list. What do you think?