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

121–130 of 209 posts

Re: Interview gone wrong

#121

Post by James_K »

atoav wrote: post #101
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'd argue that many programming languages are not optimized for "people who read code" but they are optimized for programs who read code (compilers, interpreters) and programmers can stockholm-syndrome themselves into believing that it is targeted at them.

Code optimised for an interpreter is often also optimised for the programmer, whose primary job is interpreting code. What makes natural language intuitive is that it doesn't have to be precise. You can assume language does what it is intended to do. A programmer, by contrast, must know exactly what the program does. You cannot assume it does what you want it to do because the computer doesn't know what you want it to do. A language cannot be made less precise by the addition of new rules; it is only made more complicated as there is more to remember. In this example, the person writing the ternary expression had to learn that it exists. If it didn't exist, there would have been less learning to do. Perl is the limit of this process – a language with many rules to appear natural and human-like that it's almost impossible to actually read.

Each rule of a language is a cognitive burden. It can only justify itself if the thing it replaces is a greater burden.

Re: Interview gone wrong

#122

Post by tmtvl »

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.

Yet another way in which Lisp is vastly superior to any and all blub languages:

  (= 2
     (+ 1 1)
     (sqrt 4))
  ; => t

  ( t

Re: Interview gone wrong

#123

Post by eterevsky »

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?

I also judge code quality at the interviews that I perform. I just give the candidates time to improve their code after they come up with something working.

Re: Interview gone wrong

#124

Post by blitzar »

necovek wrote: post #21
Buttons840 wrote: post #13

Why did the author consider this an "interview gone wrong"? What was "wrong" about?

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

If the interviewer is a good interviewer - they inadvertently gave the candidate an oportunity to demonstrate a range of skills.

An outstanding candidate when questioned would mention that in most languages this evalates to that, but in python it evaluates to this, and offer an alternate method chaining and's on the spot in response to the confustion.

If they are a bad interviewer - they would allow their ego to derail the interview.

Re: Interview gone wrong

#125

Post by Ukv »

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…

> the symbol it is using is overloaded with binary comparison operator, so the people will be confused

I think most people would expect expressions like `5 < x < 10` to work as they do in math, without necessarily thinking about it in terms of being an overloaded binary operator. The result in other languages that `5 < 12 < 10` = `true < 10` = `true` is more surprising, just that we've (perhaps by being bitten by it early on) gotten used to it.

Re: Interview gone wrong

#126

Post by ball_of_lint »

throwaway313373 wrote: post #92
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…

"someone who writes code" is very vague. For someone who writes code primarily in Python this behavior is less surprising than the rest that you described.

Intentionally so.

I've worked primarily in Python for the last two years and I'd still have to look at a reference to be certain of what exactly this code does. And would probably rewrite it to the expanded, parenthesized form unless the company linter insisted.

Re: Interview gone wrong

#127

Post by _niki_s_ »

WalterBright wrote: post #70

D solved the problem with what happens with (a == b == c) in an unusual way. It gives an error message. Both the C way and the Python way are considered wrong. You're going to have to add ( ) to clarify.

you can't just add () to clarify, you have to duplicate `b` too and that is not good transformation if `b` is function call

Re: Interview gone wrong

#128

Post by nmeofthestate »

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.

>I write code for people who can read the language

Programming languages often have syntax that's acknowledged as a source of confusion and bugs and better avoided. The line is not hard and fast, but I write C++ and there's "C++", and then there's "the C++ subset that you should use" (I probably couldn't write C++ code without tools slapping me for using the wrong parts). Operator precedence is debatable but our tools force the use of parentheses to disambiguate.

Re: Interview gone wrong

#129

Post by sampo »

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…

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

Re: Interview gone wrong

#130

Post by blitzar »

noncoml wrote: post #38

I am idiot but I would, and have in the past, have wasted the whole interview time argue in that I am right and he is wrong. Yes, John, some switches do start sending the packet before finish receiving it. It’s called cut-though switching. Hope you googled it. And yes it was worth losing the job offer over it.

John says you were wrong then and you are still wrong now. When talking about the problem domain John also mentions some switches do start sending the packet before finish receiving, it's called cut-though switching.
Post reply on HN