Comment by shantnutiwari
8 hours ago
" but the interview engine is already running at full speed:"
I dont know if this is a recent thing, but I had a similar thing where an interviewer was racing forward, and would only accept the answers he had in mind.
In Python, he asked me how to search for substring. I was thinking but he started hurrying me. So I said regex and started writing a regex.
"No, there is an inbuilt method"
I couldnt remember the method. He asked me to google it, but there are dozens of string methods.
"I could use a regex?" I said and tried to show him how.
He ended the call, and 5 min later the agent called me to say my Python was sun-standard so they wouldnt be going forward.
This guy was a permanent employee and supposedly an expert
Step 1: https://www.google.com/search?q=list+python+string+methods
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.
So I don't code python. Is it find() or index() or is being terse and rude not really going to add inches to your dick?
You're thinking of a perfect world. We're not in it.
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?
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.
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.
1 reply →
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.
Is probably the obvious/canonical answer to the question of trying to find a substring.
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?
No, there's literally a "find" str method.
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 correct 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.
Commenting just to go against the other two answers. I think it's fine to not remember things, no matter the apparent simplicity.
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?
I think we're either reading very different comments or having very different understanding of what google search does :)
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.
I like such interviews. They tell me it's not a place I want to work at without wasting much time finding out.
The interviewer was right. If you don't know "if substring in string" by memory, your python programming is substandard. This should be automatic for anyone who works with python as a primary language. But if you can't even Google to find "if substring in string", why would anyone pay you even minimum wage to be a programmer?
I can't tell if you're trolling or not, but this is a ridiculous thing either wya.
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.
He was being rude, but I'm equally baffled by your description. It was very weird that you couldn't figure out which method is to search for substring when you have access to google search.
And it was triply weird that when he already said he wanted the non-regex way and you insisted on that.
I think there's zero excuse to be rude to candidates, and the 101 of interviewing is to make it as comfortable as possible for the candidate and not hurrying them up when they are thinking (which wouldn't rememble real work anyway, those aren't the typical time pressures one usually finds on the job... usually). You want them to succeed and not trip up; if anything because it means no more conducting interviews for you! Also, basic human decency.
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?).
Personally, I think the fact even after being asked to google another solution they still insist on the first solution came to their mind is the second biggest red flag.
(The biggest one is that they still think there is nothing wrong about this and decide to victimize themselves on HN.)