Hacker News Reader

Comment by _huayra_ | Hacker News Reader

Is there a language where you get everything? (i.e. there's nothing you don't get)

Based on the people who have amount of "C++ experts" I've interviewed over the years who don't know much about template metaprogramming or weird rules about initialization and class layout, yet have shipped meaningful code while avoiding most of the weird parts of the language.

Even languages like Python can get weird, such as default arg initialization:

  def add_item_to_list(item, list_to_add=[]):
    list_to_add.append(item)
    return item

  a = add_item_to_list(1)
  a.append(3)
  b = add_item_to_list(2)

What do `a` and `b` print?

This is my go-to Python 1st-round question, and many prolific Python coders don't get through this.

From what little I've learned of Haskell so far, it seems like one can eschew the weird PL-heavy parts of the language and just be productive (with the tradeoffs the language contains, e.g. GC).

View on HN

You ask this in interviews...? What makes this a good 1st round question in your mind? What is there to learn about the candidate?

It seems to me that it's one of those things you've either encountered (and go "well, that's weird") or... haven't encountered (and go "well, that's weird" upon having it explained). Have pop quizzes about the sharp edges of various languages proved useful as a filtering mechanism?

As someone who deals in low-level code and has been at several different companies... Absolutely. This stuff can be the difference between a good product and 'leaks customer secrets at runtime'. It is irresponsible to program in a language and ship code when you do not understand.

It is scary that software engineers want to be considered professionals, and yet don't want to be held responsible for understanding the tools they use.

Would you trust a bridge designer who didn't really understand the intricacies of concrete? Not me, no thank you.

The responsible thing to do is to have a robust code review culture and cover your code with enough tests that boneheaded mistakes in this vein have a very low chance of making it into production. There is no amount of experience that can prevent boneheaded mistakes. If your users' privacy depends on your programmers understanding all the footguns and weird little corner cases in the tools they use, and on implementing that understanding perfectly whenever they write code, you already don't deserve said users' trust.

Is it fair to expect a candidate claiming fluency in language X to back that claim up? Sure. But I don't think the general thrust of your comment is very productive.

I think it'll depend on the role.

If you're coming into a role saying "I'm very familiar with Python" and you don't know one of the most famous 'gotchas', that says something.

If you're coming into a role and saying "Hey, I'm not so familiar with Python but I have experience in other languages and I'd love to learn it as part of this role" I think that question is not appropriate.

Even still.. Seems a bit... arbitrary?

It's pretty easy to just never bump into certain corners of languages -- even if you use said language extensively. I've used Python for, like, 8(ish) years professionally. I maintain a few moderately popular open source libraries. I honestly don't recall exactly what happens when you do the `list_to_add=[]` thing, because these days I pretty much never pass in a list with the purpose of having it be mutated by something else. I know is that I did try it once, a long time ago, and that it does something unexpected. But I couldn't tell ya more than that just by looking at in.

Color me dismayed to discover that I'm actually a hack fraud.

> But I couldn't tell ya more than that just by looking at in. > > Color me dismayed to discover that I'm actually a hack fraud.

What I said elsewhere still stands. Yes... this kind of thing is the difference between 'works well' and 'exposes private user data to other users'. I'm glad you don't use such constructs, but realistically, given python's closure rules and when data with interior mutability are captured, this situation arises more than just in this particular situation. And like I said... it can easily lead to exposing private information to other users.

The question is appropriate because it allows for further elaboration, even if a candidate isn't familiar with the call by assignment semantics of Python. It enables for a follow up discussion about differences between calls by value, calls by references, immutability and so on.

Sure... junior engineers don't need to know everything. But if someone is putting themselves out there, by offering professional services for example, then yes they ought to know this sort of thing.

> What is there to learn about the candidate?

it would be extremely hard for a Python developer not to encounter this core property of the language (call by assignment), unless the candidate has just graduated from a random 1-month bootcamp, which may be the purpose of discovering of with the first-round question.

Do you mean ``` def add_item_to_list(item, list_to_add=[]): list_to_add.append(item) return list_to_add

  a = add_item_to_list(1)
  a.append(3)
  b = add_item_to_list(2)

```

oh lol yes you're right. I meant to return the list.

I should not try to HN comment while running out the door to catch my bus...

> a.append(3)

Trick question it's a type error?

Reply on news.ycombinator.com