Bidding was decided based on communication style, low bid, low GDP country and "has feedback on just 1 or 2 projects" (minimal, but not extensive history of delivering).
Didn't ask for "extra buggy" or "extra secure" because the ideal was the combination of honest mistakes and laziness that turn up in real code all time. I like the idea though ;)
I mean, you'd think that for $100 or whatever all up, they would have half-assed it a bit ;)
Probably the mistake was to stop at n=2 and not choosing a harder problem domain.
The mistake was for your friend to think that he was a good judge of ability based on the features at hand. It might be useful to reflect on whether the people your friend normally prefers to hire might just be the people who are best at managing presentation?
I love a good anti-anecdote (antidote?) ;) Here's one potential problem with the selection criteria: "low bid, low GDP country". I might have been better to weight the bid with the GDP (I don't mean really crunch the numbers, just put your thumb on the scale).
But more to the point, if your friend didn't have a lot of experience with this sort of thing, he probably wasn't that good at picking a bad apple. Or he just got unlucky, maybe.
I suspect "has feedback on just 1 or 2 projects" might also indicate the opposite: That the guy is picky, waiting around for a project he can actually deliver quality on, and perhaps optimising for second (off-site) follow ups.
Didn't ask for "extra buggy" or "extra secure" because the ideal was the combination of honest mistakes and laziness that turn up in real code all time. I like the idea though ;)
I mean, you'd think that for $100 or whatever all up, they would have half-assed it a bit ;)
Probably the mistake was to stop at n=2 and not choosing a harder problem domain.