- if it's a super difficult problem, remark how fascinating it is and ask the interviewer how often they're doing this stuff
- if it's FizzBuzz or something else that is solved and has a known value, propose hardcoding the answer as a constant and printing it without doing any computation, and see how that goes over
- if it's not one of these, you might be in a 10% case
My favorite was when I applied at, let's call it "StoreJogger" at as entry level engineer. This guy comes in for the technical interview and asks me a question that basically boils down to "how would you make StoreJogger?" and I remember thinking that if I knew the answer, I sure as shit wouldn't be in there. Yeah I guess it was technically a relevant question.
That is a systems design question and would have been reserved for Senior/Staff+ level hires. I have learned there is a whole delivery framework for providing that answer and I would not ask that of entry-level engineering. Assuming it was entry level.
People in hiring positions basically want productivity. That largely means they want people who will slot into whatever problem is at hand and tackle it effectively. The minute you approach the situation with "this is a stupid pointless problem you have asked me to solve" you failed the test. Even if it's only implicit and through subtle use of language, this will come across.
The good candidates apply to some jobs, get hired, and stop applying. Some terrible candidates will apply to hundreds of jobs, never get hired for long, and just keep applying on every job posting. So a small minority of terrible coders end up being a disproportionately large fraction of interviewees.