Throttle is different, it's a rate limiter, whereas debounce just measures delays between calls. With throttle, the server request would be made every 200ms rather than 200ms after the user stops typing. From a user experience though, throttle feels like a better way to approach this, since it would let you update the list at a measured pace, but it would be incorrect for the problem as described.
Right, from a UX perspective, throttle makes more sense due to more constant feedback. You want the user to realize that it is a live search before they finish typing. Else, they'll just type the entire query.
But obviously, in this case, the interviewer specifically outlined requirements that would make debounce the better choice than throttle.
Good point. I've generally used debounce for live search, and throttle for window resizing, among other things. In hindsight throttle is perhaps better for live search as well.
For window resizing, i'd actually use debounce. Most times, a user resizes a window with a predetermined size in mind -- they want to show something behind the window, or want to make the window fill an existing space.
In that case, showing live updates in the window during resizing might not be worth it.