I never do online tests, like with CoderPad. Why? The tests are flawed and subjective. I can give any interviewer 1 assignment that will make him/her fail miserably. Should I not do that first to see if the lead/manager is competent? Of course not! We are stupid applicants/beggars! We are not allowed to test our superiors for competence!
I cannot imagine the author of CoderPad would be happy to be in the position of an applicant again having to do such a stupid test. He is only happy because he now makes so much money of that process and never have to be an applicant again. Well done, we less lucky devs are f* anyways.
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.
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.
> The TS API in my case had something like 90% less errors
That sounds like a red flag to me. I hardly have any type related bugs in my pure JS server code. Must be a poor developer in the team. Too easy to blame JS for that.
That's the great thing about Type systems. It doesn't matter if the development team is amazing or not. Typescript still makes huge classes of errors impossible. It also speeds up development due to superior IDE support.
I've only used TS on the frontend, but I had the same opinion as you until I dug into a couple of TS projects. I don't know if I've ever caused a JS production bug that was a type error at its core, but I've had plenty of bugs like that in development. TS lets me cut out those little dev cycles where I'll write some code, rebuild the app, then see an obvious error in the JS console when I run the app. That adds up to a lot of wasted time over a week of coding. Smart autocomplete and smart variable renaming is also really nice, and I have way more confidence refactoring a TS project than a JS one. I think using TS does result in fewer production bugs, but the big win for me has been having fewer development bugs.
Types are good for more than just "int instead of string". What you consider a type related error is likely not the full set of errors a type system can prevent.
Aside from the other responses you are getting, consider that the "90% less errors" doesn't actually tell you anything about the overall quality of either codebase. It could be a million lines of JS/TS with 10 errors found in the JS vs 1 in the TS. That would be a 90% reduction, but 10 errors in a large codebase would still be pretty excellent.
Simply using open-source projects is definitely a way to say thank you. I have several projects on github and I am very grateful for developers trusting and using my code. It says much more than a 'thumps up'.
Indeed, for the fools that store their bitcoins in a wallet on services like Coinbase. You only need to save your private key in a save place to have the storage for free.
I cannot imagine the author of CoderPad would be happy to be in the position of an applicant again having to do such a stupid test. He is only happy because he now makes so much money of that process and never have to be an applicant again. Well done, we less lucky devs are f* anyways.