Missing level of technical depth (Recursive to Iterative)

I recently have given a coding test in a reputable IT company. There were three coding questions.

They refused me by saying that


as we felt they didn't demonstrate the level of technical depth we're
seeking from candidates

Please help me understanding what type of the technical depth my solution is missing? Thanks

Question 2 : Missing level of technical depth (Flatten Tree)

Question 3 : Missing level of technical depth (Common Ancestor)

and this is the 1st question.

Question 1:


Reimplement this code so that its results will always be the same, but
that it does not cause a stack overflow on large inputs. Your
solution must still implement the Folder interface.

Answer 1:

package iteration;

import java.util.Queue;

public interface Folder
{
    U fold(U u, Queue list, Function2 function);
}

package iteration;

public interface Function2
{
  R apply(T t, U u);
}

package iteration;

import java.util.Iterator;
import java.util.LinkedList;
import java.util.Queue;

public class MyFolder implements Folder
{

     public U fold(U u, Queue ts, Function2 fun) {

        if(u == null || ts == null || fun == null)
            throw new IllegalArgumentException();

        if (ts.isEmpty()) {
            return u;
        }

      //get an iterator first instead of forEach loop, because poll() is modifying underlying collection/queue
        Iterator iter = ts.iterator(); 
        while (iter.hasNext()) { //loop over the items

            u = fun.apply( ts.poll() , u); 

        } 

        return u;
    } 

    public static void main(String[] args) {

        Folder folder = new MyFolder();

        Queue q = new LinkedList();

        for(int lop =0; lop () {
            public Integer apply(Integer val1, Integer val2) {
                return val1 + val2;
            }
        });

        System.out.println("Result: " + result);
    }
}

as we felt they didn't demonstrate the level of technical depth we're seeking from candidates

This is a stock response. The engineers who interviewed you probably said something like “nah, not good enough”, so someone in HR sent you their stock response. Don't worry about the exact words; it wasn't written about you.

Some problems they might have objected to:

• fold shouldn't throw an IllegalArgumentException when U is null; null is a reasonable input.

• It traverses the Queue with both Queue.poll (which removes the first element) and an iterator (which doesn't modify the queue). Pick one or the other. Doing both may not even have well-defined behavior — what happens to the iterator when you remove the current element?

• The initial isEmpty check is redundant. If the queue is empty, the iteration loop will do nothing.

• There are lots of blank lines that take space without contributing to readability. That you include them in such a small program suggests you're not used to large programs.

There are also some design flaws in the specification.

• Folder should not be an interface. It makes no sense to create an object in order to call its fold method; fold should simply be a static method.

• If the original version used Queue.poll instead of an iterator, then it destroys the contents of the queue. It's usually not a good idea to modify arguments unnecessarily, because it tends to create bugs.

• fold should probably accept any Iterable, not just a Queue.

If you didn't point out these problems, they might take that as a sign you wouldn't notice design flaws in real work either. Part of a programmer's job is noticing problems and (when feasible) fixing them!

StackExchange Code Review Q#51526, answer score: 7