Back in 2006 I was resigning from a large IT consulting firm to become a partner in a newly created company Farata Systems. During my resignation meeting with a top manager of that firm I asked if he could give me any advice with the new company. He said, “I’ve been managing hundreds of IT people and learned an important lesson – don’t try to hire only the best and the brightest. There are lots of people of various level of expertise in our industry, and they can do the job”.
Since then, I’ve been doing a lot of interviewing and hiring. Our software engineers successfully work on various IT consulting projects as well as on our own software product development. The vast majority of our people work for us for years, which is very impressive given the fact that many of them work remotely from Eastern Europe, where software developers are in high demand. But last year we’ve fired about the half of newly hired contractors. We’ve fired about 15% of people working for our company.
All of them were good software developers. But they were not good enough. When a new hire joins the team working on a project he needs some time to learn the codebase and the tooling. But we expect a person to become productive within 3-4 weeks. If this doesn’t happen, this person becomes a burden for the team. Not only he doesn’t deliver, he requires other team members’ time. We simply can’t afford this. Firing costs us dearly, but we prefer giving such people two-week notices and start hiring again. We want the best and the brightest.
You may say, “You don’t know how to interview people to weed out those that are not a good fit.” It’s not that easy. We are not Google – a dream company to work for. We don’t have candidates camping out by our doors with job applications. We pay better than others, but this is not good enough in the offshoring countries, where many developers would rather work for half pay as employees of the large body shops than as remote contractors. I don’t blame them, but this is a reality we have to deal with.
Unfortunately, the fact that the candidate did well during a couple of phone interviews doesn’t mean that he is a good fit. During the interviews we don’t ask questions like “How many piano tuners live in San Francisco.” We don’t ask to demonstrate hands-on knowledge of algorithms from the book by Donald Knuth. We just need people who care about their profession and know a specific set of software tools.
You’ll be surprised, but even if a person demonstrates good understanding of a certain technology this doesn’t mean that he will be able to apply this knowledge in a real project. If a technical job interview doesn’t work, what does? We started using a new hiring technique: try and buy. This is not about hiring people as contractors and then offering full time employment to those who quality. We offer remote software developers who successfully passed phone interviews to start working on our projects part time without leaving their current employer.
If a person wants to work for us, he can find 40-60 hours to commit for working on our project just for one month. After that, we’ll either make an offer or say, “Sorry”. We pay for this time even if the person didn’t prove to be a good fit for us. It’s less expensive for our company and less stressful for the developers.
We are a software boutique and can afford to hire the best. This worked for us in the past and it will work in the future.