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

Or maybe they want a candidate who asks: what are the functional and non-functional requirements for this task?

If the interviewee guesses whether or not security, speed, memory use, portability, maintainability or anything else are important, maybe they will do the same in production code.

Type-safe, bonus unit test.

   import org.junit.Test;
   
   import java.util.ArrayList;
   import java.util.Arrays;
   import java.util.List;
   import java.util.stream.Collectors;
   import java.util.stream.Stream;
   
   import static junit.framework.TestCase.assertEquals;
   
   public class FlattenList {
   
       @Test
       public void test() {
           // [1, [2, 3], [4, [5, 6]], [7, [8, [9, 10]]]]
           final FlattenableList list = new FlattenableList();
           list.add(new SingleFlattenable(1));
   
           list.add(new ListOfSingles(Arrays.asList(2, 3)));
   
           list.add(new Flattenable(){{
               add(new SingleFlattenable(4));
               add(new ListOfSingles(Arrays.asList(5, 6)));
           }});
   
           list.add(new Flattenable(){{
               add(new SingleFlattenable(7));
               add(new Flattenable(){{
                   add(new SingleFlattenable(8));
                   add(new ListOfSingles(Arrays.asList(9, 10)));
               }});
           }});
   
           assertEquals(Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10), list.flatten());
       }
   
       public static class FlattenableList {
   
           final List> list = new ArrayList();
   
           void add(final Flattenable item) {
               list.add(item);
           }
   
           List flatten() {
               return list.stream().flatMap(Flattenable::flatten).collect(Collectors.toList());
           }
   
       }
   
       private static class Flattenable {
   
           final List> contents = new ArrayList();
   
           Stream flatten() {
               return contents.stream().flatMap(Flattenable::flatten);
           }
   
           void add(final Flattenable content) {
               contents.add(content);
           }
   
       }
   
       private static class ListOfSingles extends Flattenable {
   
           final List list;
   
           ListOfSingles(final List list) {
               this.list = list;
           }
   
           @Override
           Stream flatten() {
               return list.stream();
           }
   
       }
   
       private static class SingleFlattenable extends Flattenable {
   
           final T item;
   
           SingleFlattenable(final T item) {
               this.item = item;
           }
   
           @Override
           Stream flatten() {
               return Stream.of(item);
           }
   
       }
   
   }

Oh, I'm not imagining you making an attack on Perl. It happens commonly enough, though. I was commenting that your property had a lot of punctuation and bemoaned that Perl with the same amount often gets criticized for that very thing. Meanwhile many of the same people are fine with Python's invisible punctuation, Lisp's parentheses, or Haskell's syntax which likewise includes a lot of punctuation.

I also was pointing out that Haskell has Tree shipping with it, and Perl's CPAN, which is usually a stellar place to look, has what appear to be some false starts. I'd sort of expect one of the many List:: modules like List::Utils, List::MoreUtils, etc. to have the functionality, but as far as I saw when looking, no. It's easy enough to do in the base language, though. I assumed Haskell from your language and the syntax of your notation.

Your Bash and sed solution appears simple on the surface, but it is using a trick of the data format and bringing together two languages. It's even using a syntax that will confuse some people on first look in that you're putting square brackets within square brackets starting with the right bracket then the left. Many people are going to look at that and at first think it's two empty character classes then do a double take. It's clever, but any simplicity in it is rather baked into some, let's say interesting assumptions. I like it as a snarky response to the problem, but it's not something I'd hire a programmer for proposing as a serious solution.

Flattening a list of lists is a problem that occurs quite frequently in functional programming.

OTOH, in functional programming languages and frameworks, there is no need to actually write a method that does that since it is usually a library function call.