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

51–60 of 209 posts

Re: Interview gone wrong

#51

Post by encomiast »

jbverschoor wrote: post #47
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?

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

Re: Interview gone wrong

#52

Post by cpfohl »

bowmessage wrote: post #48
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 '-'.

That’s… what the article says.

To be fair to parent I read the whole thing and also missed that.

Re: Interview gone wrong

#53

Post by nothrabannosir »

bowmessage wrote: post #48
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 '-'.

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…

Re: Interview gone wrong

#54

Post by necovek »

nerdponx wrote: post #40
necovek wrote: post #11

Earlier quoted context omitted.

I disagree: if you are demonstrating your mastery of a language (and with Python, these things are important: using appropriate syntax is the difference between dog slow code and fast code), you should use idiomatic patterns like the above. Another of Python features is a great REPL: when unsure or confused by an interviewer, I'd just fire python from shell and type in 'x' == 'x' == 'x' to confirm and demonstrate it…

In this case the candidate evidently didn't understand it either, but was repeating a pattern they had seen before, which IMO is a form of anti-mastery: don't do things that you don't understand, especially when you're supposed to be demonstrating your skill and understanding.

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, functools, external C libraries like pandas or numpy), I think I wouldn't be confused only because I am aware I don't know the details and have a quick way to prove it works.

Re: Interview gone wrong

#56

Post by Terr_ »

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

Re: Interview gone wrong

#57

Post by whatshisface »

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…

In defense of Python here, a==b==c -> (a ==_string b) ==_bool c is an extremely confusing way to write (predicate) nxor c. A principle here could be "operators that look the same shouldn't do different things when they're written close together."

Re: Interview gone wrong

#58

Post by andrewflnr »

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.

Yes, even the "unconcise" first draft of anyone who cares enough to be here on HN is much better than some of the code out there.

There's a basic level of concision you'll have by default if you actually understand the problem and the tools. You won't go away out of the way to complicate things. Maybe it's still a far cry from optimal, and definitely not code golf, but enough that I'd be worried if I saw even a first draft without it.

Re: Interview gone wrong

#59

Post by nerdponx »

necovek wrote: post #54
nerdponx wrote: post #40

Earlier quoted context omitted.

In this case the candidate evidently didn't understand it either, but was repeating a pattern they had seen before, which IMO is a form of anti-mastery: don't do things that you don't understand, especially when you're supposed to be demonstrating your skill and understanding.

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 that was: at some point, you do need to at least be able to reason about your own code.

In a more generous light, yes, I agree with everything you wrote. The precise details of comparison chaining are out of scope and I'm sure that most Python developers (myself included) don't know or remember them.

Re: Interview gone wrong

#60

Post by necovek »

mozman wrote: post #27
necovek wrote: post #11

Earlier quoted context omitted.

I disagree: if you are demonstrating your mastery of a language (and with Python, these things are important: using appropriate syntax is the difference between dog slow code and fast code), you should use idiomatic patterns like the above. Another of Python features is a great REPL: when unsure or confused by an interviewer, I'd just fire python from shell and type in 'x' == 'x' == 'x' to confirm and demonstrate it…

In the real world you iterate, profile, and optimize

I am definitely a subscriber to not doing premature optimization, but in Python, there is a huge difference between

  found = searched_key in list(large_dict)
vs

  found = searched_key in large_dict
But also compare:

  searched_key in large_dict.keys()  # O(1)
and

  searched_value in large_dict.values()  # O(n)
Post reply on HN