Efficient 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 (Example). 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.

Example Conversation

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.

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 behavior 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.