Employing staff in technical roles can be an extremely difficult process – particularly when the person doing the hiring doesn't have an existing technical background themselves. If you don’t have the right background how do you pick people that are not only right for your company and the work that you do, but also that are in turn a right fit for them?
Added to this the complexity of the ever changing landscape of Development for the digital space you can also set yourself up for failure, all those experienced .NET staff you hired but now you’re being asked for more and more work in Objective C and Java for mobile apps? Sure in some cases you are going to get lucky and find the right person, but chances are if you didn't hire the right candidate you don’t have the flexibility to adapt to these changes without swapping out staff – this can be both extremely costly to your business as a whole, and incredibly damaging for overall morale for your company.
Employing the right people helps staff retention: At Mammoth we have around 30 employees. Each one is incredibly important to us, this is why we try to ensure we pick the right people to employ. We have been a consistent company for 12 years and of those, 6 people have been employed full time by the company for the last 10 years, with more to come in coming years.
Of those that have left us who were full time employees of the company for longer than a year – we like to feel that they have gone on to things that we just couldn't offer as a company in the business we are in. Of our developers we have lost several to Readify, several to Amazon in the US, and several to Yahoo!7 in Sydney. We haven’t lost any to other digital companies locally as yet in our 12 years in operation.
Added to this, in the time we have been active we have maintained a very strong and flexible technical ability in any language we chose to work within – or our clients chose us to work in.
With that in mind its worth looking at how we have done this. Firstly it’s worth pointing out that we don’t really use recruiters that much, we do use them for some other roles, but generally they are expensive and internal networks almost always work best for the types of roles we’re looking for.
Maybe is NO: One of the best pieces of advice I have read and have used extensively throughout our time at Mammoth is that a Maybe is Always NO. A good article to read which mostly mirrors our approach to hiring people is Joel Spolsky’s Guerrilla Guide to interviewing (http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html). Almost every time we've hired outside of this neat little mantra, in some cases due to workload, other for more intangible factors its been a complete miss. We have been through two consecutive months of trying to hire, waiting to find a candidate that met the criteria we are looking for in Developers, rejecting everyone – including a lot of maybes.
Have a defined Criteria: Hiring someone on the basis of x years’ experience in CMS’s such as Sitecore or Kentico or experience in any other flavor of the month has not been an approach we’ve ever followed.
It's handy to have sure, it naturally allows someone to get up to speed faster on whatever the current project you’re working on but what happens when that project ends and the next one is something else? A shorter ramp-up time is a false economy, and its almost always better to pick the person who better meets a broader criteria you set over the person that best meets your current project needs.
These people may have a longer ramp-up time but will be far more resourceful in dealing with any issues along the way. Some of the Criteria we set are obviously ones set that you’d see around the place, the requirements in criteria will vary business to business, its important that you consider and have a good understanding of what you need rather than just cut and paste someone else’s.
CV Evaluation: CV evaluation can be somewhat difficult, generally we’ll cull on CV’s so having a good understanding of what you’re looking for in a candidate is important in this evaluation process and can save you time. Some of the things we look for are less abstract and reflect in our belief a display of passion for development, we’re completely uninterested in people who simply develop for a day job. This is generally expressed by signs of self learning on new technologies – Its important the person reviewing these have an understanding of fresh new technologies themselves – another good one is looking for Blogs that they follow and stated experience in things like specific ORM’s, TDD and Agile practice experience.
Testing the candidate: Testing the candidate is one of the most important things we do, it confirms what we have learnt from the CV Evaluation and gives an assessment on the basis of what we feel is a good candidate for our business. This will again vary from company to company depending on what types of development you’re doing and how its being approached.
For this reason canned testing for Developers should almost always be ignored and a set of questions should be developed by your team to answer questions you feel best represents the type of work you’re doing and the type of questions you think would be helpful.
For Mammoth, we are less interested in specific accolades and learnings – we have rejected PhD candidates, and employed people with no degrees, simply because we have a thought out process that works for our company and gives us the most flexible developers. When developing our internal test we later go back and seeded the test with existing developers, we rank score on a few simple things, 0=not asked 1=wrong 2=right track 3=correct.
Where a person is having a problem with a group of questions we simply skip it, its just a test designed to give us an idea on their skill set not knowing a group of questions isn't such a bad thing. On average of the 50 or so tests compiled to date the average is around 2.5 for all questions.
The Questions
As stated above our questions aren't such a big deal – since they are specific to your business, but as we are looking for developers that are able to display an understanding beyond specific languages we work in we ask for things that reflect this – for a given .NET developer we ask questions ranging in several area’s HTML, C#.NET, General programming, MVC, WebForms, SQL, Libraries/Tools, and General Knowledge.
Some of the example questions are What is AJAX? AJAX is asynchronous: explain the difference between synchronous and asynchronous? What is boxing? Why is it needed? Explain the factory design pattern. Explain the singleton design pattern Etc.
The Interview
Once our questions have been answered we already have a good understanding of the strengths and weaknesses of a given candidate, based on the CV we have an understanding of a candidates specific experience in work, the interview at this point is to check out personality and general fit, give them the opportunity to expose specific experience outside of that , and for them to elaborate on what they want out of a role with us.
As part of the interview, we have drafted though a run sheet for each interview which we go though that gives information on us as a employer, what we want to hear from them and all the boring stuff that is easy to forget when you’re actually talking to someone. In the interview we’re generally looking for a broader idea of how a candidate likes what they do, if it’s a hobby or a job and how passionate they are about it.
We really do like passion but also we find it important to point out that we try not to abuse it either. We are always sure to point out we don’t ask staff to work weekends and we don’t work back during the week. Discussing your work practices during the interview process is the best way to ensure that not only the candidate is good for you but you’re also good for the candidate as well. This is as important a consideration, what you don’t want as a company is to invest time and effort training someone who isn't committed, you have already made your commitment the moment you start paying them.
In Summary
This is effectively our hiring process that we have evolved over time during the last 12 years. We feel that it really does give us the best employees for us, but human factors mean that we don’t always get it right, we occasionally get it wrong, but dealing with those head on is the best approach to ensure continuity in our organization at least. Our general knowledge questions and specifically our instance on an understanding of general pattern theory helps us achieve flexibility in our staff. It allows for people with only a high level understanding of .NET but more specific experience in other languages such as C++ and Java can come into our organization and with a small amount of ramp up time be a valued and flexible employee in the future.
