There are several ways to go about selecting a developer for your project. In this article I will run through some techniques that I use when selecting a developer. In all honesty, it is similar to interviewing someone for a position. You want to find out about their backgrounds, techniques, ability to innovate, past jobs and personalities. Since there are dozens of developers out there, it can be hard to differentiate them by just looking at their websites alone. I have created an interview process to filter out inexperienced, overpriced and understaffed developers.
I initially start off with what I call “Pre-PowerPoint Questions” to help me filter out the amateur developers. I ask them questions pertaining to their specific expertise, company organization and their preferred approaches to certain problems. Depending on your background, you may either know exactly how you want your project done – for example the coding languages or systems used – or you may just have a rough idea of what needs to be done and prefer to let your developers decide on the best approach to take. Either way it is a good idea to find out the capabilities of the developers in terms of ancillary abilities such as programming languages or expertise in marketing and design and also what certifications they possess. Additionally, it is a good idea to find out if they outsource their work or if it is all done in-house. Be wary though, some unscrupulous developers will tell you that work is done in-house but still might get their work done out of the country in places like India, China or Russia. Since they have an office in these locations and hire developers to work there, this is technically considered “in-house”. Of course, just because work is outsourced to another country doesn’t mean that it’ll be of lower quality, it just means you have to pay close attention to their organizational structure and track record. If they have a good management system with proper organizational structures in place such as Project Managers and Department Heads etc, they will usually have fairly reputable work. After you determine their organizational structure, it is a good practice to go through and find out the entire development process from hire to finished product.
After I get these preliminary questions answered, I have a PowerPoint that I show to them to summarize my project requirements to help them get an idea of what is required without bogging them down with unnecessary detail. I usually present the PowerPoint in a Go2Meeting session to avoid wasting precious time travelling. I do however, eventually go to see their office and setup to verify what they have told me. During my PowerPoint presentation I will be asking them questions regarding how they would specifically handle certain situations, or what software they would use. At this point I’ve noticed many developers put me on a pause to get their actual programmers on the line instead of their sales team to help answer the technical questions. This is beneficial as you get a first-hand experience of who you are really working with. Throughout this presentation I will ask them questions such as, “If you discover a blank page, what are your protocols to discover the problem?” or “Which coding languages do you prefer? What are the shortcomings of these languages?” I could supply you with many more questions but they require some technical background otherwise the answers you receive will be meaningless. At some point I will create a post detailing some questions to ask and what sort of answers to look for.
After the presentation I usually give them a set of “Post-PowerPoint Questions”. In these I ask for: references whom I may contact, samples of their best work, a list of project personnel and the project investment breakdown. The project investment breakdown includes a rough price quote, some developers will even give you an itemized bill if your features aren’t too unique, and a timeline breaking down the ranges of work needed. In addition to these questions, I also ask very specific programming related questions to make sure the finished product will be optimized for performance, presentation and bandwidth utilization. This is another area in which I will definitely expand on in future posts. After this set of questions are completed, I go through legal issues, troubleshooting, maintenance procedures, any additional work that I may need and edits/changes to the bill.
Even with this outlining of my personal interview strategy for developers, you still have to constantly apply an OODA mindset to it, constantly improving and altering your approach. There is no single perfect approach. As always, I would definitely love to hear from anyone who would like to detail their experiences and strategies.
