It's clear to me that in a tech interview, unless otherwise told, it is your algorithm skill that is being tested. If I were you, I would begin talking about Fisher Yates, outline its implementation, explain why it correctly shuffles the list, show why it's an O(n) solution, etc. I might even talk about alternatives.
It's always better to demonstrate in an interview that you have a lot of knowledge about whatever that is being asked. It's not just being able to code, but also the ability to explain why and how it works.
Sometimes tech interviews will ask questions that are more along the lines of API memorization. They can be valid questions too, I've worked with "senior" developers that would implement their own sort algorithms (in .net) rather than use the built in ones. "Does this enormous framework I'm using have a way to do x" is a question some developers never ask.
It all comes down to the question asked, if they were literally asked to randomize a list then OP gave the correct answer, if they were asked to implement a list randomizer they were wrong. If the interviewee didn't make this explicit they were wrong.
This is completely subjective and depends on who is interviewing you. I could give a crap about someone's deep algorithim knowledge. I want to see them write productionizeable code.
Granted, there should be 1-3 people around who can be tapped for algo knowledge when bottlenecks need to be addressed. However the rest of the dev team just needs to worry about productionizeable code...
Often the people who know the algorithms struggle to write maintainable code that isn’t esoteric garbage to everyone but them and will fight to the death to say their way is correct. So your mileages may vary...
It's always better to demonstrate in an interview that you have a lot of knowledge about whatever that is being asked. It's not just being able to code, but also the ability to explain why and how it works.