My company runs a coding test, it's like "here are some interfaces we want a solution that detects Y and does Z". We don't compile or run the code that people s

My company runs a coding test, it's like "here are some interfaces we want a solution that detects Y and does Z". We don't compile or run the code that people submit. We're literally looking for if they ask the right questions, structure their design in anything like a sane way, and understand the fundamental restrictions of the technology we use. Oh and that previous paragraph? That's how I explain our coding test, I'm very clear what our standards are. >How can you possibly evaluate a test without predefined criteria for evaluating that makes the result good and what makes it bad? If it's even a slightly reasonable solution it's a pass. It doesn't need to be "good" it just needs to not be terrible. >Another down side to coding tests is that if the assessor knows less than you about some area of coding and sees something they don't recognise or understand, then they might well negatively view what in fact is a much better way of doing things. A correct solution is acheivable in between 50-100 lines of code. If you do something I don't understand I can look it up. In fact, people have done things that I don't understand and looked up. >And, much worse than anything else, you have a very tangible chance of spending 12 hours doing it and hearing nothing back at all. Every candidate has a phone interview first and every candidate gets a response to the coding test. It's unusual to complete the test without e-mail back and forth with one of us for clarification (which is part of the test). >And as for "Tic Tac Toe" as ANY sort of effective test topic, First you wanted something that didn't take 12 hours, now you're complaining the test is too simple. You don't know what the company does, so how do you know the skills you need for a tictactoe solver aren't relevant? >I did two coding tests in recent years ... in one, their feedback was "they didn't like it", and the other one I worked on for 12 hours because I believe in doing a good job and meeting the requirements, and I heard nothing at all back - not a single word. Companies being bad at coding tests doesn't mean coding tests are bad. Companies are liable to ghost you at any point in the interview, that's nothing to do with a coding test. Our interview process is on-site and normally takes 1/2 visits, it will involve probably 8 person-hours of our engineering time + management. So yes, we want to make sure that candidates are atleast vaguely able to solve practical problems before they come in.