How to (Not) Hire Freelancers for Your Startup

Or at least I've done this before. With, I'll admit, at least one instance where I raised red flags which were ignored for a long time until I was finally hired to deal with a by then terminal* as it turned out mess.

* Before the company could be saved the early '90s recession killed its profitable line of business.

An example, lest I just be picking on you. Other commenters have already reasonably tackled many of the other assertions, so let's go with this one: "Developers have gotten really clever about creating fake portfolios"

First of all, how do you even know this? Did you work with someone who did this? Have you discussed this w/other entrepreneurs who experienced this? Did you hear a rumor somewhere? No one's demanding hard data, but it's fair to expect you to back up your assertion WITH AT LEAST SOMETHING. Even if you had a personal story, you'd have experience that others could use to detect red flags.

Second, what did they do? Get fake apps uploaded to the App Store? Put together screenshots that weren't theirs? What is this super clever scheme that you've discovered? I assume it's not that clever, if it exists at all, but there's no way to tell.

Finally, your lack of trust just creates a hostile environment around what might otherwise be some good advice. I'm a freelance dev and I LOVE SAMPLE PROJECT "INTERVIEWS". There's a number of reasons why they are significantly better than just guessing based on a resume and some technical questions (especially w/non-technical startup founders), but I expect to go into first time projects with a sense of optimism and mutual respect, not mindless fear.

Your article starts out noting that it's best to find a technical co-founder, and I couldn't agree more. Devs often understand what is going on in the mind of other devs, but also represent the needs of their company, so it's a good balance. Way better than relying on overseas talent using this linkbait as a guide. Ugh.

Perhaps I'm a jerk, but I don't feel bad making fun of people who write dumb comments on Hacker News.

Or.

Perhaps I'm a jerk, but I don't feel bad when non-business people get take for a ride when hiring people to help them run the business side of their tech-startup. Why should I feel sorry for someone who feels that he can make a go at something that requires highly talented, seasoned workers who understand the details of how to run and grow a business?

Anyway:

Not everyone knows everything. If you are hiring someone because you're aware that you lack the skills to get something done, that's fine. That's why you hire experienced people. And when you hire them, you expect that they'll do a good job at what you're paying them for. Businesses require teams of talented people who can trust one another. Not everyone knows everything -- and if you think that everyone should just take advantage of each other, well, remind me to never hire you. Or work for you.

Perhaps I'm a jerk.

1. (Code reviews.) This seems really rare, in my experience, and there are a few problems with it. For one, the code reviewer might not be better than the original developer. And they may not know the constraints and development process of the project. Secondly, the one time someone wrote up a major code review for a project I had recently finished, I felt they were nit-picking and falling into the trap of "well, that's not how I would've done it" mostly just so they could land a job fixing the alleged problems.

Even if you're non-technical, I might suggest asking the developer to show you how they've organized the code. Just because you're curious how it works. I really enjoy teaching people about code, and it can be fun when non-technical people get a glimmer of understanding. And I think you can tell a lot about how clearly someone thinks simply by how clearly they can explain what they're doing.

2. (Sample projects.) Sorry, I don't do these. Look at my portfolio, resume, and go use some stuff I've built. If you think I'm lying to you about my involvement in those, then we have a bigger problem on our hands. If you need to, ask me for the contact info of someone I've previously worked with and talk to them about me.

3. (Goals not being aligned.) No two people ever have perfectly-aligned goals -- there's no need to get weird about it. Part of hiring someone is assessing whether you can trust them to do what they're expected to do. You'll get better at this with age. And hiring developers you can meet and talk to face-to-face is probably important. I am a professional and I am invested in the success of my clients. Because I'm a human being with a soul. And because it makes me look better if I can say "I built this app and then the company went on to wild success!"

4. (Tests.) It's all about budget and timeline. And project complexity.

5. (Communication.) Yes, good communication is key.

6. (Hourly vs. fixed-price.) My clients mostly want fixed-price contracts, which is fine. But I don't think it's because they don't trust me -- it's because it's easier to predict budgets that way. If trust is really such an issue that you need to worry about whether a developer is wasting time and you're thinking about hiring someone to audit(!) their timesheet, you have a bigger problem on your hands. So much in life requires trusting people and you need to either find people you can consistently rely on or come up with some ways of judging the trustworthiness of someone that doesn't involve micromanaging them. As for not getting screwed on fixed-price contracts: Trust also comes into play. But so does a well thought-out contract that spells out exactly what's expected from everyone and when. A contract doesn't replace trust. But it does make sure that everyone's on board with all of the nitty-gritty details and it lets everyone know what happens if something goes wrong. Think of it as a design document for your working relationship.

Anyway -- I'm glad people are thinking about these issues, but my general sense, here, is that Danny Britz is fairly new to this and has been hiring people off of relatively impersonal cattle-call sites like Elance. Which is fine. But I think that once you establish a rapport with some developers and get more experience working with them you'll find that you don't have to be quite as fearful that they're going to screw you.

Keep in mind that this article is about hiring outsourced/contract/freelance labor, not future partners/members of a team.