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

81–90 of 209 posts

Re: Interview gone wrong

#81

Post by flakes »

throwaway313373 wrote: post #35
int_19h wrote: post #15

In this respect, Python makes a lot more sense since that is how you'd normally write such an equality in math, and generally how people chain them: A=B=C means A=B and B=C. Part of the problem here is that we treat true/false as "just another value" in programming, and thus the usual operators are used to compare them. In math notation, if you wanted to compare the result of comparison A=B to a Boolean value C, you'…

I think that the main issue here is not treating true/false as values but allowing them to be implicitly converted or compared to numbers with the assumption that true equals 1 and false equals 0. I think that Rust got this right. It doesn't allow you to add integer to boolean or multiply boolean by float etc, because it is unclear what does it even mean mathematically. Also, most languages implicitly assume that any…

A lot of languages have no boolean primitive to begin with. Often in older languages, the values for `true` and `false` are aliases for `0` and `1` respectively. Perl and earlier versions of C, Python, and JavaScript are notable.

Perl is probably the most awkward due to context-sensitive casting. e.g. the string `"0"` in a boolean context evaluates as an integer, and the boolean interpretation for `0` is false.

Re: Interview gone wrong

#82

Post by int_19h »

throwaway313373 wrote: post #35
int_19h wrote: post #15

In this respect, Python makes a lot more sense since that is how you'd normally write such an equality in math, and generally how people chain them: A=B=C means A=B and B=C. Part of the problem here is that we treat true/false as "just another value" in programming, and thus the usual operators are used to compare them. In math notation, if you wanted to compare the result of comparison A=B to a Boolean value C, you'…

I think that the main issue here is not treating true/false as values but allowing them to be implicitly converted or compared to numbers with the assumption that true equals 1 and false equals 0. I think that Rust got this right. It doesn't allow you to add integer to boolean or multiply boolean by float etc, because it is unclear what does it even mean mathematically. Also, most languages implicitly assume that any…

That resolves the problem for other types, but you still have the case of (a == b == c) being parsed and evaluated as ((a == b) == c) if all three are booleans, which is still not an intuitive interpretation. I think the PL either has to ban such construct outright and require parentheses, or treat it as an n-ary operator like Python does (albeit perhaps with a few more constraints on what you can chain, for the sake of readability).

Re: Interview gone wrong

#83

Post by Der_Einzige »

taxman22 wrote: post #2

Any time you use language specific tricks in an interview, you’re probably going to confuse your interviewer and not do well.

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!

Re: Interview gone wrong

#84

Post by throwaway313373 »

int_19h wrote: post #82
throwaway313373 wrote: post #35

Earlier quoted context omitted.

I think that the main issue here is not treating true/false as values but allowing them to be implicitly converted or compared to numbers with the assumption that true equals 1 and false equals 0. I think that Rust got this right. It doesn't allow you to add integer to boolean or multiply boolean by float etc, because it is unclear what does it even mean mathematically. Also, most languages implicitly assume that any…

That resolves the problem for other types, but you still have the case of (a == b == c) being parsed and evaluated as ((a == b) == c) if all three are booleans, which is still not an intuitive interpretation. I think the PL either has to ban such construct outright and require parentheses, or treat it as an n-ary operator like Python does (albeit perhaps with a few more constraints on what you can chain, for the sake…

I've just checked [0], Rust bans such construct for booleans as well.

[0] https://play.rust-lang.org/?version=stable&mode=debug&editio...

Re: Interview gone wrong

#85

Post by freehorse »

nothrabannosir wrote: post #53
bowmessage wrote: post #48

Earlier quoted context omitted.

That’s… what the article says.

That’s not what the article says. The last paragraph: if (cell[0][0] == cell[1][1] == cell[2][2]) { return Winner } > Well the code is indeed correct . Well done, Python… for finding yet another way to confuse us all. The code is incorrect: if all entries are '-' there is no winner. Even ignoring the braces…

You do not know how the game was implemented to assume that.

Re: Interview gone wrong

#88

Post by wiseowise »

Buttons840 wrote: post #29
necovek wrote: post #21

Earlier quoted context omitted.

Interviewer made a mistake and confused/sidetracked a candidate in a short interview.

The interviewer made no mistake though, they made an observation; they were confused by the boolean expression. The candidate said they understood the interviewers concerns and was also confused, and didn't have an immediate answer. This is all normal and healthy, and something you'd commonly see in healthy and competent development teams. The only thing I see that's wrong is that the interviewer thinks something wen…

Interviewer made a mistake, stop rationalizing.

Re: Interview gone wrong

#89

Post by selcuka »

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…

> Whatever the types are, Python will probably do something. Just not necessarily what you want.

Are you sure you are not confusing it with PHP? Python is not statically typed, but it is strongly typed. There is no implicit type conversion unless it's safe to do so (such as between a float and an int).

For example, print(1 > "foo") will raise a TypeError, and print("1" == 1) will print False.

Re: Interview gone wrong

#90

Post by pansa2 »

zdragnar wrote: post #61
Terr_ wrote: post #56

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

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

That's not true in Python though.

    a = b = c =
is equivalent to:

    temp = ; a = temp; b = temp; c = temp
I don't know why that order of evaluation was chosen.
Post reply on HN