└── README.md


/README.md:
--------------------------------------------------------------------------------
  1 | # Accumulated Times
  2 | 
  3 | ## Problem Statement
  4 | 
  5 | A dasher is dropping off orders in a large building and we want to
  6 |  compute how much time they spend in each room. We are given a list of elements containing the name of a room, a time period, and a value
  7 | indicating whether a user is entering/leaving the room. The dasher cannot be in more than one room
  8 | at the same time. Once they exit a room, they return to the previous room. Determine the time spent in each room.
  9 | i.e.: 
 10 | ```
 11 | Lobby 0 Enter
 12 | Hallway1 10 Enter
 13 | Room1 30 Enter
 14 | Room1 40 Exit // back in hallway1 now
 15 | Room1 50 Enter
 16 | Room1 60 Exit
 17 | Hallway1 90 Exit // back in Lobby
 18 | Hallway2 100 Enter
 19 | Hallway2 150 Exit
 20 | Lobby 160 Exit
 21 | ```
 22 | 
 23 | Output:
 24 | ```
 25 | map(Lobby = 30, Hallway1 = 60, Room1 = 20, Hallway2 = 50)
 26 | ```
 27 | 
 28 | Allow the interviewee to construct their own data structures for function input/output.
 29 | Gain some understanding of whether they are comfortable in their language of choice and if they have
 30 | some reasoning for their choice.
 31 | Some examples:
 32 | ```
 33 | Kotlin - List<Data class(enum, int, boolean/enum)> for cleanliness, readability, and unit testability
 34 | Python - List<Tuple> for ease of looping through
 35 | ```
 36 | 
 37 | ### Constraints
 38 | 
 39 | Candidates should ask for these themselves in order to fully grasp the problem.
 40 | If these are given by the interviewer or not considered in any way, reflect in scorecard below.
 41 | 
 42 | - Elements are sorted with respect to time.
 43 | - No negative times.
 44 | - Can assume valid flow. Each entered room will have an exit.
 45 | - Can assume non-cyclical/non-recursive flows. A dasher can't re-enter the room 
 46 | they're already in and they won't re-enter a room they've already entered without exiting. (i.e. Once in Hallway1, can't enter Lobby)
 47 | 
 48 | ## Interviewer Notes
 49 | 
 50 | ### Solution
 51 | The proposed solution uses a stack to maintain a memory of which room the dasher is currently in.
 52 | We then keep track of how much time they've spent in the room since the last action and we can increment
 53 | our returned data structure accordingly.
 54 | 
 55 | #### Things to Consider
 56 | 
 57 | There are plenty of solutions, however a stack approach is intuitive and efficient.
 58 | 
 59 | Don't reveal the constraints above and see if the interviewee clears up ambiguity and thinks through potential edge cases.
 60 | 
 61 | For hints, can also provide the constraints above.
 62 | 
 63 | ### Extension 1
 64 | 
 65 | What if we can be given a sequence where not every begin has a matching end and we want to return null/empty in these cases?
 66 | i.e.
 67 | ```
 68 | Enter lobby
 69 | Enter floor 1
 70 | Enter hallway 1
 71 | Exit hallway 1
 72 | Exit lobby
 73 | ```
 74 | 
 75 | We can expand on this case shown in the solution.
 76 | ```
 77 | if (!currentElement.entered) {
 78 |     stack.pop()
 79 | } else {
 80 |     stack.push(currentElement.room)
 81 | }
 82 | ```
 83 | 
 84 | And change this to: 
 85 | ```
 86 | if (!currentElement.entered) {
 87 |     if (currentElement.room != peakedElement) {
 88 |         return emptyMap()
 89 |     }
 90 |     stack.pop()
 91 | } else {
 92 |     stack.push(currentElement.room)
 93 | }
 94 | ```
 95 | 
 96 | In addition we need to account for the case where we have an incomplete begin statement.
 97 | This can be done near the end with an empty check on the stack: 
 98 | ```
 99 | if (!stack.isEmpty()) {
100 |     return emptyMap()
101 | }
102 | ```
103 | 
104 | See `extended_solution.kt`.
105 | ### Extension 2
106 | 
107 | Design unit tests for given function. Look for full branch coverage at the very least. 
108 | All code flows should be tested. Bonuses for boundary test cases and more bad data test cases (cases looking to
109 | break the function which can help highlight missed constraints above). 
110 | 
111 | This extension highlights a candidate's ability to reason through test cases as well as
112 | to gauge whether they've missed any edge cases/assumptions. 
113 | 
114 | ### Evaluation
115 | 
116 | The candidate should be able to solve the base problem and extension unit test cases in the given time with minimal help.
117 | 
118 | Rubric:
119 | ```
120 | Inputs (0-1):
121 | - Reasonable input: 1
122 | - Little thought given to input which leads to unnecessary complication of algorithm: 0
123 | 
124 | Clearing ambiguity (0-2):
125 | - Asks about at least 3 of the constraints: 2
126 | - Asks about at least 2 of the constraints: 1
127 | - Else: 0
128 | 
129 | Actual execution/coding of problem (0-10):
130 | - No help needed, able to design efficient solution: 10
131 | - Minimal help needed: 8-9
132 | - Some help needed, particularly in getting started: 5-7
133 | - Significant help needed and/or answer not finished completely: 0-4
134 | 
135 | Extension 1 (0-3):
136 | - Fully able to solve extension (all cases) without any help: 3
137 | - Missing/help needed with the non-empty stack check: 2
138 | - Missing/help needed with the in-loop check: 1
139 | - Missing both checks: 0
140 | 
141 | Extension 2 (0-3): 
142 | - Well thought out unit tests with all branch/empty cases as well as consideration for boundary and edge cases. Deep understanding of industry standard unit testing practices: 3
143 | - Clear thought process used in unit tests. At least covers all branch statements including empty/null cases: 2
144 | - Missed cases. Little/no logic used when designing tests. Random approach rather than making tests based on the code itself: 0-1
145 | 
146 | Recommended scorecard:
147 |     Strong yes: 18-19
148 |     Yes: 15-17
149 |     No: 7-14
150 |     Strong no: 0-6
151 | ```
152 | 


--------------------------------------------------------------------------------