I did a code project as a test once. Mostly out of desperation to find a job quickly. And it taught me to refuse and ignore any work-at-home tests, no matter wh

I did a code project as a test once. Mostly out of desperation to find a job quickly. And it taught me to refuse and ignore any work-at-home tests, no matter what they are. Either you look me in the eye and we talk like men about software development. Or you play alone with your tests and quizzes until you find someone desperate enough to care. Why I don't do code tests: - Artificial problems with artificial constraints. I have to understand some weird context you dreamed up and figure out a solution that matches your expectations. Give me real world problems. I don't work in la la land. - Solving your test takes at least a couple of hours. I can send three more resumes in that time. Or I can start hacking together a side project to compete with your company. I don't waste my time and neither should you. - Skewed expectations. Your test is prepared in advance. And because you already know the solution, it seems easy. But it's not. Want a real test? Let's try one you haven't seen before side by side. We'll see then if I'm good and if you are as competent as you think you are. But if I figure it out before you do, I expect a salary higher than yours. Not so fun anymore, is it. - Skilled people don't need tests to determine skill. They assume it's there and look for potential problems. If I built at least one side-project and you can see it, don't treat me like someone that can't code. If I have 7 years experience, don't test my coding skills like I'm a graduate. Because the 3-5 guys that hired me before you did that already. And they found me good enough to hire. Show respect to your candidates. Treat them like they are as good as they claim, and look for discrepancies subtly. Don't assume everyone is an incompetent liar. And definitely don't test the living shit out of them just to prove yourself right or wrong.