How to Hire and Work with Developers

Steve Zehngut, founder of Zeek Interactive, has lived through and heard countless developer horror stories, such as “my project went over budget,” or, “my project is way over schedule.”

The reason for these failures is usually because of poor communications with developers. “Let’s face it, developers are not the best communicators,” says Zehngut, who presented at Silicon Valley Code Camp. His subject: How to hire and work with developers.

The trick, he says, is to manage expectations for both the developer and the client along the way.

Zehngut’s more interested in how developers answer these questions than their actual answers. When interviewing new employees, all Zehngut really cares about is their body language. Are they confident in their answers or are they squirming?

It’s not important that you have all the requirements, he says, but that can you express your passion, and prove that you’re able to learn.

Holding Code Hostage

Some contract developers hold their code hostage as an insurance policy that they’re going to get paid. Zehngut avoids this behavior himself as it does his client no good. “That never turns into a good situation. It’s just not a good client relationship,” he says.

Whenever he starts a project he gives his client complete access to his code. It’s a controversial decision with which many other developers don’t agree. But, Zehngut says, “I’m much more interested in business and earning future business than holding code hostage.” The insurance is really for clients. It gives them a level of security. Should anything happen to Zehngut and his team they can take the code to another group.

He qualifies this “open code policy” by saying it’s only appropriate if you’re in a “work for hire” situation. If you own a portion of the product, you shouldn’t be releasing the code.