My simple process of finding and keeping great developers

If you follow me long enough, you probably know that I run e-commerce store that sells women clothing. Yep, that’s right, a women clothing store! How did that happen? You can read all about it here if you are really curious. Actually, today we sell more than just clothing, but that’s not the point.

I was the only programmer behind the project for a long time. It was actually fun for a while as I was learning new skills and growing professionally.

As the site grew and feature requests started piling up I realized that I had to scale myself somehow. I remember how scared I was of letting someone else touch the code that I wrote… But I had to do it if I wanted to keep my sanity.

I wrote my first ever job listing and published it on one of the local sites. Soon enough, a few people responded and I had to interview them somehow. I never did it before and was very nervous, probably even more nervous than the guys I was about to interview. It’s funny to remember now.

Anyway, I ended up hiring my first ever programmer Andrei from Donetsk Ukraine! I actually had to convince him to join me, as he had an impression he wasn’t good enough after I bombarded him with a bunch of deep technical questions during the interview.

Once I added another person to my team, I had to change the whole development process and setup additional management tools. The hardest part for me was letting the new guy do the actual work. I double and triple checked every little change which slowed the entire dev process even more.

Andrei was a character on his own. He wasn’t afraid to get into an argument with me and I remember us arguing for hours trying to identify the best way to implement some specific feature.

Eventually, we found our ways to communicate with each other and I slowly started to relax and let go of the reins. Fortunately for me, Andrei was an extremely smart guy, just a bit stubborn (like most of the engineers?). He was definitely a great addition to my small dev team back then.

That was about seven years ago I believe. The project continued to grow and I had to learn how to find and bring in more great programmers.

Main takeaways of hiring and firing engineers

Here are the main takeaways that I discovered over the years of hiring and firing people in US and overseas:

• Always hire people overseas – I do love local developers, there is a LOT of great talent over here in US. Here is my problem – they are just FREAKING INSANELY EXPENSIVE! and YOU CANT REALLY GET THEM EVEN IF YOU OFFER THEM A LOT OF MONEY! The good ones at least. Plus, as a long-time software engineer myself, I don’t believe that it’s possible to assemble great developers in the office and keep them there for long. Unless you are GOOGLE… maybe…

Anyway, I’m a big believer in remote and have a lot of experience running distributed teams. The only thing that I’d like to mention here is the importance of hiring people in similar (ideally same) timezones. It’s just so much easier to manage.

Maybe one day I’ll create a virtual reality tool which will help us to get together in some cool and weird places instead of boring offices. Plus, there will be no dress codes there. Hell, you don’t even need to be you, feel free to come in as Dragon, Goblin or whatever you feel like at the moment. We all will be connected to the Matrix eventually anyway, so why not? See, dropping ideas for you guys! 🙂

Ok, where was I? Oh yeah, that’s right – hiring overseas.

There are other significant benefits like very simple and straightforward process of hiring and firing which cannot be underestimated. Plus no need of having extensive benefits packages and dealing with insurances and stuff like that.

• Pay them well and keep them happy – still will be much cheaper compared to US. This one is VERY important.

What I like to do is to start a new person with rather low initial pay and then once I see that the guy is good, I periodically (in some cases rapidly) raise the salary without programmer asking for it first. You can think of it as a testing period of some sort. Always try to leave some room for periodic salary bumps as every person no matter how much he/she makes expects a raise once in a while.

If you remember one thing from the whole post, that would be this one – always keep your programmers happy. Get to know them and give them what they want – vacations, new computers, new games/toys, money. Whatever is necessary. Trust me, it will pay off 😉

By the way, this principle applies to all people you have on your team, not just tech gurus.

• More expensive software engineers are not necessarily better than less expensive ones – it’s very possible they just have better marketing skills.

Like with many things in life, price does not always reflect the quality. It doesn’t mean that you need to find the cheapest offer on the market and expect a miracle. No. I just meant to say that you need to interview multiple people. Don’t hire the first developer who comes at the door, no matter how excited you will be at that moment. Even better if you can work with multiple coders on some short therm well-defined project just to test them out in the battle. That’s the best (and only?) way to tell who is who.

• Always make them do some test coding tasks before you pull the final trigger – just try to come up with something easy to do, but at the same time covering a few distinct areas. For web developers, I usually make them do login form challenges, payment/shopping card integrations, design to html conversions and things like that.

Just don’t give them something complicated and time-consuming, unless you are willing to pay for the test task as well. Time is precious and no one likes to work for free.

• Do not hire the first person you spoke with – a bit of repetition won’t hurt here. It’s ok to spend some extra time on interviewing multiple candidates as the difference between average and great programmer is HUGE. Plus it will cost you much more in the long run if you will need to replace the person you rushed to hire. It takes time for the programmer to familiarise himself with the previously written code unless you are hiring at the very beginning of the project.

• Fire quickly – sometimes you pick bad apples, it’s the normal way of life. Don’t get emotionally involved and don’t try to change the person as it will take a lot of time and does not guarantee any results in the end. More likely you will waste time and your project will suffer.

• Try to get the person fulltime if you can – this is my personal favorite. In my experience, professional freelancers have a lot of different clients and can’t focus 100% of their attention on your project. They usually juggle a lot of balls in the air and dropping quite a few in the process.

I only work with freelancers on some short-term well-defined projects. Yes, it may seem more expensive to go bring in full-time person, but it always pays off in the long run. It’s the investment. What happens is that projects rarely end after initial development is done, there are always extra features, maintenance/support and bug fixes.

• Avoid single point of failure – hiring a developer is a great first step. The problem comes when the guy that built a lot of your software suddenly stops responding to your emails and phone calls. Now you have to wait weeks and months for the simple features/bug fixes to get done. This is a very typical situation when you deal with freelancers as they always tend to book more work than they manage to complete.

The same thing can happen for your fulltime gurus when one day you receive an email from your super smart coder saying he decided to pursue other opportunities in life… Just trust me it happens and it’s not pretty…

That’s why you need to have a backup strategy. If you work with short-term hourly projects – try to find an agency with multiple people. In that case, you don’t need to worry about people leaving or going on vacations. Yes, your project will be affected, but not as much.

If you prefer individual freelancers (might be cheaper), build a list of multiple people and keep them engaged with some small projects periodically. This approach is more time consuming but works.

When it comes to full-time developers – you need to have at least two. Here is the important detail – only do it when you software project gets some traction. Fulltime people are expensive and you want to make sure you have enough work to keep them engaged and enough revenue to pay them on a regular basis.

Those are the major things that I keep in mind when I work with software engineers. As with everything, no matter what you do at the beginning, you going to suck. That’s why I want you to pull the trigger and hire your first coders. Get your feet wet. You will get better eventually, I promise.

Feel free to ask questions or share your thoughts in the comments section below or/and join our private group of like-minded software builders so you can avoid many of the commonly made mistakes and save yourself some hard earned $$.

Where is the url to the private group? Well, I didn’t create it yet… Just drop me a line for now if you have some specific software questions or ideas. I always enjoy working with passionate entrepreneurs and engineers.

Cheers.