Hi Elias here, founder of Interviewless. Here to show an early version of a service I'm building, a dev-to-dev freelancer network were clients define the validation criteria upfront so a freelancer can get started working on the problem, no interview process needed.
This is a really cool concept. There's a great crowdsourcing paper [1] that I think will really help with your framing. Have been studying this space for close to a decade.
Some first-pass thoughts:
- when I click "try to solve demo tasks" I'm presented with a loading dialogue, "waiting for a task to work on..." and nothing else. Do you think it would be helpful for you to write a few demo tasks yourself as some "control tasks" to see how people would interact?
- for creating a task, I think it would be useful to specify the language / framework - your example is Python, but what if I want help on Rust or JS?
- while I can see benefit to hidden tests, if they are validation criteria by which the freelancer's output is measured by, could this introduce gotchas?
- it's unclear to me whether price and max development time have a relation; am I defining a gross price for the task, and a maximum time to fulfill, or a max price per minute? I assume the former, but it's important to clarify.
- what do you think about a "share to stackoverflow" button or something similar?
- I really like the no-nonsense signup flow. Email and that's it. Nice.
I really liked the paper, I'll have to read it in more detail, but yes, it definitely helps with the framing. At a high level I want to achieve the speed and efficiency of microtasks, but for interesting and intellectually challenging tasks as the ones present in broadcast search - we'll see how it goes.
On to your points:
- Absolutely, I added a few instances of the demo Counter task to show more or less how it will look. I plan to add more variety of tasks soon.
- Definitely, as I plan to make Interviewless useful enough so I can use it to build Interviewless itself, there will be a much greater variety of tasks: API connectors (stripe, GitHub), task allocation algorithms, UI/UX components... The python example was mostly to get something out the door quickly for now.
- My idea was to show that a task has 2 sets of tests: one clearly visible to the freelancer (logs and all) and another one hidden (so it's harder to cheat). As you say, the risk is there could be gotchas (or more likely errors) on the hidden tests. I'm hoping I can solve this with a reputation based system on the client side, and only consistently good clients can have hidden code.
- The max development time is the amount of time a freelancer has exclusivity over solving the task. I don't want the platform to feel like a constant race, but at the same time, there has to be a limit on how much time a freelancer can take on a task. Price is separate. The max price label was for a bidding system I was planning. I'll fix this and clarify these things soon on the page.
- Do you mean when a client is posting a task or after the freelancer solves it? The latter could be cool but if have to see how to implement it.
This has little value to me as it will likely take me longer to write the unit tests (asserts) than most of the functions I'd ask to be written.
If you give me a way to live a documentation link and a register for api access link, I could do more meaningful units of work using my app's public and private apis.
Test is difficult to be automatically generated. Unit testing Shane's when it catches the edge cases, which cannot be automated or they're very different. That's why a few teams are employing AI to solve this issue.
This is true, in TDD writing the tests before implementing something is usually more than half of the work cause it requires to figure out how it should work in order to test for the edge cases.
I get your point and I know there are many kinds of tasks that have a similar issue: difficulty of generating a validation test ~= solving the issue. That's why I imagine cases where it could be easier to have a set of inputs and then compare submissions by several freelancers at once (this would be the validation criteria). Given than (in my experience) hourly cost of a dev in SV > 10 x hourly cost of dev anywhere else, there should be still some margin
Being a developer while trying to work as a marketer, I see lot of possibility of automating data collection and analysis. I'd love to see a service that can take precise description of the tool I need, and it should get not only developer to build but a tester also test that so the tool I get is working without me needing to get involved much in discussion. As a client my money will go in escrow for posting the project, and as a developer/tester, freelancers would stake some amount (say $1) to start building the tool. So as to discourage those who don't understand the requirements and just do copy paste bidding (speaking from personal experience of being both a freelance developer and a client for several years).
I feel like defining the requirements for work to be done is half the work. If I'm going to specify all the possible inputs and outputs a system accepts, I might as well write the code myself because I've already done all the thinking.
14 comments
[ 4.8 ms ] story [ 45.3 ms ] threadHope to hear your feedback :)
Some first-pass thoughts:
- when I click "try to solve demo tasks" I'm presented with a loading dialogue, "waiting for a task to work on..." and nothing else. Do you think it would be helpful for you to write a few demo tasks yourself as some "control tasks" to see how people would interact?
- for creating a task, I think it would be useful to specify the language / framework - your example is Python, but what if I want help on Rust or JS?
- while I can see benefit to hidden tests, if they are validation criteria by which the freelancer's output is measured by, could this introduce gotchas?
- it's unclear to me whether price and max development time have a relation; am I defining a gross price for the task, and a maximum time to fulfill, or a max price per minute? I assume the former, but it's important to clarify.
- what do you think about a "share to stackoverflow" button or something similar?
- I really like the no-nonsense signup flow. Email and that's it. Nice.
[1] https://www.researchgate.net/publication/320744080_How_to_Ma...
I really liked the paper, I'll have to read it in more detail, but yes, it definitely helps with the framing. At a high level I want to achieve the speed and efficiency of microtasks, but for interesting and intellectually challenging tasks as the ones present in broadcast search - we'll see how it goes.
On to your points:
- Absolutely, I added a few instances of the demo Counter task to show more or less how it will look. I plan to add more variety of tasks soon.
- Definitely, as I plan to make Interviewless useful enough so I can use it to build Interviewless itself, there will be a much greater variety of tasks: API connectors (stripe, GitHub), task allocation algorithms, UI/UX components... The python example was mostly to get something out the door quickly for now.
- My idea was to show that a task has 2 sets of tests: one clearly visible to the freelancer (logs and all) and another one hidden (so it's harder to cheat). As you say, the risk is there could be gotchas (or more likely errors) on the hidden tests. I'm hoping I can solve this with a reputation based system on the client side, and only consistently good clients can have hidden code.
- The max development time is the amount of time a freelancer has exclusivity over solving the task. I don't want the platform to feel like a constant race, but at the same time, there has to be a limit on how much time a freelancer can take on a task. Price is separate. The max price label was for a bidding system I was planning. I'll fix this and clarify these things soon on the page.
- Do you mean when a client is posting a task or after the freelancer solves it? The latter could be cool but if have to see how to implement it.
- :)
If you give me a way to live a documentation link and a register for api access link, I could do more meaningful units of work using my app's public and private apis.
https://hypothesis.works/articles/what-is-property-based-tes...
I’d much rather pay someone a few 100s to solve a problem that’s taking me too long than keep spinning my wheels until I eventually get it.