I've been a freelancer for the better part of 17 years. A few quick reactions: 1. (Code reviews.) This seems really rare, in my experience, and there are a few

I've been a freelancer for the better part of 17 years. A few quick reactions: 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.