Comment by stemchar
7 hours ago
I probably would've done the same. "I don't remember what the function is called" would've been fine-ish, but reaching for a regex is just insane.
7 hours ago
I probably would've done the same. "I don't remember what the function is called" would've been fine-ish, but reaching for a regex is just insane.
Why? Unless it's an extraordinarily hot code path, it doesn't matter. A regex once compiled will be quite efficient.
It's simple, unless you're given a specific broader context (like we have an enterprise customer data pruning system that needs to handle a broad range of corner cases) then you must not resort to overengineering this early in an interview.
And an extra import. also, it sounds like they where looking specifically for knowledge of built-in operators.
A 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.
It kind of depends on the substring and problem context.
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.
Sarcastic or for real? Because I find that an obvious choice, a little depending on context though.