3

This is my first interview for a software development company. As a part of their interview process, I am asked to solve a programming problem that was emailed to me.

Before I submit the solution, I have to write a document with my "design assumptions". What exactly does it mean?

Improve this question
6
  • 4
    Before you wrote the solution, didn't you have to design it? When you designed it, didn't you have to make some assumptions? Such as the hardware platform, the programming language and the APIs, etc.?
    – Nobody
    Nov 2, 2015 at 8:05
  • 3
    While this is borderline off-topic, I disagree with the current close vote reasons ("real questions have answers"): the OP's question seems rather obvious and well-defined to me.
    – Lilienthal ♦
    Nov 2, 2015 at 9:41
  • 2
    This really belongs on programmers.se in my opinion.
    – jmoreno
    Nov 2, 2015 at 15:26
  • 2
    I'm voting to close this question as off-topic because it belongs on programmers.se
    – jmoreno
    Nov 2, 2015 at 15:28
  • @Lilienthal the OP's question seems rather obvious and well-defined to me Yes, the question is well-defined on a programming related site, not on a general purpose SE such as Workplace. Wokplace deals with all sorts of jobs, not just programmers. Your answer below is good, but only good for a programming related site. For those who works on other jobs, it's hardly useful. For example, do I need to care about "analyse a complex system" if my job is to take care of a senior citizen?
    – Nobody
    Nov 3, 2015 at 3:42

1 Answer 1

Reset to default
11

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.

Improve this answer
3
  • 1
    You can even start smaller and a design assumption can be "The parameter X of my method will never be called with a null value" which would explain, that you did no null checks in your code (but also shows you're aware of the problem passing null values)
    – Aron_dc
    Nov 2, 2015 at 12:39
  • @Aron_dc It would depend on how technical the question is whether you should include preconditions as assumptions. Most programming exercises that I've seen focus more on the (functional) analysis of the target system and less on the technical implementation.
    – Lilienthal ♦
    Nov 2, 2015 at 12:41
  • 1
    All systems have assumptions, the worst devs I ever worked with did't realize this and mde assumptions unconsciously. These very frequently turned out wrong. Further good devs question the assumptions if they don't make sense with what the dev knows about the current system and business. For instance I once had a client tell me to do things one way and some other people who worked for the client wanted it the exact opposite way two days later. Because I was familiar with the first assumption, I was able to send the whole mess back to the client to figure out what they really needed.
    – HLGEM
    Nov 2, 2015 at 22:56

Not the answer you're looking for? Browse other questions tagged .