I disagree: if you are demonstrating your mastery of a language (and with Python, these things are important: using appropriate syntax is the difference between dog slow code and fast code), you should use idiomatic patterns like the above.

Another of Python features is a great REPL: when unsure or confused by an interviewer, I'd just fire python from shell and type in 'x' == 'x' == 'x' to confirm and demonstrate it does the right thing (or write tests).

Obviously, the interviewer should be careful not to sidetrack the candidate much, and let them do the work and attempt to help only if things don't work out.

This is my opinion as well, but unfortunately isn’t always held by others. I once interviewed and by dint of knowing Python’s itertools module, absolutely destroyed the interviewer’s questions that they clearly thought would take some time to do.

I was told later that while I “obviously knew Python quite well, it didn’t give a good signal for my capabilities.”

>I once interviewed and by dint of knowing Python’s itertools module, absolutely destroyed the interviewer’s questions that they clearly thought would take some time to do.

If I see such a situation I usually ask the interviewer whether they want a concise solution using libraries or they want to see how I would do this if I had to do it from scratch.

Or I just offer both, I show that I can do it, but that I know it would be easier to do with x.

I think this is a great opportunity to show you're a good communicator as well as a problem solver.

Fair point.

In the real world you iterate, profile, and optimize

I am definitely a subscriber to not doing premature optimization, but in Python, there is a huge difference between

  found = searched_key in list(large_dict)

vs

  found = searched_key in large_dict

But also compare:

  searched_key in large_dict.keys()  # O(1)

and

  searched_value in large_dict.values()  # O(n)

So much this. Write code that you can reasonably expect to not be slow af, while not sacrificing readability. Then profile and optimize if necessary.

In this case the candidate evidently didn't understand it either, but was repeating a pattern they had seen before, which IMO is a form of anti-mastery: don't do things that you don't understand, especially when you're supposed to be demonstrating your skill and understanding.

Having a candidate understand all of the edge cases of a language syntax is a very high bar to clear: there is a lot of programmer between a "master" and "anti-master".

I've used Python for 20+ years, and while I'd confidently use a == b == c or 1 < a < 10, I didn't know the specifics and wouldn't use it in cases like 10 > a < 8 (or really, any other case chaining supports).

I believe myself to be an expert at Python and I'll explain differences between different loop types (while/for, ranges/iterators/generators, list comprehensions, functools, external C libraries like pandas or numpy), I think I wouldn't be confused only because I am aware I don't know the details and have a quick way to prove it works.

Maybe I interpreted the article differently than you did.

I got the impression that the candidate was repeating the x == y == z pattern because they'd seen it in other people's code and was pretty sure it worked, not because they knew about comparison chaining. At minimum I'd expect a candidate to be able to clarify that (x == y) == z is not the same thing, not just "idk it works whenever I do it". My reaction to that was: at some point, you do need to at least be able to reason about your own code.

In a more generous light, yes, I agree with everything you wrote. The precise details of comparison chaining are out of scope and I'm sure that most Python developers (myself included) don't know or remember them.

I agree that anyone (including an obviously juniorish candidate) using it should be able to explain it to an extent, but maybe not if you confidently and wrongly claim it doesn't work as an interviewer :)

But it's not a "trick", it's just a normal Python code.

I don't think that anyone who main programs in Python would perceive it as some kind of cool/unusual trick and not just normal code.

It's not a trick though. It's normal Python code. It's so common that you don't even think about it. It's just how equality comparisons work in the language.

If you're used to python, you wouldn't consider it to be a trick.

If you're giving interviews, and evaluating code in a language you don't know, don't be so confident it's wrong. Ask the candidate how it works.

I've used python for ~2y now and I'd balk at and rewrite this statement, considering it unclear at best.

That's an entirely reasonable point of view.

The important part here is that there are a substantial fraction of python developers that don't share your sentiment.

In this case the candidate also didn't know.

My usage of "yield" (alongside knowledge of "prange" from numba) in an interview instead of return has sealed the deal on a 200K offer (ML role circa 2020).

"Confusing" the interviewer is a totally valid strategy! It's the only strategy when python async is involved!

I suspect the interviewer would have likely been fine if they’d been able to explain chained comparisons and how they work. I would probably consider the interviewer using them without understanding them to be a negative signal.

It is possible that the candidate would normally use it from muscle memory, but got confused under the stress of the interview.

Fair enough. In general, I think the interview is a pretty lousy way to measure how good a software developer is.

“Language specific tricks” are the entire value proposition of there being more than one language.