Serval Interview Experience — Interview Ended at 60 of 90 Minutes, Still Rejected

The onsite interview was 90 minutes: an hour of coding plus 30 minutes of DB schema design. The coding part had two sub-questions. You're given a list-based stream where each item has a timestamp (sorted ascending) and a motion intensity between 0 and 1. Given a threshold, find all the continuous time periods where the motion intensity is greater than or equal to the threshold, and return the start and end time of each period.

Part 1: Find Active Motion Periods

You are given a single camera that produces a stream of motion readings. Each reading consists of:

• a timestamp (sorted in ascending order)
• a motion intensity between 0 and 1

Given a threshold, return all time periods during which the motion intensity is greater than or equal to the threshold.

input:

readings = [
(1, 0.4),
(5, 0.2),
(11, 0.9),
(15, 0.9),
(17, 0.8),
(20, 0.3),
(27, 0.9),
(31, 1.0),
(36, 0.8),
]
threshold = 0.8

output:

[
(11, 17),
(27, 36)
]

The second question could reuse the first one — its input is a list of the first question's input.

Part 2

camera_streams = [
camera1_readings,
camera2_readings,
camera3_readings,
...
]

Return all time periods during which every camera has motion intensity greater than or equal to the threshold. I used part 1 to find the periods for each camera, then took the intersection.

The interview was scheduled over lunchtime — the interviewer showed up late because he said he was in line getting food, and he also stepped away from the camera for a bit in the middle. I actually finished the coding in 40 minutes. Then the schema question only took just over ten minutes, so the whole thing wrapped up at the 60-minute mark even though it was supposed to be a 90-minute interview. And I still got rejected — I have no idea what the bar was.

For the schema question, the operations were: book a flight, get the passenger list for a flight, get the flight for a passenger — how do you build the data model. I said to build three tables, talked about what the primary key of each one would be, and how to index for the fastest lookups, that kind of thing. Not sure what they were actually testing. The follow-up was: what if you need to temporarily hold a seat — so I added another seat-hold table. I asked him what he wanted but he didn't seem too sure either. I feel like the seat-hold part could have been expanded on more, but the interviewer seemed ready to wrap up too.