So I got a task to code some "home work" for a technical interview, where we are going to discuss what and why I did it this way.
I normally dont se any problem doing so. But the case I got recently is just nonsense and this really makes me doubt if I want to work in a place like that and waste time on this task and a new interview.
Its almost like this task is just made in this way, so I should point out how meaningless this is. Is this something that ca company actually would do?
I can't imagine a scenario where an interviewer would assign a task as a test of whether or not a candidate is able to recognize the task has no value. If you're convinced the task in no way measures your skills as a developer, you could send a follow up email and ask what they're trying to gauge. If it's not a job you're particularly keen on landing, I would probably just call it a day and move on to the next one.
I would recommend you seek an opinion about if it is nonsense from your peers in the industry.
Also, sometimes these screening exercises can be from a recruitment agency, and not from the organisation itself. And sometimes these recruitment agencies can be quite... wacky... with the stuff they come up with.
If you want the job, I'd complete it. If you get hired, and the actual work is the same, you can always leave. You are not locked in for life.
One of the option not covered in the other answers is that the problem stated requires skills/knowledge beyond yours to understand or that the answer is exactly that you tell that it doesn't make sense. As an Interviewer I regularly ask questions which seem trivial to people not trained in a specific field. A typical thing would be controller design where there is a simple layer (Test if that works in a simulation), a medium layer (Analytical criteria for stability) and a abstract layer (Coupled nonlinear systems).
In such cases it very often happens that the candidate believes that the questions is answered completely and thoroughly, yet it just tells me that he/she didn't go to the bottom of it. And it actually could be that "ok, thats the function you asked me to implement, but don't put that in a production server because the database design is not normalized and you will probably get an inconsistent database" is the answer they are looking for (or in my case, yep, the controller is the design you asked me to do but please never use this....).
Coming up with decent technical tests, that can be approached by people with varying experience levels is hard. Even more so if you try and make it relevant.An artificial one is sometimes easier to produce, or just get from a third party.
It's possible that it is more relevant than you realise. I did a technical test that seemed very contrived and dated, until I worked there and realised it was very close to how a number of their interfaces worked.
It is a trick to see if you pick up why it's a bad test. This seems very unlikely.
When interviewing I always ask candidates what they think of the test. It's useful info about the candidate, and helps us improve the tests. Assuming they do the same, that's your window to say what you think (Politely of course...)