In general the naive advice is to follow the instructions. If you are told to spend 4-6 hours on a project, spend that time.
Unfortunately in real life two things invalidate this advice:
- Question setters invariably underestimate the time required to complete a question, just like software developers invariably underestimate the time taken to program a task, often by a factor of 2-4. As well as the usual underestimation problems, question setters are setting a question they are already familiar with, and neglect any time a candidate may have to think about the topic, or false starts they may make.
- Interviewers assess a result for quality. In reality they are not too bothered by whether your solution took four hours or six hours.
Having said that spending ten times the allocated time is not sensible and will backfire. If you have spent ten times the allocated time on a problem there are only three possibilities:
- The task setters have given you a time estimate in which it is not
possible to accomplish the task, or come close to it. This may be an
unwitting extreme underestimation or may be deliberate to test your
reaction to an unreasonable estimate.
- You are overengineering the problem, covering every possible case,
optimizing for things that don't need to be optimized, focussing on
details that aren't important. This will be noticed in the solution.
- You are actually not very good, and take five or ten times as long to produce an adequate result as other people.
My strong advice is to take longer than they say (if you need it), but only by a small multiplier, never more than twice what they say. Make it work, cover obvious errors. You can talk about improvements you might have made given more time in the interview. No reasonable company expects production-ready code after a few hours of work.
You could be doing other stuff with that time - researching jobs, sending out resumes, networking preparing for other interviews.