source : http://githut.info/
This article isn’t just about hiring software developers. It’s about hiring software designers! Engineers who can deal with highly abstract software design principles that will allow them to create robust systems for large scale projects. Let’s proceed …
Uncle bobs ‘clean architecture’ is a great example of an advanced OO design princple : https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
A good trait to find is; developers hate doing mundane and repetitive tasks. There is a good chance they will automate them. Great software engineers work on tooling and meta programming as much as they do the actual programming. Some call this dev-ops but I call it common-sense! It’s good to hire developers with common-sense.
“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” - Abraham Lincoln
This is my favourite. Working with developers who have great command of the english language and can use it expertly to describe complex problems is going to help your project succeed. There is a correlation between how well someone can explain something and how well they understand it.
Check out this little story from Richard Feynman, by two of his colleagues at Caltech in 1989 (after his death):
“Feynman was once asked by a Caltech faculty member to explain why spin 1/2 particles obey Fermi-Dirac statistics. He gauged his audience perfectly and said, “I’ll prepare a freshman lecture on it.” But a few days later he returned and said, “You know, I couldn’t do it. I couldn’t reduce it to the freshman level. That means we really don’t understand it.”
Ok, dependant on how much the candidate wants the job you may be able to get them to spend an hour or two on an exercise before they come in.
Idea 1 : Get them to present techniques they used to decouple various parts of their application in the past such as data transfer (JSON) from the user interface
Idea 2 : Ask them to show the architectural patterns they have used to handle the update and refresh of user interface components when application models are updated
Technical testing is fraught with problems so we need to look first at how NOT to do it. The purpose of a test at interview stage is for two reasons :
Hiring teams often buy or design a technical test which they feel fulfills those objectives and then they place a time limit on it such as 1 or 2 hours. This is a completely arbitrary and biased approach to testing someones ability and has actually been found to be the wrong way according to research:
In 1998, Frank Schmidt and John Hunter published a meta-analysis of 85 years of research on how well assessments predict performance. What they found was that the best predictor of how someone will perform in a job is a ‘work sample’ test. This entails giving candidates a sample piece of work, similar to that which they would do in the job, and assessing their performance at it.
source see the results here
What I recommend is that new developers are tested using a pair programming exercise. They can work with one or more of the current developers on the team. This should be an exercise to accurately gauge how they work and whether they can contribute working software.
You can either design a test which covers the key areas (which we covered in our ‘traits’ section), or if you are really adventurous why not work on a real user story with them?
Avoid algorithm based tests unless this is genuinely a pre-requisite for the job. Companies love giving them to candidates but in most cases the tests prove nothing about Object Oriented business software. They are a separate skill in their own right so treat them as such.
Don’t set time limits on tests. Not only does this make the candidate rush (leading to increases in mistakes) it will also force you to evaluate them in the incorrect order. You should be looking to evaluate their quality of their work before how fast they deliver, since delivering rubbish code is worse than delivering quality ‘late’; is it not?
If you are opting for the pair programming test just tell them you expect not to finish it. If you give them a test to do in their own time then let them have as long as they want.
In the real world all developers have access to the net. Cutting of the internet is forcing them to recall from memory which will impede their ability to write software as effectively. If this happens you are testing their memory not their skill.
If you leave them with a solo test they should have access to the internet. This should place the burdon back on you to create a test that is sufficiently complex enough that it can’t just be ‘looked up’ and thus you will create a better test too! (Not making this easy for you am I?)
Remember, you are looking to test their ‘actual’ ability to write software. Not their ability to complete tests or carry out instructions. So structure your tests against real world objectives as opposed to artificially constructed ones.
A study in 2008 by sociologist Lauren Rivera found that when interviewing people the sample set of interviewers (made up up by bankers and lawyers) typically (and unconsciously) tended to hire people like themselves.
This worrying trait is unfavourable to a hiring process for an organisation because it limits what I like to think of as “cognitive diversity”. Cognitive diversity is important because it means you have lot’s of different types of thinkers, these ‘thinkers’ when put together in a team; will be more critical of each others work.
Matthew Syed covers the topic of teams being critical of each other in his book Black Box Thinking.
In it, he refers to an experiment conducted by Charlan Nemeth, a psychologist at the University of California, Berkeley, and her colleagues. She took 265 female undergraduates and randomly divided them into five-person teams where she measured the effect of having them work in both critical ways and non-critical ways together. The results were startling. The groups with the ‘dissent and criticise’ guidelines generated 25 per cent more ideas than those who were brainstorming (or who had no instructions)!
In order to remove your bias when asking questions you should do the following three things :
For each candidate you simply add up their scores at the end. The important thing is to have an interview that is structured and scoring like this will help. This allows you to remove bias from the ‘questioning’ part of your interview and will allow better people to come through your interview process.
In my own personal experience the icing on the cake with finding people to work with is about you making a decision made on your gut feeling of ‘team balance’. You have to weigh every hire up against the general flavour of the entire team too. The key here is diversity. Hire some introverts and some extroverts.
Ok, now my favourite part of an interview. Be warned; this is for mature interviewers only. Asking someone else for feedback on your own teams work especially when you are interviewing them totally flies in the face of convention. In the typical setting the company hiring is the one who decides what is ‘right’. I appreciate opening up your code base so a developer can critique ‘you’ instead of you judging ‘them’ is probably a million miles away from the mindset most hiring teams are using.
However, there is a very good reason you should break the mould here;
Ask them to make a list of improvements they would suggest to make the code more readable and maintainable. Ask them if there is anything they can spot in the code that could be improved. For example:
Even if they only pick up one or two improvements this will tell you a lot about the sort of skill level they have in being able to read large and complex code bases.
Simply allowing a developer an hour or two to look at the code they will be expected to develop and maintain says a lot about your transparency and openness as a team. It’s beyond me why this isn’t done more by companies. Writing an NDA would be a trivial affair!
Interview processes can be a great way to establish a ‘specification’ for your team. By improving interview processes organisations will not only find it easier to convince the right engineers to join their team but they will also learn a lot about what their teams actually need.
I hope you have enjoyed this article/guide, feel free to write questions below or connect with me on LinkedIn where I post regularly. Happy Hiring :-)