Live data from Hacker News

Interview gone wrong

ashu1461.com

101–110 of 209 posts

Re: Interview gone wrong

#101

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.

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.

Re: Interview gone wrong

#102

>> I have a very basic question which I usually ask in a interview which is to implement a tic tac toe game. I like this because the logic is straightforward and it helps to judge things like code quality / speed / conciseness etc. "I like this because the logic is straightforward and it helps to judge things like code quality / speed / conciseness etc." No, it doesn't. Everyone who comes up with their own pet way of…

How did you get "unshakable belief" from that paragraph?

Interviewing is inherently messy, imprecise and unscientific. The process involves a lot of guesswork and feeling, rather than accurate measurements of any kind. It creates a fictional work environment that is often stressful for candidates, so any signal you may get out if it is also inaccurate.

It's natural for interviewers to have a preference for certain questions, topics or ways of conducting an interview. You're free to disagree, of course, but claiming that your way is superior is silly.

Re: Interview gone wrong

#103

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.

Rust also gives a custom error message [0] that explicitly explains that "comparison operators cannot be chained" and shows you how to rewrite the expression using `&&`. Which makes me wonder whether they came up with this idea themselves or if they borrowed it from D. In any case, I think that this is the only reasonable solution for new languages. Because if you go with C way it will be surprising for people who ex…

I gave several presentations that included this back in the 2010-2012 timeframe, and it had already been in the language for maybe a decade.

When I implemented it, I had seen many knock-down drag-out debates about which was the best way to deal with it, and none of them mentioned simply making it illegal.

It was another one of those features that were based on my experience designing aircraft systems.

Another one adopted by pretty much all languages since D is the _ in numeric literals (although C++ used a backtick). It was just something that was obviously right once you saw it. But I didn't originate it, I cribbed it from Ada. I've always had a soft spot for Ada.

Re: Interview gone wrong

#104
post #15

In this respect, Python makes a lot more sense since that is how you'd normally write such an equality in math, and generally how people chain them: A=B=C means A=B and B=C. Part of the problem here is that we treat true/false as "just another value" in programming, and thus the usual operators are used to compare them. In math notation, if you wanted to compare the result of comparison A=B to a Boolean value C, you'…

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

Re: Interview gone wrong

#105

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 mutiple files as well.

Re: Interview gone wrong

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

I would say if you know you have to later work with the guy and he will be higher up than you this is actually smart.

Re: Interview gone wrong

#108

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.

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.

Re: Interview gone wrong

#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, but I've found it's rarely useful and can easily be avoided.

Re: Interview gone wrong

#110
post #95

I'd be more confused about the curly brackets, I only know python and have never seen them used like that? My brain goes like: Here comes a set or dict. Also, why not do `all(cell[0][0],cell[1][1]),cell[2][2])` if you want to have True when all 3 are True? Perhaps I'm missing something, I don't exactly consider myself a 1337 coder.

> I'd be more confused about the curly brackets, I only know python and have never seen them used like that?

Yeah, that’s C/C++/JavaScript/… syntax, it’s not valid Python.

> why not do `all(cell[0][0],cell[1][1]),cell[2][2])` if you want to have True when all 3 are True?

We want to test whether all three are the same, not whether they’re all True.

Post reply on HN