Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interview gone wrong

ashu1461.com

Post reply on HN
Print view View original

61–70 of 209 posts

Re: Interview gone wrong

#61

Post by zdragnar »

Terr_ wrote: post #56
reader9274 wrote: post #42

If 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.

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 duplication of the operator as merging the expressions into one.

Instead of what you would expect, per the rules of literally every other expression, 5 == 5 == 5:

    (== 5 (== 5 5))
It gets rewritten as

    (== 5 5 5)
Which one is "unexpected" is really a matter of perspective: are you reading with the rules of English or the rules of your programming language as your context?

I do concede one caveat to this argument: mathematical operators tend to change operator precedence around to avoid making mathematical mistakes. I am mildly of the opinion that this itself was a mistake. Most calculators don't do it, so it's not like anyone would be* that* thrown off by it.

Re: Interview gone wrong

#62

Post by Izkata »

pavel_lishin wrote: post #7
mlinhares wrote: post #4

Stopped judging candidates on "style" due to stuff like this. I only comment if the code doesn't work, if it works i don't really bother to correct code style or provide feedback on it. 45 minutes interviews aren't really the place to evaluate this.

It sounds like the author wasn't nitpicking style - they thought the code literally wouldn't work. (But, the intent on the interviewee's part was definitely clear - I'd definitely let this pass.)

The blog itself isn't clear, and I think that's confusing some of the people here:

> The candidate this time was programming in python

But the code blocks aren't in python. But in the paragraph afterwards they capitalize "True" which is a python thing. Then afterwards mention they're using javascript as their reference, which uses "true" instead and the code blocks could be javascript.

It feels like the author has more language confusion going on than just this one feature of python.

Re: Interview gone wrong

#63

Post by alkh »

In my mind,I just automatically translate a EXPRESSION1 b EXPRESSION2 c as (a EXPRESSION1 b) and (b EXPRESSION2 c), so there's no ambiguity. But I agree, it can be very confusing,so I tend to write code that is easy to read without being a master. For example, what would have guessed this evaluates to:

False is False is False. If you thought, True, you were right :)

I would recommend to take a look at one of my favourite repos for more[1].

[1]https://github.com/satwikkansal/wtfpython

Re: Interview gone wrong

#64

Post by necovek »

nerdponx wrote: post #59
necovek wrote: post #54

Earlier quoted context omitted.

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 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, functoo…

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 tha…

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 :)

Re: Interview gone wrong

#65

Post by devanl »

Animats wrote: post #50

I remember when that went into Python. It seemed too cute. There was a lot of that around the Python 3.4, 3.5 era. The case where all items are the same type is reasonable, but if implicit type conversions are invoked, it gets really complicated. Whatever the types are, Python will probably do something. Just not necessarily what you want. I could see having this if there was a compile-time constraint that all variab…

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...

Re: Interview gone wrong

#66

Post by 8n4vidtmkvmk »

lvturner wrote: post #49
userbinator wrote: post #36

Earlier quoted context omitted.

The norm in most of my interviews has been that candidates can solve coding problems in whatever language they are most comfortable with. I assume they've already filtered out candidates whose "most comfortable language" isn't the one they're hiring for, or they're going to have a difficult time when they come across the one who wants to use APL or x86 Asm.

I heard a tale of a candidate white boarding in an obscure language (in a bit of an attempt to hide a deficiency), unfortunately for the candidate the interviewer happened to be well versed in the language and saw right through the charade.

Hah. Even if the interviewer didn't see through the charade they have plenty of time to check the code after the fact. Once or twice a candidate has done something I didn't know about so I just googled it. Nice little learning opportunity for me.

Re: Interview gone wrong

#67

Post by Animats »

devanl wrote: post #65
Animats wrote: post #50

I remember when that went into Python. It seemed too cute. There was a lot of that around the Python 3.4, 3.5 era. The case where all items are the same type is reasonable, but if implicit type conversions are invoked, it gets really complicated. Whatever the types are, Python will probably do something. Just not necessarily what you want. I could see having this if there was a compile-time constraint that all variab…

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/

Re: Interview gone wrong

#68

Post by solveit »

polyomino wrote: post #30

This is a tangent, but checking if all the elements in the diagonal position are the same is not sufficient. You also need to check that any of the elements are not '-'.

Depends how the flow goes. It's reasonable to only check the diagonal when one player has actually played on the diagonal, in which case this is fine.

Re: Interview gone wrong

#69

Post by solveit »

murderfs wrote: post #25
Kim_Bruning wrote: post #3

This 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 think mathematicians looking at that expression would curl their lips in mild disgust, but also evaluate it to True.

Re: Interview gone wrong

#70

Post by WalterBright »

D 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.
Post reply on HN