It’s the sort of thing where if you’ve written, like, any Python at all, it’ll be somewhere in the back of your head. It’d surface immediately on the job. But if you’d been using any other language earlier that day, it might not pop up reflexively, or in interview-stress mode.
It’s essentially trivia, and over-indexing on trivia is a mistake. But if they were a Python writer every day, I could see why they’d incorrectly expect everybody to have “in” in their l1 cache.
The interviewer is not asking to solve a problem here, they're asking for a simple ability to follow instructions, hence the offer to use Google to find the correct answer.
You could make a very solid case for using "in" (it is 2-4x faster), but only after you've solved the task at hand, this is what is expected in interviews. Not knowing the interview meta makes an average Joe basically unhireable in this market.
The existence of a more conventional .find method does some damage to my original point. Oops.
The reason is the intent behind their question, which they don't vocalize.
This question means we are dealing with an extremely broad hiring funnel designed to fail people who can't FizzBuzz and need to keep answers at MVP level.
In other words, if you are asked to put out a fire use a bucket of sand, not a state-of-the-art fire extinguisher.
Maybe this was a very junior position, but I'm with the interviewer here. Using regex would be very questionable - and a solid case of 1171.
Step 2: Parse the output with your eyes. The method is literally called "find".
This one-trick pony failure mode could perhaps have been fine for a guy who did Java and nothing but Java for 10 years, but you are supposedly the person who runs "pythonforengineers" website...
100% correct call by the interviewer.
In this one there are often thousands of applicants for a position, most of which can't pass FizzBuzz.
Why would they (or anyone for that matter) choose a candidate who can't figure out how to find info about a trivial method?
Quite surprised by others finding this as a... Surprise? I get there is people who never experience this, but they also not know anyone personally to whom this would happen?
if "needle" in haystack:
print ('haystack.__contains__("needle")')
So obvious that -to be fair- I blanked for a moment too. But 'in' is an operator, not a method (even though it calls __contains__ under the hood) . The question might have been slightly malformed?
str.find(sub[, start[, end]])
"Return the lowest index in the string where substring sub is found within the slice s[start:end]. Optional arguments start and end are interpreted as in slice notation. Return -1 if sub is not found."
Your instinct to resort to "in" is correc,t as it's generally slower than the "in" membership test, but the interviewer has even allowed the use of Google. Blanking out after that is really bad.
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.
And it was triply weird that when he already said he wanted the non-regex way and you insisted on that.
That said, really... finding a trivial python function using google search, that is a real life work skill. It's 100% real and not made up for interviews. I guess these days one would ask the LLM, too. The only artificial thing was the time pressure which, granted, complicates things needlessly, but other than that, the fact the candidate didn't come up with an answer is still a red flag. (I wouldn't disqualify them just for this, but maybe there were other red flags already?).
(The biggest one is that they still think there is nothing wrong about this and decide to victimize themselves on HN.)
I've used Python as my main language for ~10 years in various professional roles (DS, DE, SWE) and I so rarely need the exact construction `substring in string` that I probably would have blanked on it too in an interview. 99% of my string processing is .startswith/.endswith and re.search, that's just the way it goes. Hell, I know the difference between re.search and re.match by heart (do you? no? you're substandard!) but I genuinely forgot that `in` works on strings.