Any time you use language specific tricks in an interview, you’re probably going to confuse your interviewer and not do well.
“Language specific tricks” are the entire value proposition of there being more than one language.
Interview gone wrong
71–80 of 209 posts
Re: Interview gone wrong
#72Earlier quoted context omitted.
Yeah, the behavior is arguably much less confusing than the alternative of: 5==5==5 # All three the same (5==5)==5 true==5 false Or 1==2==false # All three different, in a troublesome way (1==2)==false false==false true
I dunno, I'd expect the right hand expression (2 == false) to be resolved first, then compared to 1. Compare this with a = b = c = 5 You evaluate the innermost (i.e. the tail) expression first, and work your way out to the head. As a sexpr it is a little more obvious that way: (= a (= b (= c 5))) An argument could easily be made that python is making up special rules for the equality operator by treating the duplicat…
> An argument could easily be made that python is making up special rules for the equality operator by treating the duplication of the operator as merging the expressions into one.
I guess the argument could be made but it would be wrong. All the comparison operators can be chained in python. a < b < c, for example, or even a == b <= c < d.
Re: Interview gone wrong
#73I know the point of the piece is the python syntax here, but I got stuck on: "judge things like code quality / speed / conciseness etc." Do people generally write concise code on right off the bat when confronted with a new problem? I've always taken the same approach I would with writing: get something that works; refactor for concision. Maybe everyone else is playing 3D chess and I'm still on Chutes and Ladders?
Do people generally write concise code on right off the bat when confronted with a new problem?
As someone who has been on the interviewer side: this is an indicator of how much the interviewee "thinks first"; the ones who immediately start spewing tons of code are usually those who don't really have a good understanding of what they're trying to do.
Re: Interview gone wrong
#74Earlier quoted context omitted.
This feels a bit like a case of a "Python from 10 years ago in my head" vs "Python from 10 years ago in reality" meme. Chained comparisons have been in Python since I started using it at 2.1. It looks to me like they've been there since at least 1.4: https://docs.python.org/release/1.4/tut/node40.html#SECTION0...
Ah. I'm thinking of [1] from 2016, when there was a plan to add short-cut evaluation to short-cut comparisons. That avoids evaluating all the terms when not necessary. But that was deferred. [1] https://peps.python.org/pep-0535/
That's so lazy!
Re: Interview gone wrong
#75If you know nothing about Python or coding, and you see a=b=c, you'd think that's true when all three a,b,c are the same. Python does that beautifully here, and that's the intent. It's not Python that's confusing, it's your previous experience with other languages that's confusing you.
Most programming languages ought not to be optimized for a non-programmer to read, but rather for someone who writes code to read.
There's a lot of options for a language to deal with a statement like this. It could be a syntax error, a compile or lint warning, it could work by doing order of operations and comparing the boolean from one compare with the third element, or it could work in the way you described.
I'd prefer languages that I work with to chose earlier options from that list. In most languages this sort of statement is usually a bug, and deserves explicit parenthesis to clarify the order of operations. I really don't want to have to pull out an operator precedence chart in order to read your code, much less have to look up some esoterica about this specific language.
Re: Interview gone wrong
#76Any time you use language specific tricks in an interview, you’re probably going to confuse your interviewer and not do well.
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.
Re: Interview gone wrong
#77I know the point of the piece is the python syntax here, but I got stuck on: "judge things like code quality / speed / conciseness etc." Do people generally write concise code on right off the bat when confronted with a new problem? I've always taken the same approach I would with writing: get something that works; refactor for concision. Maybe everyone else is playing 3D chess and I'm still on Chutes and Ladders?
Do people generally write concise code on right off the bat when confronted with a new problem? As someone who has been on the interviewer side: this is an indicator of how much the interviewee "thinks first"; the ones who immediately start spewing tons of code are usually those who don't really have a good understanding of what they're trying to do.
Thinking first is a very Cartesian approach to development and not necessarily the best way. Many people think through a more engaged approach of doing
Re: Interview gone wrong
#78D solved the problem with what happens with (a == b == c) in an unusual way. It gives an error message. Both the C way and the Python way are considered wrong. You're going to have to add ( ) to clarify.
Rust also gives a custom error message [0] that explicitly explains that "comparison operators cannot be chained" and shows you how to rewrite the expression using `&&`.
Which makes me wonder whether they came up with this idea themselves or if they borrowed it from D.
In any case, I think that this is the only reasonable solution for new languages. Because if you go with C way it will be surprising for people who expect Python way and vice versa. So, making this syntax illegal is the only way to uphold the principle of least astonishment [1].
[0] https://play.rust-lang.org/?version=stable&mode=debug&editio...
[1] https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
Re: Interview gone wrong
#79This mirrors mathematical notation for things like ranges or equality checks 5 x == y == 10
Unfortunately, it's more permissive than mathematical notation: `3 > 1 < 2` evaluates to True.
I can think of some more interesting examples when it violates intuition gained from mathematical notation.
When looking at `a == b == c` we naturally assume that not only `a == b` and `b == c` but also `a == c` because equality is assumed to be transitive.
The problem is that in Python we can make `==` operator to do literally whatever we want, so in Python `==` doesn't have to be transitive.
You may argue that no reasonable person would define equality in such way that is not transitive.
To which I would reply that approximate comparison of floating point numbers looks perfectly reasonable to me.
EPSILON = 10**-9
class Foo:
def __eq__(self, other):
return other.bar - EPSILON