News for hackers. Stuff that matters.
Re:Why it’s hard for programmers to write a program to flatt... by franciscop on Friday February 24, 2017 @02:24PM (#13726795)
I fail to see how some people see this as a contrieved test. It's an issue many programmers have probably found at some point as opposed to fizzbuzz or other artificial tests. Probably other questions related to your business would also be good, but using this as a first and quick filter sounds about right IMO.

In Javascript, depending on your context, it could be as easy as:

     // Only if we're using numbers or other variables without commas on them
     // divide them, remove empty things and make them numbers again
     const flatten = arr => arr.toString().split(/[\s,]+/).filter(e => e).map(n => 0+n);
Or a slightly more complex and "proper" one as:

    // Recursively flatten an array
    const flatten = arr => arr.reduce((all, one) => all.concat(one instanceof Array ? flatten(one) : one), []);
Re:Why it’s hard for programmers to write a program to flatt... by throwaway729 on Friday February 24, 2017 @02:54PM (#13727165)
The complaint isn't that it's contrived in general. The complaint is that it's a bad question if you're interviewing Java developers (because Java's type system is impoverished, but that's really beside the point).

If you're going to ask this question of a Java developer, you should carefully indicate what form the input takes. Heterogeneous collections are canonical in dynamically typed languages, and also in reasonable typed languages as recursive sum types. But in Java you're stuck between awkward subtyping / dynamic casting, or coding up your own definition of a heterogeneous collections. And in particular, the wording of the question suggests List<Object>, which is terrible style in Java land.

The real take-away is that Java's type system stinks for this sort of thing, and the standard libraries don't offer much help. But if you're interviewing Java developers, you shouldn't start off by asking them to writing terribly non-idiomatic Java code.