I approached the problem by first discussing a naive merging method using a brute force approach that would involve picking nodes from each list, but quickly pivoted to a more efficient practice. I suggested using a min-heap to maintain the order of nodes from each linked list, merging them in O(n log k) time, where n is the total number of nodes and k is the number of linked lists. The interviewer seemed engaged and asked for clarifications on handling edge cases, such as when some lists might be empty. I provided a couple of examples and explained how the heap would work in those scenarios.

While I articulated my initial thought process well, I struggled with the implementation details. There were moments where I hesitated and second-guessed my approach, especially when coding the merging logic. As I coded, the interviewer prompted me with questions, which ironically made me more anxious but also helped clarify my thought process and refine my code as I went. It was a mixed experience: I appreciated the probing, but I felt a bit unsteady.

I made several syntax errors and spent precious time correcting them, which led to the interviewer stepping in to help guide the final logic. While he was supportive, it stung to realize that my unwillingness to pause and think through my syntax led me to delve into wrong assumptions in the code. I knew the algorithm conceptually but mixed it up during the implementation, which is a crucial skill in coding interviews.

Overall, despite the challenges I faced during the coding portion, I felt that I managed to communicate my algorithm well, showcasing my understanding of the underlying principles. The back-and-forth nature of the interview kept me engaged, but I left feeling like I could have executed better. Ultimately, the interviewer expressed that it was a complex problem and encouraged me to take my time in real-world scenarios, but the experience raised a few doubts about how well I handled pressure and problem-solving in real-time situations.