How to Hire Software Developers
Interviewing
Whether you are going to hire a company or an individual software developer you must determine if they are competent.
It is not easy to determine from an interview if the software developer will be a competent and efficient developer.
When we hire our own developers, we don't attempt to do that. We simply put them to work. 90% of the resumes we receive
for employment are not good enough for us. Of the remaining 10%, we put them to
work and after a day or two about 50% will not make the cut. After another week or two another 50% will be shown the exit.
When we hire, we are looking for very bright eager individuals. We usually don't care what technologies they know, and won't hire
ones that claim they are experts in some technology. We also generally don't care how much experience they have. We will put them
to work under the direction of one of our senior developers that have years of experience.
If you have a small business and are looking for the primary developer of your product, you should hire someone with experience.
The experience won't necessarily get you a developer that will implement a given feature faster than an equally skilled but less experienced developer, but the
experienced developer will be able to help determine what features should be developed and in what order (). In your initial conversation
with the software developer, you should make sure that they have gained an understanding
of your business and challenged some of your assumptions and ideas. If they pass that test and seem to have experience then put them to work.
Comparing Prices
Most customers will get estimates from a handful of developers and then compare and choose one. This approach is acceptable for hiring a carpenter but lousy for
software developers. I recently hired a builder to put three windows into my home where there was a blank wall. I had no problem
comparing the estimates because I had no doubt that the different builders had the exact same job in mind. They all knew what windows,
trim and paint would be required. With software, it is completely different. Unless the project is fully specified, each developer will have a different
picture of what needs to be developed and each will be different from what you are
imagining, so you won't be able to compare them on price. This does not mean you
should fully specify the project. Indeed you cannot fully specify a software project.
It takes nearly the same amount of time to specify the behaviour of the program
with words and pictures so that there can't be a different opinion of how it should work as it does to make it. Most importantly, that specification will
change as the software is developed because both you and the developer will learn new things as the software comes alive.
You should simply compare the hourly rate. The hourly rate should depend on how big the project is, so make sure that you ask the price for some number of
developers over some amount of time.
Discussing Your Business
In the initial conversation with the developer, you should have no problem recognizing that the developer understands the particulars of your business situation. The developer
must get a feeling for what type of users will use it, how often they will use it,
whether it is for their own goals or for the bosses' goals. The developer must understand
how you will sell this software or use it to make your business more efficient.
There is no checklist that an excellent software developer can run through to get
the information from you, it is as varied as the different businesses in the world.
An excellent developer will start to lead the conversation to get the information
from you instead of waiting for you to spell it out. The best developers will want
to know what software already exists for this situation and what competitors are
already there. If the developer essentially follows what you are saying and says
that you just need to write the specification and they will create it for you, you
are not getting the best developer.
When you describe your software needs, the software developer should be able to
not only understand your business and the ramifications for the software, they should
surprise you with a deeper understanding of what will be required than what you
originally envisioned. If they don't do that, then don't hire them.
See
User Interface and Project Complexity for an example of some of the deeper understanding
that the developer must have.
This is a conversation I had with a potential customer (PC). They were showing me how their web application works.
PC: Here's the configuration UI where my customers will configure the look for their employees.
John: Why do you have that feature?
PC: When we start selling this to a lot of customers we will need this feature so that they can customize the look by themselves.
John: I have no doubt that you will want something like that when you sell to a lot of customers,
but for at least the next six months you are selling to a handful of large corporations and none of them are going to set this up themselves, right?
PC: True, but we will need it eventually.
John: We should not put any labor into this feature now. I am not saying it is a certain waste,
but new businesses frequently die for lack of money so paying for features before they are needed is bad business.
Also a business built around a new product, rarely ever plays out as you expect. Most likely you will change how the application should work as you learn
to sell it, and get feedback from the customers. So there's always a good chance that the feature won't be needed or
will need to be heavily modified before anyone really uses it.