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

171–180 of 209 posts

Re: Interview gone wrong

#171

Post by acdha »

_w1tm wrote: post #151
sampo wrote: post #129

Earlier quoted context omitted.

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

Is “let me check the docs” an appropriate thing to say in an interview setting?

It’s what you’d do on the job, right? A place which dings you for checking your work is broken.

I’d expect a raised eyebrow if it was some very basic question about something you’ve claimed to be an expert in but given how many, many bugs over the years stem back to confusion about order of evaluation I would consider it a minor plus if someone said “I think I know but I want be certain”, and a major one if they paired that with mention of defensive coding practices like adding tests covering cases where it’d matter and structuring the code so there are no side effects hidden in the test (e.g. the code as written is fine but if it was f1() == f2() == f3() I’d probably write it as a clearer multi-line if block when there are side effects to those calls to make obvious when I’m intentionally not doing them in every case).

Re: Interview gone wrong

#172

Post by Izkata »

dijksterhuis wrote: post #141
ckastner wrote: post #117

Earlier quoted context omitted.

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,…

on my phone and a bit discombobulated today, so we’ll see how i go with this > That still looks like something that a novice might trip over when reading this. my experience with “juniors” who start with python is that they think in lists and dictionaries. they don’t think in terms of set theory. that’s just the way python is taught. i would definitely set interview questions where a “decent” solution involves using…

".intersection()" takes any iterable, it can be:

    if set(args).intersection(["-h", "--help"]):
Also python has had a special syntax for sets since 2.7 (I think), though I haven't seen it used very often:

    if {"-h", "--help"}.intersection(args):

Re: Interview gone wrong

#173

Post by bityard »

_w1tm wrote: post #151
sampo wrote: post #129

Earlier quoted context omitted.

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

Is “let me check the docs” an appropriate thing to say in an interview setting?

It absolutely is.

Re: Interview gone wrong

#174

Post by irishsultan »

the5avage wrote: post #104
int_19h wrote: 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

I don't see how you could interpret "a != b != c" as equivalent to "not (a == b == c)" in the first place. In the first expression a doesn't equal b and b doesn't equal c (no restriction on a and c). In the second expression you could have a == b, but b != c (and vice versa), clearly that's not equivalent to the first expression.

Re: Interview gone wrong

#175

Post by renegade-otter »

sampo wrote: post #129
TrainedMonkey wrote: post #118

Earlier quoted context omitted.

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

It's a completely useless question - it's language trivia. It's like asking "what happens if you do X in database Y version Z and up". Who cares? It's something you figure out when you get there. There are tons of examples of something like this where it's language-dependent, so don't even bother memorizing this stuff.

I once passed an interview where it was all just Spring documentation questions. I had never built a Spring app in my life, I just "read the docs" five times.

Re: Interview gone wrong

#176

Post by ninetyninenine »

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.

The problem isn’t meaning or intent its inconsistency of operator behavior.

1 + 1 + 1 has different operator behavior then 1 == 1 == 1. The operations here are not consistent and it’s not clear what happens if I overload the operators.

On the surface level python looks more beautiful. But mathematically speaking python is actually more ugly and more inconsistent with weird rules to make things look a certain way.

Re: Interview gone wrong

#177

Post by ljm »

_w1tm wrote: post #151
sampo wrote: post #129

Earlier quoted context omitted.

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

Is “let me check the docs” an appropriate thing to say in an interview setting?

I'd prefer a candidate to check the docs or look something up if they were unsure, because that would also provide useful information to me as an interviewer.

Although I'd also want that benefit of the doubt for myself. I'm quite familiar with how Ruby handles collections, for example, but if I tried to use `slices.Collect` in Go the same way as `Enumerable#collect` in Ruby I'd end up stuck and would need clarification.

Re: Interview gone wrong

#178

Post by Izkata »

jeroenhd wrote: post #166
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 x z). Banning these chained comparison operators is not necessarily a bad idea as comparison operators can eas…

If you write the bounds check in the same order it's really not that bad: (0 <= n && n < something.length)

Re: Interview gone wrong

#180

Post by Izkata »

otherme123 wrote: post #119
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 co…

The basic rule is "if there's a number on either side, convert the other side to a number before doing the comparison". I think false == '0' is the only one that fails that test, unless you think of false as a special case of 0 which makes false == 'false' the one that fails with that rule.
Post reply on HN