Comment by bee_rider
1 hour ago
I’d call this an understandable mistake on the part of the interviewer. “in” is a pretty commonly used operator. But it is also a bit unusual/trivial, in the sense that most languages would have a method or a function instead.
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 "in" operator is not unusual or trivia, it's something people who code in python use all the time! Python does have a function (or more accurately a method), it's called __contains__ and it's invoked by "in". I would expect a python developer to be able to comment on whether python uses a fastsearch algorithm or not, they should be able to comment on BM and H algorithms.
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.
I don't understand how you jumped to the membership test instead of literally the .find() method on a string?
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 unfortunate answer is just that I didn’t think of .find before thinking of “in,” haha. Nothing too clever going on in my head.
The existence of a more conventional .find method does some damage to my original point. Oops.