This was the dasher pay question from the interview reports on the forum. I spent a good chunk of time up front discussing the requirements and the data shape. I wanted to get part 1 done with a simple algorithm first and worry about the rest later, and I had already finished writing it, but the interviewer was clearly unhappy and hinted that I should use a sweep line. Changing the code took quite a while. (A gripe here: the recruiter explicitly said the interview is about getting a workable solution first and only then optimizing, and the interviewer clearly did not want that at all, so be fully prepared.) After I rewrote it, he asked what edge cases I'd consider, and we discussed some things that felt like system design questions. I thought we might be done at that point, but then he threw out part 2, which adds peak windows. In my earlier practice I had put the peaks into the input, sorted everything together, and then run a sweep line. But the interviewer said no sorting. This is where I made a mistake: I went with checking at every time point whether a peak window matches, but getting that logic right takes a lot of time (maybe it doesn't have to, but I hadn't thought it through in the moment), so I had to regress and say I could use binary search to insert the peak times into the input (both are pre-sorted), which avoids the sort. With one minute left the interviewer called time while I was still two or three lines short of finishing; he said it was fine as it was. Overall I don't think my chances of passing are high. I made several mistakes and had no time left to run the code. The lesson is that even though the problem isn't hard, the interviewer may add requirements on the spot, and if you haven't thought it through or prepared in advance, all kinds of things can go wrong in the moment.
DoorDash Software Engineer Interview Experience — Dasher Pay Phone Screen with a Surprise Sweep Line and Peak Windows Follow-up
Technical Screenhard
Published
Curated and edited by PracHub
Discussion
Loading comments…