As an interviewer, I would consider this to be a failed attempt. Simply put, it's conceptually wrong. No elevator that I have ever encountered acts as a queue. In a single-elevator system, it should go up, stopping at all requested floors on the way, until there are no more pending requests for higher floors, then it should service all of the down requests in descending order. The order in which the requests are submitted does not matter; the timing does matter, though.
In an interview, you should usually submit the simplest solution that works (then ask for feedback, and refine the solution as necessary). I see that you wrote an interface and an implementation, so I would challenge you to explain why you felt that an interface was needed. Are you anticipating the need for multiple implementations? One such justification might be to implement a multi-elevator system in the future. But in that case, your interface would not be sophisticated enough. With multiple elevators, you would need to distinguish between external and internal requests: external requests (consisting of a floor and desired direction) may be served by any elevator, but internal requests (consisting of a destination) must be served by a specific elevator. Furthermore, you would probably want to model the system using a controller that directs the elevators' movements. With multiple elevators, the algorithms for deciding which elevator to dispatch to handle an external request could get quite sophisticated. If you are planning for growth (which doesn't look like the case here), a // TODO comment would be helpful.
One minor observation: you have a maxCapacity field. What is it for? "Max" capacity sounds redundant — why not just "capacity"? Are you talking about limiting the load that the elevator is carrying (which you haven't modeled), or limiting the number of requests (which makes no sense)? In any case, I'd avoid leaving unexplained dead code when submitting a solution.
As an interviewer, I would consider this to be a failed attempt. Simply put, it's conceptually wrong. No elevator that I have ever encountered acts as a queue. In a single-elevator system, it should go up, stopping at all requested floors on the way, until there are no more pending requests for higher floors, then it should service all of the down requests in descending order. The order in which the requests are submitted does not matter; the timing does matter, though.
In an interview, you should usually submit the simplest solution that works (then ask for feedback, and refine the solution as necessary). I see that you wrote an interface and an implementation, so I would challenge you to explain why you felt that an interface was needed. Are you anticipating the need for multiple implementations? One such justification might be to implement a multi-elevator system in the future. But in that case, your interface would not be sophisticated enough. With multiple elevators, you would need to distinguish between external and internal requests: external requests may be served by any elevator, but internal requests must be served by a specific elevator. Furthermore, you would probably want to model the system using a controller that directs the elevators' movements. With multiple elevators, the algorithms for deciding which elevator to dispatch to handle an external request could get quite sophisticated. If you are planning for growth (which doesn't look like the case here), a // TODO comment would be helpful.
One minor observation: you have a maxCapacity field. What is it for? "Max" capacity sounds redundant — why not just "capacity"? Are you talking about limiting the load that the elevator is carrying (which you haven't modeled), or limiting the number of requests (which makes no sense)? In any case, I'd avoid leaving unexplained dead code when submitting a solution.
As an interviewer, I would consider this to be a failed attempt. Simply put, it's conceptually wrong. No elevator that I have ever encountered acts as a queue. In a single-elevator system, it should go up, stopping at all requested floors on the way, until there are no more pending requests for higher floors, then it should service all of the down requests in descending order. The order in which the requests are submitted does not matter; the timing does matter, though.
In an interview, you should usually submit the simplest solution that works (then ask for feedback, and refine the solution as necessary). I see that you wrote an interface and an implementation, so I would challenge you to explain why you felt that an interface was needed. Are you anticipating the need for multiple implementations? One such justification might be to implement a multi-elevator system in the future. But in that case, your interface would not be sophisticated enough. With multiple elevators, you would need to distinguish between external and internal requests: external requests (consisting of a floor and desired direction) may be served by any elevator, but internal requests (consisting of a destination) must be served by a specific elevator. Furthermore, you would probably want to model the system using a controller that directs the elevators' movements. With multiple elevators, the algorithms for deciding which elevator to dispatch to handle an external request could get quite sophisticated. If you are planning for growth (which doesn't look like the case here), a // TODO comment would be helpful.
One minor observation: you have a maxCapacity field. What is it for? "Max" capacity sounds redundant — why not just "capacity"? Are you talking about limiting the load that the elevator is carrying (which you haven't modeled), or limiting the number of requests (which makes no sense)? In any case, I'd avoid leaving unexplained dead code when submitting a solution.
As an interviewer, I would consider this to be a failed attempt. Simply put, it's conceptually wrong. No elevator that I have ever encountered acts as a queue. In a single-elevator system, it should go up, stopping at all requested floors on the way, until there are no more pending requests for higher floors, then it should service all of the down requests in descending order. The order in which the requests are submitted does not matter; the timing does matter, though.
In an interview, you should usually submit the simplest solution that works (then ask for feedback, and refine the solution as necessary). I see that you wrote an interface and an implementation, so I would challenge you to explain why you felt that an interface was needed. Are you anticipating the need for multiple implementations? One such justification might be to implement a multi-elevator system in the future. But in that case, your interface would not be sophisticated enough. With multiple elevators, you would need to distinguish between external and internal requests: external requests may be served by any elevator, but internal requests must be served by a specific elevator. Furthermore, you would probably want to model the system using a controller that directs the elevators' movements. With multiple elevators, the algorithms for deciding which elevator to dispatch to handle an external request could get quite sophisticated. If you are planning for growth (which doesn't look like the case here), a // TODO comment would be helpful.
One minor observation: you have a maxCapacity field. What is it for? "Max" capacity sounds redundant — why not just "capacity"? Are you talking about limiting the load that the elevator is carrying (which you haven't modeled), or limiting the number of requests (which makes no sense)? In any case, I'd avoid leaving unexplained dead code when submitting a solution.