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

161–170 of 209 posts

Re: Interview gone wrong

#161

Post by quietbritishjim »

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.

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

Sure, that's true if you literally know nothing about coding. But that is not a very common audience for reading code. You only need to spend about 10 minutes coding to realise that the compiler follows fixed rules rather than making an LLM-like guess as to the meaning. If you get that far then most people (admittedly after a bit more 10 minutes) go on to realise that the only way to know what code does is carefully pick it apart step by step, rather than glance at it and guess yourself.

I love Python dearly, but this rule was a misstep on my opinion.

Re: Interview gone wrong

#162

Post by quietbritishjim »

throwaway313373 wrote: post #84
int_19h wrote: post #82

Earlier quoted context omitted.

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

That is impressive.

Re: Interview gone wrong

#163

Post by tmtvl »

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…

> very very very slightly confusing for - and /

It's fine if you DNF it:

  (- a b c) => (+ a (- b) (- c))
  (/ a b c) => (* a (/ 1 b) (/ 1 c))

Re: Interview gone wrong

#164

Post by spacebanana7 »

tbrownaw wrote: post #32
encomiast wrote: post #23

I 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?

There are degrees of conciseness. I've seen real code that looks like if(bool_var == false) { other_bool_field = true; } else if(bool_var == true) { other_bool_field = false; } Which I suppose could be called anti-concise.

When I see code like that, I wonder whether a beginner is trying to fix a bug where they unexpectedly copied by reference rather than value.

Re: Interview gone wrong

#165

Post by otherme123 »

vdvsvwvwvwvwv wrote: post #144
otherme123 wrote: post #119

Earlier quoted context omitted.

And the nerve to put Javascript as the example about how equality should work, a language known for: 0 == '' evaluates to True 0 == '0' evaluates to True false == 'false' evaluates to False false == '0' evaluates to True ' \t\r\n ' == 0 evaluates to True and the === operator you need to overcome the above. I don't have anything against JS and I understand why it is done that way, but if some language has weird and co…

It is merely syntatically confusing. Make == be ~~ or .fuzzyCompare() And === be == And you are fixed.

Paraphrasing: "Well done, Javascript… for finding yet another way to confuse us all."

I don't know many programming languages, but of the few I know any of them has a === because == is so confusing that you don't know exactly if (or when) it would bite you. You can't attack any language for their comparison operators from the Javascript camp.

It that blog post removed the sentence "And this is how it would definitely happen if the code was written in javascript" they would be fine. But you actually don't know what would definitely happen in Javascript with the line in question "cell[0][0] == cell[1][1] == cell[2][2]", unless you know 100% what is in these cells. For example:

cell[0][0] is "0", cell[1][1] is 0, cell[2][2] is true

and "cell[0][0] == cell[1][1] == cell[2][2]" evaluates to True.

Re: Interview gone wrong

#166

Post by jeroenhd »

laurentlb wrote: post #109

Python chained operators can be confusing, especially as it allows you to write things like: — x z — a in b not in c WalterBright mentioned that D will give you an error. When designing Starlark (a derivative of Python), I also decided to give an error for this, by making the comparison operators non associative. https://github.com/bazelbuild/starlark/blob/master/design.md... I agree this Python feature can look cute…

I find these expressions a lot more readable for bound checks (like `if 0 = 0 && n The way it works in Python allows for some hilariously unreadable code, but the concept itself is good. I think it just needs more constraints to maintain readability, such as not allowing flipping the comparison sign (like in xz).

Banning these chained comparison operators is not necessarily a bad idea as comparison operators can easily cause confusion in that manner, but the reason they cause confusion is that many programming languages use mathematical symbols differently than actual math. A=B=C is perfectly understandable and more readable than A=B ∧ B=C. Restraining ourselves to "operand operator operand" as the only infix expression model made sense decades ago when computers had storage counted in kilobits. Today, we can let go of the limitations of yore and use mathematical expressions in a way that plain sense.

Re: Interview gone wrong

#167

Post by froh »

wouldn't it be lovely if someone, somehow pointed out that it should be

   if a == b == c != "-": return Winner
?

so three empty fields in a row don't "win" the game?

Re: Interview gone wrong

#168

Post by VoodooJuJu »

>Well done, Python… for finding yet another way to confuse us all.

Would have liked to see some humility from the author, especially since he's an interviewer, but instead he deflects the fault onto Python as being confusing, rather than attributing the fault to himself and his own lack of understanding.

Unfortunately, this kind of blame game is par for the course with enginerds. I say this all the time: engineers really should do a sales or customer service job before getting into engineering. This will help you build empathy, which will build your social skills and kindle some humility within you. These traits will give you an edge over other nerds and take you further in your career.

Re: Interview gone wrong

#169

Post by sgarland »

carlmr wrote: post #153
sgarland wrote: post #147

Earlier quoted context omitted.

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…

Fair point.

Re: Interview gone wrong

#170

Post by mlinhares »

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

That's why i put "style" in quotes, the interviewer didn't know about the feature but still decided it was "wrong" or "ugly" even though the code works.
Post reply on HN