That's exactly what I've started to do, but you've helped clarify what I was thinking and added some extra points, thank you

@wot Also note that the employer very likely knows this task should take longer than 2 hours to get it done. If you spend 8 hours or an entire weekend perfecting the task then that opens you up to abuse for free overtime. "Hey sport, you handily completed that interview task in 2 hours so here's a 2 week project that I expect you to have completed by Friday."

In the real world, you succeed at a task by doing it faster than your competitors, not better than your competitors. Very good advice from one of my mentors in industry: "if you have 2 weeks to complete a task that will take 4 weeks, what do you do? The wrong way is to work 16 hours a day instead of 8, and hope for the best. The right way is to spend the first 9 working days figuring out which 99% of the task isn't worth doing. Then do the remaining 1% on the morning of the last day, and leave early for the weekend."

Note: in your blockquote "ignored?" should be "ignore?", but is too small of a change for a suggested edit.

@alephzero, I think that faster vs better rule is a little broad. As a software engineering manager, I'm taking better over faster. The long term cost for that difference in quality can easily offset the upfront speed.

@cdkMoose - of course it's never just a matter of faster or better. There are always both quality and time constraints. Nobody ever says "I don't care how long it takes, I just want it better.", just as nobody ever says "I don't care if it's any good or not, I just want it in 2 hours."

@JoeStrazzere, I agree but a statement that applies a blanket faster over better is too broad and potentially bad advice. There are plenty of jobs where better outranks faster because quality is critical in those jobs. Construction, medicine, software for planes/nuclear power plants, ...

If any candidate sends me an email like this, that would be a pretty significant mark against their ability to understand and follow clear instructions. They said about 2 hours, and this response seems to be treating it as a hard deadline. It disregards the fact that the candidate was presumably asked to complete the task, not to get as far as they can in 2 hours. It also implies that the candidate is unwilling to spend even a minute more than 2 hours on the task, which doesn't send the best message about their work ethic.

@cdkMoose - agreed. Context is always important. Some jobs/projects emphasize quality over speed. Other jobs/projects emphasize speed over quality. I once worked on a software project that had a hard deadline. The CEO said "if we can't deliver this product on time, we are out of business". We delivered.

Although this is a very reasonable take, this will lose you some jobs immediately. If 9 candidates silently take a day to do the task, and the 10th asks for a day, some places will assume the 10th was the only one who needed more time and is therefore not up the standard set by the others. On one hand I would say places where this would lose you a job are not the most shining examples of places to work, but on the other only OP knows how badly they need/want this job. I think it's important to identify that there's a risk with this approach.

@BernhardBarker Well, something like "I expect you to do 4 hours of OT and work on weekends" is also "clear instructions", but I wouldn't recommend anyone to work for a place that does this. The issue is not whether they're following instructions, but that an employer expects 2+ hours of free work done from a candidate.

@BernhardBarker If you'd give me a full day's work and tell me it should take "about 2 hours", that's a significant mark against your ability to give realistic instructions. Questioning how I'm supposed to do a full day of work in 2 hours doesn't say anything about my ability to understand or follow instructions.

@BernhardBarker that's fair enough, but if I was your employee and you gave me substantially more work that was possible in the time, I'd professionally & politely ask questions to try to come to some compromise. If that would count against me, I think it's mutually beneficial that we both find that out in the interview process ASAP rather than months down the line.

@Nelson I'm not making any judgement about whether it is reasonable to give a candidate such a task, or what that might say about the company, but rather that this email, as it's written, seems likely to decrease the candidate's chances of getting the job. Your argument also seems to imply that the person reading this wouldn't actually want the job, but should we really be making that decision for them without their knowledge or consent by recommending a response that very likely doesn't align with their goal in interacting with the company in the first place?

@ChrisH If I say "complete this task" and you ask "should I only complete a portion of this task", I would very much question your ability to understand and follow instructions. If you say "it will actually take a lot longer than the rough estimate you gave, do you still want me to complete it, or just get as far as I can", that might be a different story. Although I still wouldn't expect them to give an answer other than "complete the task", if that's what they said initially, or to tell you to only spend "about 2 hours" on it, and then very likely heavily mark you down for not finishing it.

@BernhardBarker Prioritization of tasks is a fundamental part of Agile software programming. It's expected that not everything is likely to be accomplished, so asking for a clear list of what you should prioritize the completion of should be a mark in your favor in a software engineering role, if the boss knows anything about how to properly perform software engineering.

@nick012000 If you think demonstrating that you know prioritization exists (by asking how to prioritize, which doesn't actually demonstrating the ability to prioritize yourself in any way, or by prioritizing yourself) will be more important to the potential employer than actually being able to understand and follow clear instructions, finish a task and demonstrate work ethic, I suppose that's fair enough. It's not going to be the case for the vast majority of employers, but maybe you're looking for that one rare employer who would be on the same page as you on that.

@BernhardBarker As a software engineer, under Agile, it's not your job to do the prioritization, it's the job of the Product Owner (usually using a ranked backlog). Asking how to prioritize is a vital step to actually accomplishing successful software engineering projects.

@nick012000 Either way, that has little to do with how interviews are typically conducted. Interview assignments rarely need to be prioritised (in the sense of doing some tasks and not doing others), they usually need to be completed in full. When candidates do need to prioritise (like if there's a hard deadline they can't meet), it's usually left up to their discretion how they do so (but being unable to finish usually means they won't be invited to the next stage).