I did many interviews, and enjoyed most of them. I had some bad ones, which I either failed or refused to do. Software devs are very highly paid professionals and can afford to refuse opportunities with quite a bit of discretion. I encourage you to continue refusing tests you find stupid or poorly designed. We encourage our clients to ask fair, useful questions, but the only way to change the world is to vote with your feet.

> I had some bad ones, which I either failed or refused to do.

And that's the other reason I never do online tests. I don't know what the company and for example CodePad will do with the data collected from me. Will they store, sell and/or share it? Will CodePad reuse collected data in any way if I do an interview for another company? Etc..

I sort of doubt this will change your course of action, but we of course do not share your data. That said, any company that asks you an interview question has probably seen hundreds of answers to said question already and probably has neither the inclination nor ability to profit from somehow collating your answers.

If anything, companies are much more concerned with candidates sharing questions with each other.

> but we of course do not share your data

There you go buddy:

"A record of everything the candidate types in the pad will be permanently saved for your team to review and share afterwards."

https://coderpad.io/getting-started-recruiters

Right, what you type is shared with the company interviewing you. Isn't that kind of the point of the product? Isn't that true in whiteboard coding interviews as well? Maybe I'm misunderstanding, but getting worked up about this sounds like being upset that GMail sends your messages to recipients' mail servers.

I think akanet was clarifying that CoderPad doesn't share your data with any other companies.

If you're worried about the company you're interviewing with doing shady things, I'd suggest interviewing somewhere else.

The interview process is a two way street, and a good onsite will include time for an applicant to talk to a manager at the company which will give you time to determine if that manager is competent, as well as a good fit.

Furthermore the interview test "FizzBuzz" was announced back in 2007, yet there are applicants who claim they can program but still fail such a basic test. (Failure modes include the applicant thinking they are "too good to take the test" and refusing to trivially demonstrate they are able to code. Choose your reaction carefully.)

>>The interview process is a two way street, and a good onsite will include time for an applicant to talk to a manager at the company which will give you time to determine if that manager is competent, as well as a good fit.

The candidate is never allowed to see how manager solves technical puzzles.

I was asked to complete a screening test on CoderPad earlier this year and got rejected because, from what I could tell, my edits didn't sync with their backend for some reason. Of course I couldn't prove it so I can't blame the company. It sucks because I came up with what I thought was a pretty good solution to the problem. Make a copy and attach it in a notification email to your interviewer!

Anyway, just one more reason to be weary of these types of tools.