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

191–200 of 209 posts

Re: Interview gone wrong

#191

Post by nerdponx »

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…

Fun Python fact time!

`any` works on arbitrary iterables, so you can use a generator comprehension instead of a list comprehension:

  if any((a in ["-h", "--help"] for a in args)):
      display_help()
Which algorithmically is a wash, because the time you save not-materializing the list, you waste in the overhead of iterating through a generator (and it's all +/- nanoseconds in recent versions of Python anyway). However, Python has a special syntax that allows you to omit a layer of parentheses when a generator comprehension is the only argument to a function, leaving us with the very elegant (IMO) syntax:

  if any(a in ["-h", "--help"] for a in args):
      display_help()
This works for any(), all(), str.join(), and others. Yet another demonstration of why I think the iteration protocol is one of the best features in Python (and underappreciated as such).

Re: Interview gone wrong

#192

Post by nerdponx »

ckastner wrote: post #117
atoav wrote: post #105

Earlier quoted context omitted.

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

Being extremely pedantic, omitting the outer ()s is legal for a generator comprehension. That is, the following are equivalent:

  foo(x for x in xs)

  foo((x for x in xs))

  gen = (x for x in xs)
  foo(gen)
But these are not the same as:

  foo([x for x in xs]

  lst = [x for x in xs]
  foo(lst)
It doesn't matter in this tiny example, but the difference between generators and lists can be very very important when working on very large amounts of data (e.g. processing a big text corpus), or a potentially-infinite stream of data.

Re: Interview gone wrong

#193

Post by noncoml »

blitzar wrote: post #130
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.

Didn’t get you..

Re: Interview gone wrong

#194

Post by atoav »

nerdponx wrote: post #191
atoav wrote: post #105

Earlier quoted context omitted.

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…

Fun Python fact time! `any` works on arbitrary iterables, so you can use a generator comprehension instead of a list comprehension: if any((a in ["-h", "--help"] for a in args)): display_help() Which algorithmically is a wash, because the time you save not-materializing the list, you waste in the overhead of iterating through a generator (and it's all +/- nanoseconds in recent versions of Python anyway). However, Pyt…

ah cool, I didn't realize

Re: Interview gone wrong

#195

Post by recursive »

ball_of_lint wrote: post #76
recursive wrote: post #17

Earlier quoted context omitted.

If you're used to python, you wouldn't consider it to be a trick. If you're giving interviews, and evaluating code in a language you don't know, don't be so confident it's wrong. Ask the candidate how it works.

I've used python for ~2y now and I'd balk at and rewrite this statement, considering it unclear at best.

That's an entirely reasonable point of view.

The important part here is that there are a substantial fraction of python developers that don't share your sentiment.

Re: Interview gone wrong

#196

Post by int_19h »

throwaway313373 wrote: post #84
int_19h wrote: post #82

Earlier quoted context omitted.

That resolves the problem for other types, but you still have the case of (a == b == c) being parsed and evaluated as ((a == b) == c) if all three are booleans, which is still not an intuitive interpretation. I think the PL either has to ban such construct outright and require parentheses, or treat it as an n-ary operator like Python does (albeit perhaps with a few more constraints on what you can chain, for the sake…

I've just checked [0], Rust bans such construct for booleans as well. [0] https://play.rust-lang.org/?version=stable&mode=debug&editio...

Great error message, too.

Re: Interview gone wrong

#197

Post by int_19h »

flakes wrote: post #81
throwaway313373 wrote: post #35

Earlier quoted context omitted.

I think that the main issue here is not treating true/false as values but allowing them to be implicitly converted or compared to numbers with the assumption that true equals 1 and false equals 0. I think that Rust got this right. It doesn't allow you to add integer to boolean or multiply boolean by float etc, because it is unclear what does it even mean mathematically. Also, most languages implicitly assume that any…

A lot of languages have no boolean primitive to begin with. Often in older languages, the values for `true` and `false` are aliases for `0` and `1` respectively. Perl and earlier versions of C, Python, and JavaScript are notable. Perl is probably the most awkward due to context-sensitive casting. e.g. the string `"0"` in a boolean context evaluates as an integer, and the boolean interpretation for `0` is false.

JavaScript had Booleans as a primitive type as far back as I can remember. The problem, rather, is that it's altogether too eager to convert everything into everything else.

Re: Interview gone wrong

#198

Post by int_19h »

the5avage wrote: post #184
irishsultan wrote: post #174

Earlier quoted context omitted.

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.

"a == b" is the same as "not (a != b)" Maybe I'm simple minded though.

If you treat each "!" as a NOT, then (a != b != c) has two NOTs, but !(a == b == c) has a single one, so this is a bit like expecting that !(a && b) is the same as (!a && !b).

Re: Interview gone wrong

#199

Post by joveian »

alkonaut wrote: post #99
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.

What does A == B == C even mean? I mean I know what mathematically A=B=C means. That A, B and C are all equivalent. But then is the mathematical '=' really a binary operator that maps two numerical inputs to a boolean output? It feels then as an abuse of notation if (A=B)=C doesn't allow A=B to change type? Because I don't really have much use for a symbol that is some times doing a binary mapping from numbers to boo…

Maybe consider chained comparison operators early textual replacement along the lines of the C preprocessor, although the exact textual replacement would involve temporary variables to avoid multiple side effects and be more complicated than just "(a) == (b) and (b) == (c)". (a==b)==c does not expand, only the version without parentheses expands, so you can still do the boolean comparison if you want.

Re: Interview gone wrong

#200

Post by Izkata »

otherme123 wrote: post #165
vdvsvwvwvwvwv wrote: post #144

Earlier quoted context omitted.

It is merely syntatically confusing. Make == be ~~ or .fuzzyCompare() And === be == And you are fixed.

Paraphrasing: "Well done, Javascript… for finding yet another way to confuse us all." I don't know many programming languages, but of the few I know any of them has a === because == is so confusing that you don't know exactly if (or when) it would bite you. You can't attack any language for their comparison operators from the Javascript camp. It that blog post removed the sentence "And this is how it would definitely…

> cell[0][0] is "0", cell[1][1] is 0, cell[2][2] is true

If those values came from elements, the second and third examples aren't possible without having manually converted it beforehand. Input values are always strings, even a checkbox. That's where javascript's conversion rules and lax equality came from, an attempt to have sane defaults for simple uses: If a string is being compared to a number, the string is likely from an input and the number was typed into the code, so convert the string to a number before comparison.

Post reply on HN