Odd recruitment practices when hiring software developer

A few years ago, I came across an article that suggested a recruitment practice colloquially referred to as posing the FizzBuzz question, intended to weed out totally inappropriate applicants who clearly didn't have a clue about how to write code.  Personally, I had thought that the idea would cause a minor buzz (pun intended) for a while before it seemed to have finally run its course, and yet I came across a question at http://programmers.stackexchange.com/ that seems to suggest that the FizzBuzz question is still regarded by some as a useful recruitment tool.

I'll admit that I'm very surprised that people actually think that this can really tell them anything at all about an individual's abilities.  I get it that this seems to be a possible way to catch out the new developers who either don't have the talent, or that have crossed over from other specialties with even less talent, but the tone of the original article suggests that it's common to sift through and possibly even interview 100 individual candidates and still need to use this "test".  My question to anyone who has actually used a FizzBuzz-ism would be to ask if they actually know anything about recruiting technical staff at all, and programmers in particular?

Yes, I've actually had experience hiring staff for development roles.  It's an arduous process, and yet one I would never leave to the agencies as you can just as easily do a word-search as the agency can, and save yourself a hefty fee in the process.  The thing is, if you are screening candidates based on keywords, tricks and tests, you'll most likely lose the real diamonds underneath the rest of the chaff.  


The reality is that you will rarely find great candidates applying for your advertised position.  The best developers will already have good stable jobs or will have formed companies of their own.  They are head-hunted incessantly, and likely will step from one choice role to the next before they've even had a need to consider reviewing the recruiting ads.  On occasion however, you'll find the sea-changers who have decided to look at a random job ad or two, and who might find your company and role worthy of their attention. These are generally very intelligent people, who are very good at selling their abilities, and will have gone to great lengths to do their due diligence with regards to your company and the role before even thinking about the carefully crafted application letter that you will receive. They know how to lay out a resume to whet your appetite just enough to have you ask questions that they will be prepared to answer, and they will definitely know their business, oft-times better than you do. If you were to ask such a person to answer the FizzBuzz question, they are also likely to politely comply with your request, and subsequently turn down your offer for employment.  And yes, I mean graduates as well as senior candidates. To such people, the FizzBuzz type of question is not merely insulting, but shows a distinct lack of preparation on the part of the interviewer, and usually indicates that the interviewer is concerned more about triviality than actually performing a complete and objective appraisal of the candidate before them. Yes, I too have had my fair share of interviews where this type of evaluation process was applied to me.  In the early days, I would do as I was told thinking it would increase my chances of employment.  These days however, I will politely terminate any interview the moment I get asked to perform like a mere code monkey.  

Interviews should provide an opportunity to perform a two-way evaluation.  Not only does the candidate need to sell themselves, but the prospective employer also needs to be able sell the position and credentials to the candidate. There should be several opportunities to meet and discuss matters, and to allow existing and prospective staff an opportunity to really get to know each other. You're not simply hiring a coder, but also a team member, and someone who you will be investing a significant effort to secure in a role where they will likely be working very closely with others. If you feel that a coder is all you need, then just about anyone will do as you can train anyone to throw code together and get it to compile.  Even the worst candidates will be able to meet that basic requirement under supervision.  If however, you want someone who lives and breathes software engineering, who is a keen problem solver, and who can communicate with all of the project stakeholders, who can integrate well with any team configuration, and who actually understands the business, then you need to be asking them the right questions and also answering the right questions. This process however should start even before the interviewing process begins.

Give me 500 applications, and I guarantee you I will be able to filter out 400-450 applications on the application letter alone. Of the remaining 50, I will find perhaps 10 resumes worth reading, and of that only 3 candidates that are worth looking at.  If none of these interview well, the next 3 best might be worth looking into, or you might need to rethink your job advertisement and start over.  Of the top 3, you'll know within 5 minutes of meeting whether the candidates have even the slightest knowledge of what they are about, simply by asking them to introduce themselves and the projects that they have worked on.  People who don't get it will give you a lot of spiel about every keyword they think a recruiter wants to hear, and they won't sound very convincing.  The good candidates however will talk about solving problems, and working on projects. Keeping an open discussion will also allow you to formulate questions on the fly, and to see how well the candidates think on their feet.  There are never right or wrong answers, but opportunities to discuss software engineering, and to learn about each other.  Anyone can learn to code, but not everyone is going to be a software engineer in any real sense.  If you asked me to write a FizzBuzz app in Ruby, I'd tell you I don't know how to write Ruby applications yet, but I could easily provide you with some pseudocode if you were that hung up about it and that I could learn Ruby easily if that was a requirement.  If you asked me "How to develop" a FizzBuzz application, then I wouldn't tell you how to code it, but instead how to craft software.  How to engineer it.  I'd suggest an appropriate methodology, and I would ask you what your expectations would be for your FizzBuzz app.  I'd want to know deadlines, and who the various stakeholders are.  These questions will tell you more about me than a handful of lines of code ever will.

The key to hiring great candidates is to look beyond your company's immediate resourcing needs, and instead look into hiring people who can adapt, and more importantly who have the ability to learn. People you could get to fit within your company culture so that you could configure your available resources however they might be needed.  The code prima-donnas who know every GoF pattern, and who throw around their Agile creds will probably struggle to fit into a team of people who aren't exactly like themselves. The software engineers will see things like patterns and agile methodologies merely as tools that they might be able to adapt to solve a particular problem at hand, and will not have fixed views about the right and wrong way to do things.  Coders are interested in creating working code, whereas Software Engineers will be interested in crafting the highest quality of product within a given set of constraints (deadlines, resources, etc...) using whatever tools and skills they have. Whenever I hire someone, I look for innovators and not inventors, problem solvers and not merely people who simply get things done, and above all I look for great communicators and willing learners no matter how advanced or new their skill set may be.