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

111–120 of 209 posts

Re: Interview gone wrong

#111

Post by shkkmo »

the5avage wrote: post #108
ball_of_lint wrote: post #75

Earlier quoted context omitted.

Most programming languages ought not to be optimized for a non-programmer to read, but rather for someone who writes code to read. There's a lot of options for a language to deal with a statement like this. It could be a syntax error, a compile or lint warning, it could work by doing order of operations and comparing the boolean from one compare with the third element, or it could work in the way you described. I'd p…

> I really don't want to have to pull out an operator precedence chart in order to read your code Hard disagree here. I write code for people who can read the language. This includes operator precedence.

The more complex an expression grows, the less well it works to rely on operator precedence to indicate structure to the reader.

Additionally, I think assuming the reader is aware of every. nuance of the language is an extremely bad idea unless you are and will always be the only developer. If you are doing anything weird or tricky or rare, I'd highly recommend linking the documentation or providing an explanation.

Re: Interview gone wrong

#112

Post by grujicd »

cplat wrote: post #24

If your knowledge of Python comes from JavaScript, I would not blame Python for it. It's the failure of the person to not "read the instructions" and assume instead. Maybe conduct interviews in languages that you're familiar with?

If you were programming long enough, you easily had contact with dozens of languages. How do you pick up a new language? You can't really treat it as your first one. Especially if you need it "for yesterday". You won't read about "if" or "for". No, you scan for what's different from what you already know. If you're lucky you'll find "python for javascript programmers", but that probably won't go into non-core details like this. In practice, you learn basics first and start coding. Then you find a piece of code somewhere that you don't understand. That's a learning opportunity! However, it's easy if it's a function since it's easily googlable. Operators are harder to search for, for instance in new versions of C# you have operators like "?." (just an example). Since googling is hard you go to some "operators documentation" and try to find it there. And hope that it covers the new version. For cases like this story it's even harder because it describes a concept (chaining) and you maybe don't even know which name is used for that.

At least ChatGPT recognized and explained it correctly, so it makes picking up new features easier than it used to be. I'm making a mental note to ask LLMs whenever I encounter unknown constructs.

Re: Interview gone wrong

#113

Post by jyounker »

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.

As someone who trained in mathematics, I would 100% say that mathematicians would evaluate it as true. It's not the cleanest way to write it, but intent is clear.

Re: Interview gone wrong

#114

Post by kdhusakdjhsadkj »

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?

[dead]

Re: Interview gone wrong

#116

Post by jyounker »

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.

It's not a trick though. It's normal Python code. It's so common that you don't even think about it. It's just how equality comparisons work in the language.

Re: Interview gone wrong

#117

Post by ckastner »

atoav wrote: post #105
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 problems I have encountered a billion times and of course I have an elegant concise solution for it, if I am an experienced programmer. if any([a in ["-h", "--help"] for a in args]): display_help() Would be one of those. Generally I learned that it can be beneficial to treat things as lists early on, e.g. if you have a program that takes one input file it costs you next to nothing to allow the input to be m…

That still looks like something that a novice might trip over when reading this. Just describing what it does is already a bit convoluted: it tests whether any value of a list of booleans, produced by a generator expression by testing membership of a value in some other list, is True.

I would have gone with the following, as it requires less mental unpacking:

  if set(args) & set(["-h", "--help"]):
      display_help()
Also, note that any() works with any iterable, the outer brackets are not needed given the list expression.

  if any(a in ["-h", "--help"] for a in args):
      display_help()

Re: Interview gone wrong

#118

Post by TrainedMonkey »

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 overloaded with binary comparison operator, so the people will be confused.

This actually gets weirder - in python you can make an arbitrary long comparison operator - it's called comparison chaining - https://www.programiz.com/online-compiler/6uyqb52IVH8if . It works with a lot of operators - https://www.geeksforgeeks.org/chaining-comparison-operators-...

Once you know how it works and are used to it, I think it makes the code easier to parse... but there are heavy downsides. For example, it's not clear how short circuiting works. I've used python a bunch and logically I expect ```side_effect3()``` to not be evaluated if results of 1 and 2 are not equal: ```side_effect1() == side_effect2() == side_effect3()```. However, I do not know that for sure, while in other languages I would be able to reason about this from basic principles.

Re: Interview gone wrong

#119

Post by otherme123 »

pzo wrote: post #115

Worth to keep in mind that python first appeared in 1991 and predates even Java, JavaScript, PHP, Ruby

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 confusing comparison operators is JS.

Re: Interview gone wrong

#120

Post by blitzar »

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?

if you know the domain for the task at hand (+a few very basic soft skills) you can learn a lot from watching and discussing with a candidate while they are doing the task.

In reality - tasks like these are garbage leet-code samples; candidated who have been grinding examples rapidly regurgitate the best solution from the forums and impress the interviewer, but would fail if asked a basic question on what they produced. Those that solve it reasonably from first principles fail the task.

Post reply on HN