alt Hacker NewsA regexp basically comes with a compiler. Who knows what sort of optimisations they've built in under the hood. It wouldn't be surprising if there was a special fast-path for efficiently searching for a substring; that'd be effective in practice.
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.
Questions like "how would you search for a substring?" are so incredibly dependent on what you're doing on a day-to-day basis, and what you're doing with the data once you've split it. Just because .split(...) is in all the tutorials doesn't mean the codebase you've worked on for the last 5 years actually uses that specific call with any regularity, and it may well be the case that your codebase does use regexs more often (maybe for query-portability purposes).
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.