Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why it’s hard for programmers to write a program to flatten a list?

shekhargulati.com

Post reply on HN
Print view View original

71–80 of 128 posts

Re: Why it’s hard for programmers to write a program to flatten a list?

#71

Post by Qcombinator »

ghshephard wrote: post #37

I think a lot of this is based on your experience with languages. If you have exposure to a list/iterator native language like python, you come up with solution in a few seconds, even if you aren't even remotely a programmer. Other languages might not lend themselves to so obvious a solution. The perl example cited here kind of blows my mind compare to the trivial python approach: def flatten(lst): rlst=[] for x in l…

>The perl example cited here kind of blows my mind compare to the trivial python approach

That's because the Perl version is a two-for-one deal: just for fun, Cestith threw in a non-recursive version too. The 'trivial' recursive approach is more or less equivalent to the Python:

  sub flatten { map ref($_)? flatten(@$_) : $_, @_ }

Re: Why it’s hard for programmers to write a program to flatten a list?

#72

Post by mannykannot »

collyw wrote: post #34
cableshaft wrote: post #6

Earlier quoted context omitted.

Doesn't stop people from asking these questions of people at all levels. I still get asked these coding questions pretty much every interview I have had, and I have almost a decade of programming experience, and have even been lead programmer on some projects (without the title). I've been asked a barrage of these questions for senior positions, even. Especially sucks because I don't usually program terribly fast or…

Have you ever needed to flatten a list in your career outside exams and interviews?

I am not an enthusiast of this approach to recruiting, but to be fair, the purpose of the question is not to find someone to flatten lists.

It is reasonable to ask, if a programmer cannot flatten a list, in what sense is that person a programmer? Putting aside the question of whether this is a good approach to recruiting, if this question is being failed with any regularity, it raises some interesting and important questions about the innate difficulty of programming and/or the methods by which it is taught.

Re: Why it’s hard for programmers to write a program to flatten a list?

#73

Post by alkonaut »

dragonwriter wrote: post #57
alkonaut wrote: post #50

The fact that "int or list of int" isn't sanely representable in any concise way in the mainstream OO languages is a sign that perhaps this isn't a great example problem for a Java interview. Obviously you can do this with brute forcing the sum type with some class hierarchy (ugh) or make the algorithm accept some List or Java "List" interface. Both of those options are pretty terrible. I think the intents of the que…

> The fact that "int or list of int" isn't sanely representable in any concise way in the mainstream OO languages is a sign that perhaps this isn't a great example problem for a Java interview. OTOH, if you are going to be using Java dealing with real world problems, many of which have aspects that are not neatly representable in Java's type system, some test of how you deal with the mismatch of that type system with…

Yes obviously Java is going to be the tool at hand, but to keep focus on the good aspects of this exercise (naming, testing, etc) perhaps it would be best to have a problem that has a good solution in Java.

If the subject does this property with generics that simple sum type alone requires writing several classes just to represent the sum type.

It's not clear from the article what the input is. What signature I can use depends on what the input data is. Is it a string rep of the nested list? Can I assume it's any type I want such as my own NestedList?

Re: Why it’s hard for programmers to write a program to flatten a list?

#74

Post by dragonwriter »

dllthomas wrote: post #70
dragonwriter wrote: post #28

Earlier quoted context omitted.

> One of the problems is that for Java the task is underspecified: Flatten a list of what? Sure this one is integers, is that always the case or should the list take ? Well, I don't Java much, but I think that even if the result List is just integers, the source list has to be (invalid syntax) List >, which is somewhat problematic to type as anything but List given Java's lack of sum types.

Interfaces are (open) sum types. Or close enough for government work.

Yes, but Java (unless I missed a recent change) doesn't let you assign new interfaces to existing types, so short of either wrapping Lists and Ints in containers implementing a common interface and demanding that the input be in the wrapped form, that doesn't actually help.

Re: Why it’s hard for programmers to write a program to flatten a list?

#78

Post by throwaway729 »

alkonaut wrote: post #69

> No one thinks about generic program so that solution will work across all types. Is this even possible to do generically in Java or C#? You can do it for objects so that it works for ALL types (i.e "object"), but you can't make it work generically for a type T for any T. That's why this is such an excellent example of why sum types really are useful. Writing the flatten interface without generics (Java List or c# I…

Yes you can code up sum types in the object system of Java or C#.

But are you allowed to do that? The problem write-up makes it sound like you're supposed to be ingesting the interviewer's input. So, how did the interviewer code up sum types? With tons of nasty casting out of List, or with a slightly less terrible object hierarchy mimicking sum types?

That's what makes the question terrible. It implies you're supposed to be coding against an interface, but in the allowed language (Java) it's totally non-obvious what the interface is.

I'll submit this criteria for coding question: if a big chunk of your candidates can't write down the friggen type of the program you want them to implement -- and if two reasonable people could write down extremely different types for the same question -- then your question is bad and you should throw it out.

Re: Why it’s hard for programmers to write a program to flatten a list?

#79

Post by whorleater »

hibikir wrote: post #56

The first problem I see is that your rubric is a complete shibboleth: The candidate has to guess what you are evaluating. In some interviews, all they want is working code. Others want performance. Others care about testing: Based on the question, I'd not be sure of what you want. There's places where writing the test first will, if anything, be detrimental. Others will love it. You have to be clear on expectations.…

> The second issue is that a question like that is not even remotely fair across programming languages. What about types?

I wonder if part of this test is to see if a programmer will choose a language that's appropriate for it. Picking the right tool for the job and whatnot.

Post reply on HN