Assumptions are common element of any programming project and can usually be understood to be a set of constraints that narrow the scope of the project both technically and functionally. A good requirements analysis will result in a functional specification that outlines what the program/solution should do, who will use it and why. In that sense a functional spec can be seen as a collection of assumptions that have been validated with business. This is why some programmers consider assumptions to be a bad thing as they might not have been checked with the prospective users of the system, leading to a dangerous misalignment on scope and functionality.
To illustrate what assumptions programmers can make, here are a few examples:
- "The system will never be used by multiple users at once." This avoids the need for concurrency support, this is a dangerous assumption these days since it's hardly ever true.
- "We expect 1000 requests a day for the first year, ramping up to 5000 within 3 years." This can determine technical resources and the level of optimisation required.
- "The discombobulator won't ever be confabulated." Statements like these simplify the responsibilities of the program and specify the behaviour. A less abstract example would be "A customer can't ever have more than one account."
- "The system needs to run on a Linux environment."
The reason these can be dangerous is when they're not checked with the users first. If you build your entire solution without supporting multiple-user access and it then turns out that Bob from accounting also needs to approve Sales Orders while Alice is busy adjusting them you get to redesign your system.
Now, when it comes to programming tests like the ones you describe, assumptions have a more important role: they reduce the example scenario to something that has a workable solution and a scope that's limited enough to be developed by one person in a few hours. The goal of such an exercise is not to deliver a working solution but to show that you can correctly analyse the requirements of the system, identify pitfalls and account for possible issues. All those will be listed in your assumptions. Explaining them correctly shows that you can look past the basics in the use case description, analyse a complex system and reduce it to its core features. These are all vital skills for a good programmer.