Return to Answer

The interview reason for this task, is the intelligence in coordinating several elevators. As a normal user the behavior of an elevator is simple. But as house owner buying an elevator system, you want specs on the intelligence: what elevators do coordinated: no two elevators waiting on the same floor, going waiting at the first floor, secundarily at the top floor.

So I would have made the individual elevator behave consistently: up-going pressing a lower floor deferred handled after all up-floors are dealt with; downwards the reversed. Doors openable. In short: let everyone survive a ride.

Then with closed doors, with no buttons pressed for say 10 seconds, request the common intelligence/coordinator whether to go somewhere. It has to know where every elevator is, in which direction, with how much buttons pressed internally. It has to know wich floor buttons in which direction are pressed. That is the most interesting class. As time might not suffice, add comments on your ideas ("might do statistics, learning when rush hours are"). But the basics: if a floor button is pressed an elevator will pass the floor, decide whether to halt, or not (already many other floors pressed, an other elevator free).

Typically minimism is the best strategy. The states, the data model, states like direction and actors like buttons.

Even if you did not present an entirely satisfying piece of software, that would be much more interesting, do you not think too?

• You can do the above, without the technical object implementation.
• Use-case specification: controller.floorButtonPressed(floor, direction); physical: which floor buttons there are.
• In Model-View-Controller sense: what data you need to know of the elevators and floors, to determine what elevator to call in the controller.

Queues will automatically come to bear, when assuring that a pressed floor button will be served in reasonable time (no starvation).

The interview reason for this task, is the intelligence in coordinating several elevators. As a normal user the behavior of an elevator is simple. But as house owner buying an elevator system, you want specs on the intelligence: what elevators do coordinated: no two elevators waiting on the same floor, going waiting at the first floor, secondarily at the top floor.

So I would have made the individual elevator behave consistently: up-going pressing a lower floor deferred handled after all up-floors are dealt with; downwards the reversed. Doors openable. In short: let everyone survive a ride.

Then with closed doors, with no buttons pressed for say 10 seconds, request the common intelligence/coordinator whether to go somewhere. It has to know where every elevator is, in which direction, with how much buttons pressed internally. It has to know which floor buttons in which direction are pressed. That is the most interesting class. As time might not suffice, add comments on your ideas ("might do statistics, learning when rush hours are"). But the basics: if a floor button is pressed an elevator will pass the floor, decide whether to halt, or not (already many other floors pressed, an other elevator free).

Typically minimism is the best strategy. The states, the data model, states like direction and actors like buttons.

Even if you did not present an entirely satisfying piece of software, that would be much more interesting, do you not think too?

• You can do the above, without the technical object implementation.
• Use-case specification: controller.floorButtonPressed(floor, direction); physical: which floor buttons there are.
• In Model-View-Controller sense: what data you need to know of the elevators and floors, to determine what elevator to call in the controller.

Queues will automatically come to bear, when assuring that a pressed floor button will be served in reasonable time (no starvation).

The interview reason for this task, is the intelligence in coordinating several elevators. As a normal user the behavior of an elevator is simple. But as house owner buying an elevator system, you want specs on the intelligence: what elevators do coordinated: no two elevators waiting on the same floor, going waiting at the first floor, secundarily at the top floor.

So I would have made the individual elevator behave consistently: up-going pressing a lower floor deferred handled after all up-floors are dealt with; downwards the reversed. Doors openable. In short: let everyone survive a ride.

Then with closed doors, with no buttons pressed for say 10 seconds, request the common intelligence/coordinator whether to go somewhere. It has to know where every elevator is, in which direction, with how much buttons pressed internally. It has to know wich floor buttons in which direction are pressed. That is the most interesting class. As time might not suffice, add comments on your ideas ("might do statistics, learning when rush hours are"). But the basics: if a floor button is pressed an elevator will pass the floor, decide whether to halt, or not (already many other floors pressed, an other elevator free).

Typically minimism is the best strategy. The states, the data model, states like direction and actors like buttons.

Even if you did not present an entirely satisfying piece of software, that would be much more interesting, do you not think too?

The interview reason for this task, is the intelligence in coordinating several elevators. As a normal user the behavior of an elevator is simple. But as house owner buying an elevator system, you want specs on the intelligence: what elevators do coordinated: no two elevators waiting on the same floor, going waiting at the first floor, secundarily at the top floor.

So I would have made the individual elevator behave consistently: up-going pressing a lower floor deferred handled after all up-floors are dealt with; downwards the reversed. Doors openable. In short: let everyone survive a ride.

Then with closed doors, with no buttons pressed for say 10 seconds, request the common intelligence/coordinator whether to go somewhere. It has to know where every elevator is, in which direction, with how much buttons pressed internally. It has to know wich floor buttons in which direction are pressed. That is the most interesting class. As time might not suffice, add comments on your ideas ("might do statistics, learning when rush hours are"). But the basics: if a floor button is pressed an elevator will pass the floor, decide whether to halt, or not (already many other floors pressed, an other elevator free).

Typically minimism is the best strategy. The states, the data model, states like direction and actors like buttons.

Even if you did not present an entirely satisfying piece of software, that would be much more interesting, do you not think too?

• You can do the above, without the technical object implementation.
• Use-case specification: controller.floorButtonPressed(floor, direction); physical: which floor buttons there are.
• In Model-View-Controller sense: what data you need to know of the elevators and floors, to determine what elevator to call in the controller.

Queues will automatically come to bear, when assuring that a pressed floor button will be served in reasonable time (no starvation).

The interview reason for this task, is the intelligence in coordinating several elevators. As a normal user the behavior of an elevator is simple. But as house owner buying an elevator system, you want specs on the intelligence: what elevators do coordinated: no two elevators waiting on the same floor, going waiting at the first floor, secundarily at the top floor.

So I would have made the individual elevator behave consistently: up-going pressing a lower floor deferred handled after all up-floors are dealt with; downwards the reversed. Doors openable. In short: let everyone survive a ride.

Then with closed doors, with no buttons pressed for say 10 seconds, request the common intelligence/coordinator whether to go somewhere. It has to know where every elevator is, in which direction, with how much buttons pressed internally. It has to know wich floor buttons in which direction are pressed. That is the most interesting class. As time might not suffice, add comments on your ideas ("might do statistics, learning when rush hours are").

Typically minimism is the best strategy. The states, the data model, states like direction and actors like buttons.

Even if you did not present an entirely satisfying piece of software, that would be much more interesting, do you not think too?

The interview reason for this task, is the intelligence in coordinating several elevators. As a normal user the behavior of an elevator is simple. But as house owner buying an elevator system, you want specs on the intelligence: what elevators do coordinated: no two elevators waiting on the same floor, going waiting at the first floor, secundarily at the top floor.

So I would have made the individual elevator behave consistently: up-going pressing a lower floor deferred handled after all up-floors are dealt with; downwards the reversed. Doors openable. In short: let everyone survive a ride.

Then with closed doors, with no buttons pressed for say 10 seconds, request the common intelligence/coordinator whether to go somewhere. It has to know where every elevator is, in which direction, with how much buttons pressed internally. It has to know wich floor buttons in which direction are pressed. That is the most interesting class. As time might not suffice, add comments on your ideas ("might do statistics, learning when rush hours are"). But the basics: if a floor button is pressed an elevator will pass the floor, decide whether to halt, or not (already many other floors pressed, an other elevator free).

Typically minimism is the best strategy. The states, the data model, states like direction and actors like buttons.

Even if you did not present an entirely satisfying piece of software, that would be much more interesting, do you not think too?