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.
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.
- :)
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.
Hope to hear your feedback :)
