Context
Some time ago, I had an interview, and during the live coding session I followed all of the interviewer’s suggestions without questioning them. I wanted to show that I was open to new ideas, and the result?
A completely disorganized code. Were the interviewer’s tips bad? No! But they were certainly not the way I would have solved the problem.
Challenge
The challenge was very simple: basically, we had to organize the schedules of tour guides. The times were defined by slots, and if an overlap occurred, the events had to be grouped while still keeping a list of the original events.
Example: If we have the events [1,2], [1,3], [3,4], and [6,7], the result should be a single event [1,4] and another [6,7].
Problem
The problem started with the very first suggestion: “People usually start with the merge function” — and that led to sorting a list, loops, and a lot of object comparisons.
Solution
If I had followed my instincts, I would have done it in a completely different way.
One array per guide and date, and inside it all the available slots. I would distribute the events into this structure (without needing sorting) and in the end just group what was necessary.
With everything in memory, a simple loop with a recursive function would always look for the latest time in that slot until it found an empty slot or the end of the schedule. Then, it would merge the events and generate the overall event. In many scenarios, it wouldn’t even need to go through the entire list.
Challenges make you grow
What did I learn from this? That yes, we should be receptive to new ideas, but never set aside our own. In this case, the ideal (and expected) approach would have been to share my idea, discuss both, and move forward with the one considered most effective.
With Kotlin, this looks beautiful with functional programming. The final code is in this repository.
