Web, Mobile and Software Consulting from a Cornell Bred, Intel Vetted Senior Software Engineer

Vetting A Technical Consultant – The Integrity Interview

Most non-technical entrepreneurs desiring to build a product in technology face a big conundrum – how do I hire a good technical person for my startup. How will you know whether your contractor possesses the knowledge required to build your project and, much more importantly, whether they will create your technology in the most efficient, bug-free manner.


At first glance it might seem an entirely valid approach to send the developer an online test – there’s many floating around there. But, not being technical how will you know what skills the test is gauging and, further, whether it is gauging all of the skills your developer will need to perform the project. Most developers agree that the tests being given to them are not even applicable to the job they will be doing nor test the necessary skills. The problem is that the time constraints of these tests forces them to be very close-ended. It does not give the developer the ability to showcase the breadth of what they know. And, further, it doesn’t tell the client whether the developer has the skills to work on their specific project.

With over 12 years of experience, I’ve discovered that a much better approach is gauging the work relationship with your potential developer with a small project relating to your business venture after gauging your developer on work-mesh-fit.

Here’s the full approach that I’ve found works the best…

1) Interview your prospective developers by gauging the most important asset – integrity. At first it might seem it could be hard to gauge someone on a characteristic such as integrity. However, it gets much easier when directed by a few questions that have to do with their past experiences. The more open and honest the contractor is about sharing their experience the more you know they’ve had a great working relationship in the past. The more detailed, the more you know they have thought about the importance of a smooth working process and have focused to hone it over the years.

Here are a few questions that will open up the conversation:

  1. How did you structure your contracts with past clients?

    This can tell you a lot about how the developer thinks in terms of their working relationship with you. Being a consultant is not just being a developer. It requires a deep focus and understanding on the client’s needs, not just on building the most technologically advanced apps. If the contractor has not focused on the client’s considerations of risk-aversion while constructing a contract, why not? If the developer has not structured contracts in the past, or if the idea is foreign to them, it’s an inkling that this is not a serious business to them and more of a hobby or a side-project. Being such is not a great sign that the person will be dedicated to the completion of your project, building it with great development concepts, choosing the best technology choices based on YOUR needs vs their own desires to play around with new technologies, or communicating clearly with you on the progress.
  2. Talk to me about the communication structure you have had in the past with your clients and the structure you like to have.

    This is a great gauge of whether the person understands that the project is all about you and whether they’re building the technology to your specific desires rather than taking the project and making their own decisions without consideration of your need. Developer many times believe that the technology itself is the only work. Never is this ever the case. I talk more about this in my article Where Business Meets Technology. Without a clean communication structure development time could start increasing as the developer builds in unnecessary code, builds features that you did not ask for, builds features to assumed specifications that need to be re-developed, and much much more.
  3. Did you work off of a set list of detailed tasks to complete?

    This is yet another great way to see what working with this developer would be like. If a developer tells you that they do not need a lot of detail, this is usually a sign that they either have not done a freelance project before or do not understand that the most important person guiding the features of your application is you. All developers need to ask a lot of questions on a lot of different details to be able to know what to include in your application and what to not waste time on. No applications are alike. If a developer has built an e-commerce app, for example, it does not mean that all the features and details of a different e-commerce app will be the same or even needed. It all depends on the particular need of the business.
  4. Which technology would you choose for the project?

    Beware of fast answers to this question. Many developers will simply recommend a technology they have worked with in the past since it will be the easiest to work with for them. And, statistically speaking, it will not be the best technology for what your project needs. Look for a discussion here that compares the different languages, frameworks, etc. and why the chosen one is the best for your business. It is also a great sign if the developer says they would get back to you on this as this decision is not a simple one and much better guided by preliminary research and thought.
  5. If you have not worked with this technology before, are you worried that it might impact the project and how will you approach the learning curve?

    This is one of my favorite questions. There’s an idea floating around there that learning a programming language is like learning a language like Spanish. In fact, there are many more differences than similarities. To explain this would take much more than a simple comparison. However, the most important take-away is that an experienced developer – with more than three languages in their tool-belt – will take quite a short time picking up a new language. There are many similarities between programming languages and once you’ve learned a few it is much easier to pick up another. A new developer, on the other hand, simply will not have the experience to quickly and successfully pick up a new language. Listen to the confidence when your prospective freelancer answers this question. Listen for whether they have done so in the past and have absolutely no worry in gaining new experience. Listen for a structured approach in picking up a new language as well. If they have done it successfully many times in the past they most definitely have a structure they are confident in.
  6. Would you be willing to do a small project?

    Which takes us to the next section.

2) Give one or two of your favorite consultants, vetted by the process at the top, a small real-life project. Rather than wasting time with an online test as mentioned above, see if the developer will be able to actually work on a specific task at hand as it relates to your project. Now, many developers might be opposed to the idea as it could be a way for the client to get some free development done and not even end up hiring the developer in the end. The way to mitigate this is by only limiting this test to a favorite developer of your choosing. This is why we perform the integrity test first. Making the test as short as possible would also help out this cause. To even further focus the process with integrity, get this potential developer involved in creating the test. This provides for a much more natural, no-bs way of gauging each other. In the end, after the small project is completed and the developer is working out perfectly, there is no reason not to pay the developer for their time on the project as you will end up using the code.

3) While working with the potential developer on this small project, use this time to gauge the working relationship. Gauge communication skills which include how well the consultant explains challenges of the project, timeline, milestones reached, etc. Your developer should be willing to explain everything that you ask because they are going to be the only point of contact to your technology. These preliminary conversations will be a good foreshadowing as to how your communication structure will go. Will they be willing to describe the technology to you every step of the way? Will they be open and willing to discuss roadblocks, status of your project, deadlines, etc.

To further gauge the development skills, you can always engage another consultant to review the code. However, bear in mind that many developers have a lot of differing opinions on approaches and styles of coding. It does not mean one is right and the other is wrong – direct the consultant to review the code based on ease of readibility, ability for another developer to take over, commenting of the code, security, holes in logic, consideration of use cases, modularity, not-over generalizing (over generalization and over modularation can lead to lower readability of code and increase the development time of both the current developer and any developers that take over the code in the future).

I hope this approach helps shed light on the challenges of gauging a developer and opens up some discussions on differing approaches. I’d love to learn about the experiences you’ve had while working with freelancers and welcome your comments and discussions.