But more importantly it is hugely context sensitive on how often the function is going to be called and what IO needs to happen around it to decide if speed matters at all.
Using a regex as a first attempt is entirely reasonable. Especially in an interview about Python. If we care about efficiently doing substring matching Python isn't the language of choice. If a programmer just wants to remember how regex work and get on with their day they'll do fine at handling string problems.
I write bare metal firmware, primarily in C, and I've had to make it a point to explain, in most every interview I do, that I've only ever used malloc(...) in tutorials. "In my world, malloc is a 4-letter word". So while I know what it does, and how it works, I actually have to google its usage, and I'm not as keyed into its pitfalls, because every system I've ever worked on could not afford the risks associated with dynamic memory allocation.
All of this to say, bad interviewers go looking for a specific answer, good interviewers go looking for good process. All of the jobs I've held are ones that accepted that I was rusty on this or that specific call, but could think about the system holistically.
Arbitrary substring in arbitrary text vs extracting embedded plant code from product serial numbers.
As long as you've got a good explanation for what you chose and why you chose it and the pro/con it's probably fine.