How to (Not) Hire Freelancers for Your Startup(dennybritz.com)
dennybritz.com
How to (Not) Hire Freelancers for Your Startup
http://dennybritz.com/blog/2013/08/27/startup-outsourcing/
12 comments
I agree, a lot of this sounds like he just found bad freelancers. I have been contacted in multiple occasions by people who wanted to launch their own startup and wanted to hire me to write it, but it was clear that they didn't have all the business details ironed out. I advised them to get feedback first, then try for an MVP based on that feedback, and then come to me for implementation. They were all very happy with this, because it's good advice they hadn't considered, and it's free.
Also, working as a freelancer right now (although in a more long-term role), I definitely am concerned about code quality and the thing I'm making working well, because I'm the one who's working on it. Writing unmaintainable code on purpose is not only unethical, but it comes back to bite you in the ass when you have to maintain it. Thankfully, I have no shortage of work at the moment, so it wouldn't be my dream job to have to work on an unmaintainable mess, much less so when I created it.
I disagree with the article a lot.
Also, working as a freelancer right now (although in a more long-term role), I definitely am concerned about code quality and the thing I'm making working well, because I'm the one who's working on it. Writing unmaintainable code on purpose is not only unethical, but it comes back to bite you in the ass when you have to maintain it. Thankfully, I have no shortage of work at the moment, so it wouldn't be my dream job to have to work on an unmaintainable mess, much less so when I created it.
I disagree with the article a lot.
I don't disagree with you that "good" freelancers should care, but that doesn't change the fact that (in my experience) most do not. That being said, most of my experiences were with "low price" freelancers, which probably has a high correlation with that fact.
Sure. If you buy at a low price you show that _you_ don't care.
> Hire an expert to regularly review your code. Contrary to what you may think this doesn’t cost much. Any good developer can tell “good” from “obviously bad” code in a matter of minutes. Hire a consultant for one hour and he can tell you exactly what state your code is in.
Generally-speaking, an "expert" is not likely to be interested in periodic code review engagements:
1. Most "consultants" aren't working on an hourly basis, at least one free of reasonable minimums. In other words, good luck finding an expert-level developer eager to take on periodic hour-long "Is this code okay?" projects.
2. A real code review consists of more than just a cursory "this is good code, this is bad code" analysis.
3. A code review doesn't really help a client who doesn't have the ability to rectify issues that are discovered. I can guarantee you that a consultant asked to perform a code review in the scenario described here will nine times out of ten find himself being asked "How do I fix it?" Unless the client is prepared to pay for the skills of a quality developer, getting involved in a "How do I fix it?" discussion is going to be a tar baby for the consultant in question.
4. The author is generally distrustful ("Don’t trust reviews or portfolios", "the motivation of most freelancers directly competes with writing concise code") yet curiously he doesn't consider the possibility that the "expert" you bring on to review your code, if he's looking for development work, has an incentive to raise questions about the quality of the code.
Not all of the advice here is bad, but I think the author generally glosses over the fact that finding good freelance developers and doing so when you have limited technical skills and experience managing the development lifecycle is difficult and may not be a viable approach.
Generally-speaking, an "expert" is not likely to be interested in periodic code review engagements:
1. Most "consultants" aren't working on an hourly basis, at least one free of reasonable minimums. In other words, good luck finding an expert-level developer eager to take on periodic hour-long "Is this code okay?" projects.
2. A real code review consists of more than just a cursory "this is good code, this is bad code" analysis.
3. A code review doesn't really help a client who doesn't have the ability to rectify issues that are discovered. I can guarantee you that a consultant asked to perform a code review in the scenario described here will nine times out of ten find himself being asked "How do I fix it?" Unless the client is prepared to pay for the skills of a quality developer, getting involved in a "How do I fix it?" discussion is going to be a tar baby for the consultant in question.
4. The author is generally distrustful ("Don’t trust reviews or portfolios", "the motivation of most freelancers directly competes with writing concise code") yet curiously he doesn't consider the possibility that the "expert" you bring on to review your code, if he's looking for development work, has an incentive to raise questions about the quality of the code.
Not all of the advice here is bad, but I think the author generally glosses over the fact that finding good freelance developers and doing so when you have limited technical skills and experience managing the development lifecycle is difficult and may not be a viable approach.
I've actually been thinking about offering a code review service, since it would fit well with the way I like to work. Personally, I wouldn't want to do one-hour reviews, but would be very happy selling four hour blocks of my time.
A third-party code review could easily point out certain problems that aren't only qualitative (e.g., the code is vulnerable to SQL injection attacks). It could also be useful to evaluate programmers. The project owner hires a few different developers to write a single user story, the reviewer tells them which code is the highest quality, and the project owner hires the best coder to do the complete project. For slightly more corporate clients, it could also be used to identify to a non-technical manager where their programmers need additional training.
As far as the reviewer being asked, "How do I fix it?", that could lead to the reviewer offering training material, libraries, or development tools.
A third-party code review could easily point out certain problems that aren't only qualitative (e.g., the code is vulnerable to SQL injection attacks). It could also be useful to evaluate programmers. The project owner hires a few different developers to write a single user story, the reviewer tells them which code is the highest quality, and the project owner hires the best coder to do the complete project. For slightly more corporate clients, it could also be used to identify to a non-technical manager where their programmers need additional training.
As far as the reviewer being asked, "How do I fix it?", that could lead to the reviewer offering training material, libraries, or development tools.
Sounds like a good idea to me. The biggest problem is establishing credibility, and deserving the credibility. The code reviewer really needs to be up to the task.
While you make a lot of good points, I'd note that you're more likely to know a good enough, if perhaps not expert-level developer who has some time to do code reviews, than one who has enough time to actually do the work.
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.
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.
re: #4 is that kind of distrust warranted? Is it really common that portfolios and reviews are falsified?
Perhaps I'm a jerk, but I don't feel bad when non-technical people get taken for a ride when hiring people for a tech-startup. I have no business trying to start a hair salon on the cheap, so why should I feel sorry for someone who feels that he can make a go at something that requires highly talented, seasoned workers?
"Perhaps I'm a jerk, but I don't feel bad when non-waiters get taken for a ride when hiring waiters for a restaurant."
This makes no sense. If you want to open a restaurant, you need to know the restaurant business well, not how to efficiently coordinate table serving.
This makes no sense. If you want to open a restaurant, you need to know the restaurant business well, not how to efficiently coordinate table serving.
If you want to open a restaurant, you sure as hell better know how to screen for qualified waiters/bartenders.
Sure, but you'd better be able to tell if the servers you hire are doing a good job. Ditto for cooks, cleaners, dishwashers. You shouldn't need to hire someone to look for flecks of food on your 'clean' dishes.
Alternatively, if you want to open a restaurant, you shouldn't need to be an expert in plumbing, electrical, framing, HVAC, upholstery, cabinet-making, painting, and floor refinishing just to get the place ready to open.
The reason you don't need to be an expert in all these things is because there are governmentally mandated codes, licensures and bonds with which all such workers must comply or face governmental censure. These standards have supposedly been crafted to represent an acceptable minimum quality of work by qualified persons.
Sure, but you hire professionals to perform and inspect this work, and at the end, have a local official verify the work has been done. Your example really stretches the analogy as buying/renting a structure is not at all similar to trying to get a stranger to build a core product that you can't maintain.
That might be a better analogy, yes.
(I love how you can just kind of say whatever thoughtless thing you want, as long as you call yourself out for being an asshole first.)
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.
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.
>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.
Keep in mind that this article is about hiring outsourced/contract/freelance labor, not future partners/members of a team.
Keep in mind that this article is about hiring outsourced/contract/freelance labor, not future partners/members of a team.
Yup, I know. Freelancers are members of the team, btw. And I still think it's not cool to find it perfectly acceptable for someone to scam someone else just because they can. Or to say that people who try to do things they're not good at deserve to be scammed.
>"Or to say that people who try to do things they're not good at deserve to be scammed."
It's more often the case that the hire isn't as good as he believes. Which is perfectly fine, because the person/"entrepreneur" that performed the hire is also still learning about the business.
It's more often the case that the hire isn't as good as he believes. Which is perfectly fine, because the person/"entrepreneur" that performed the hire is also still learning about the business.
I believe the better solution to most of these problems is to find your freelancer, consultant, etc. through personal channels where their reputation is already established and their past success verified.
For example, you may not have a technical co-founder, but you may have a friend who does, and they're likely to have a friend who is still doing independent consulting. Now, that person may not be available to work with you, but since they're in freelancing circles, they'll likely be able to put you in touch with someone who can, all while knowing that a bit of their own reputation is on the line in the process of recommending someone.
The key here is that you're not finding a stranger online and asking them to establish their credentials. Instead, you have no idea who you'll end up with and the only way you'll find them is if they've got the credentials (and the availability.)
For example, you may not have a technical co-founder, but you may have a friend who does, and they're likely to have a friend who is still doing independent consulting. Now, that person may not be available to work with you, but since they're in freelancing circles, they'll likely be able to put you in touch with someone who can, all while knowing that a bit of their own reputation is on the line in the process of recommending someone.
The key here is that you're not finding a stranger online and asking them to establish their credentials. Instead, you have no idea who you'll end up with and the only way you'll find them is if they've got the credentials (and the availability.)
I'm currently working some freelancers on my HypedSound relaunch. The designer and frontend coder both worked on hourly billing but everything was very well-defined. Since the backend is a much more complex scope, it was hard to define hours, and I'm working with a 'variable scope and budget' that we're shooting for. I wasn't ready to commit to hourly billing. Luckily, I have an advisor looking over all the code, which I think is essential as you mentioned. Whether it's a language barrier, technical barrier, or incentive barrier to good communication, you should have someone technical on your side even if they're not doing the coding.
What a terrible article. There are very few actual justifications for the arbitrary claims the guy makes. Even some anecdotes (especially non-personal ones) would be better than this guy's random assertions.
Yeah, these are just my personal experiences, no hard data. I added a little note making that clear.
You did, but you also titled the article "How to...for YOUR startup", implying that somehow these tips are valuable lessons for others, when really any founder taking this advice (without more) is doing him/herself a disservice.
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.
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.
The idea that "goals are not aligned" is very much dependent on the freelancer you hire, and is not a universal truth. The way I approach all my projects is that I (like everyone else) have a limited amount of time left on this earth. I feel a real sense of urgency to make the best use of that time doing meaningful work that I can be proud of.
The idea of just churning on a project to make a few extra dollars really makes me feel a little bit sick. The opportunity cost of that time is just too great. I would much rather take the most efficient route possible to build what my client wants and then be able to start on the next project. Hopefully the client is pleased with my work and that next project might even come from them.
The idea of just churning on a project to make a few extra dollars really makes me feel a little bit sick. The opportunity cost of that time is just too great. I would much rather take the most efficient route possible to build what my client wants and then be able to start on the next project. Hopefully the client is pleased with my work and that next project might even come from them.
It sounds like the OP was burned at least once by a freelancer in the past. We come across folks like this every so often at matchist (http://matchist.com).
The biggest problem we often see (and I've seen in my previous experience as a freelance developer) is a lack of trust between the two parties. The client doesn't trust the developer to do their job and/or the developer doesn't trust the client to do their job.
The OP has some good ideas about how to establish trust between the two parties (communicating regularly and effectively, but most of his ideas appear to stem from the fact that he simply doesn't trust freelancers from the get go.
The biggest problem we often see (and I've seen in my previous experience as a freelance developer) is a lack of trust between the two parties. The client doesn't trust the developer to do their job and/or the developer doesn't trust the client to do their job.
The OP has some good ideas about how to establish trust between the two parties (communicating regularly and effectively, but most of his ideas appear to stem from the fact that he simply doesn't trust freelancers from the get go.
>>>
Hire an expert to regularly review your code. Contrary to what you may think this doesn’t cost much. A good developer can tell “good” from “obviously bad” code in a matter of minutes. Hire a consultant for one hour and he can tell you exactly what state your code is in.
>>>
Where? How? I've tried. Even if for my own code I would love it. Any credible recommendations and I would do it.
Where? How? I've tried. Even if for my own code I would love it. Any credible recommendations and I would do it.
Everything made sense to me except for the part about writing tests.
If you're confident you're product will have a long lifespan then tests make perfect sense. But from what I've seen most MVP's are experiments that may or may not stand up to real users.
If you're in the latter camp, writing test code is prematurely optimizing for stability.
If you're confident you're product will have a long lifespan then tests make perfect sense. But from what I've seen most MVP's are experiments that may or may not stand up to real users.
If you're in the latter camp, writing test code is prematurely optimizing for stability.
> If you're in the latter camp, writing test code is prematurely optimizing for stability.
Not sure test have something to do with stability. Writing test code will help document the code for the next developer who touches the hair ball and will force better definition of requisites in the MVP phase.
Not sure test have something to do with stability. Writing test code will help document the code for the next developer who touches the hair ball and will force better definition of requisites in the MVP phase.
Totally agree, but I thought I wrote that ;) "If you know that you will start from scratch soon you can most likely skip the tests and focus on testing your hypotheses as quickly as possible."
Yeesh, just went back and re-read that. I fail at reading.
The "write tests" part could be rewritten as: don't let the freelancer dictate the rough technical direction. If you want a proper state-of-the-art software project, tests should be included.
Only if you write unnecessary tests: e.g. for CRUD code, or for front-end UI. But when you have complex procedures with clearly defined outcomes, writing tests is never premature.
It doesn't need to make sense. Author is obviously a devout monk in the church of TDD. The view is purely religion.
That is precisely why I usually recommend avoiding websites like oDesk, elance, freelancer etc.
You need to have experience and knowledge in order to weaeve-out the bad candidates... but odds are, it's due to your non-experience that you're looking on these websites.
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.
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.
(Sample Projects) -- Hey, if you wanna pay me to do a sample project and then also pay me to do the actual project, fine. I can see how that would work if the sample project is a small subset of the actual project. If you expect me to do work for free in hopes that I can do work for pay.... yeah, no.
(Goal Alignment) -- In any business, the service provider should have an investment in the client's success. Primary goals might not be the same, but if the freelancer isn't doing it to help you -- you have a bigger problem.
(Hourly vs. Fixed Price) -- I imagine any issues with fixed-price contracts can be avoided by going over requirements thoroughly at the outset and having a good agreement set up in writing. I've been bitten by this before, but I know it was my own fault for not setting things up right at the start.
------------------------
All in all, I think a better though process for this blog post would be "How to Hire (better) Freelancers" or something.
(Goal Alignment) -- In any business, the service provider should have an investment in the client's success. Primary goals might not be the same, but if the freelancer isn't doing it to help you -- you have a bigger problem.
(Hourly vs. Fixed Price) -- I imagine any issues with fixed-price contracts can be avoided by going over requirements thoroughly at the outset and having a good agreement set up in writing. I've been bitten by this before, but I know it was my own fault for not setting things up right at the start.
------------------------
All in all, I think a better though process for this blog post would be "How to Hire (better) Freelancers" or something.
> 2. (Sample projects.) Sorry, I don't do these.
Even if they are paid for? If so, why?
Even if they are paid for? If so, why?
They're too small. Any project requires a certain amount of headspace. I just don't have enough to work on two hour projects that may or may not lead to something else. It just sounds like a pain-in-the-ass.
Also, being a good developer doesn't mean I know how for loops and basic OOP works -- it means I know how to build and organize non-trivial projects that require thought and care. Having me work for two hours on something random won't tell you anything about this.
Also, being a good developer doesn't mean I know how for loops and basic OOP works -- it means I know how to build and organize non-trivial projects that require thought and care. Having me work for two hours on something random won't tell you anything about this.
Just to pick on the most obvious one:
"Freelancers want to make money. They don’t care if your business succeeds or not."
A good freelancer does care. Ignore the other ones. Good freelancers want to be involved in decisions regarding their piece of work. They take interest in what you want to achieve and try to do the best for your project. They pour in an extra hour for a bit of polish that would hurt their pride otherwise.
Freelancing leaves a lot of flexibility and ways to cut deals.
To give you an example: I had multiple prospect clients where I straight-out said "don't build that feature (now) and especially not for my price.". Quite a few ended up not doing (or delaying) the project and were very happy with the decision. All of these turned out to be lucrative events, because those clients pass you on to others with kind words. Find the ones that jump on your idea once you tell it to them and want to work with you. Enthusiasm is (relatively) hard to fake.
Also... I'll never do a fixed price project, unless you agree that: a) it is time-constrained, b) you won't change any of your wishes during the project.