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

181–190 of 209 posts

Re: Interview gone wrong

#181

Post by librasteve »

Raku (https://raku.org) supports the same design as Python3 ...

  0
The Chaining Binary Precedence is specified for this https://docs.raku.org/language/operators#Chaining_binary_pre...

That means you can make your own chaining comparison ops (or overload the current ones) with something like:

  multi infix:(Rat $l, Rat $r) { ($l-$r)
Much of Raku such as the default use of Rationals (Rat) is intended to make the language more approachable for non CS experts, so yes:

  0.1 + 0.2 = 0.3 # True

Re: Interview gone wrong

#182

Post by ubermonkey »

I don't code for a living anymore, but I think if I were writing Python I would probably AVOID using that idiom because of how jarring it could be to people who are unfamiliar with it, mostly due to how strange it is coming from other languages.

There doesn't seem to be a great upside to using it, and adding confusion to the codebase for whatever poor bum has to work on it later is bad karma.

Re: Interview gone wrong

#183

Post by phkahler »

TrainedMonkey wrote: post #118
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.

I have some experience in computer language design. The issue here is that `a==b==c` expression is magical - that is it does not follow from extending comparison binary operator. Specifically, `==` is a binary operator that that compares an expression before and after and returns a boolean. In this case, A==B==C is a trinary comparison operator. This is normally ok, except it's rare and the symbol it is using is over…

>> but there are heavy downsides. For example, it's not clear how short circuiting works.

Opinion: Code that depends on side effects like that in a conditional is BAD. It is not an optimization, it's an obfuscation.

Re: Interview gone wrong

#184

Post by the5avage »

irishsultan wrote: post #174
the5avage wrote: post #104

Earlier quoted context omitted.

I think it makes sense in python for ==, = I cannot see it for != "a != b != c" is not equal to "not (a == b == c)" which is a bit strange imo

I don't see how you could interpret "a != b != c" as equivalent to "not (a == b == c)" in the first place. In the first expression a doesn't equal b and b doesn't equal c (no restriction on a and c). In the second expression you could have a == b, but b != c (and vice versa), clearly that's not equivalent to the first expression.

"a == b" is the same as "not (a != b)"

Maybe I'm simple minded though.

Re: Interview gone wrong

#185

Post by Buttons840 »

wiseowise wrote: post #88
Buttons840 wrote: post #29

Earlier quoted context omitted.

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.

But is it "wrong" to make a mistake?

Re: Interview gone wrong

#186

Post by jbverschoor »

encomiast wrote: post #51
jbverschoor wrote: post #47

Earlier quoted context omitted.

But the code doesn’t work. That should be problem nr 1 for such a simple problem. Syntactical sugar doesn’t matter anymore at that stage

Maybe I misunderstood the piece, but it seems the last sentence, "Well the code is indeed correct" suggests it _did_ work (although I'm also a little confused about what it means when all values are '-' which I interpreted as 'no piece played').

The code might compile, but it does not functionally with in an empty game state. Resulting in an always win for the first player if he does not play on any diagonal

Re: Interview gone wrong

#187

Post by dsr_ »

_w1tm wrote: post #151
sampo wrote: post #129

Earlier quoted context omitted.

> it's not clear how short circuiting works It is clear if you read the docs. https://docs.python.org/3/reference/expressions.html#compari... https://docs.python.org/3/reference/expressions.html#boolean...

Is “let me check the docs” an appropriate thing to say in an interview setting?

Yes.

Extra points if you are familiar enough with the documentation to find the answer quickly.

Re: Interview gone wrong

#188

Post by Aachen »

gus_massa wrote: post #148
Aachen wrote: post #135

Earlier quoted context omitted.

I have no idea what this does or if you are joking. Could use some explanation

In Lisp, you put the "operator" first, so instead of 2 + 3 + 4 you write (+ 2 3 4) This is nice for associative operations like + or *, very very very slightly confusing for - and / --- You use the same style for comparisons, so instead of 2 == 3 == 4 you write (== 2 3 4) To support the fist "infix" syntax, you need some magic in the == operator. But the second "prefix" syntax is totally natural and you need no magic…

I knew that Lisp does this operator first thing, it's everything around this that I'm not familiar with. What does ; do? Is the => an arrow or greater than or equal to? What is t? Do I guess correctly that most-negative-fixnum is like INT_MIN?

Re: Interview gone wrong

#189

Post by andrelaszlo »

Fascinating, the task was supposed to be straightforward and a way to judge code quality etc. Yet, when the candidate solved it in a simple way, they were told they had a bug that they didn't have. This is okay of course, coding is hard. It could have been an interesting opportunity for discussion, I guess.

What's interesting to me is the conclusion that it's somehow Python's fault. I wonder if that attitude would work if it came from the candidate.

I think we should be more careful with tests like this. They need to be done with more humility, so it's great that the post was written!

Re: Interview gone wrong

#190

Post by tmtvl »

Aachen wrote: post #188
gus_massa wrote: post #148

Earlier quoted context omitted.

In Lisp, you put the "operator" first, so instead of 2 + 3 + 4 you write (+ 2 3 4) This is nice for associative operations like + or *, very very very slightly confusing for - and / --- You use the same style for comparisons, so instead of 2 == 3 == 4 you write (== 2 3 4) To support the fist "infix" syntax, you need some magic in the == operator. But the second "prefix" syntax is totally natural and you need no magic…

I knew that Lisp does this operator first thing, it's everything around this that I'm not familiar with. What does ; do? Is the => an arrow or greater than or equal to? What is t? Do I guess correctly that most-negative-fixnum is like INT_MIN?

The semicolon is Lisp syntax for comments. T is the way you write true in Lisp. Most-negative-fixnum is the most negative number Lisp can represent without promotion to bignum (so it can be int_min if int is roughly equivalent to size_t).
Post reply on HN