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 thingsproblems they might have objected to:
fold
shouldn't throw anIllegalArgumentException
whenU
isnull
;null
is a reasonable input.- It traverses the
Queue
with bothQueue.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 itsfold
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, which is. It's usually not a good idea to modify arguments unnecessarily, because it tends to create bugs. fold
should probably operate onaccept anyCollectionIterable
, not just aQueue
.
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!
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 things they might have objected to:
fold
shouldn't throw anIllegalArgumentException
whenU
isnull
;null
is a reasonable input.- It traverses the
Queue
with bothQueue.poll
(which removes the first element) and an iterator (which doesn't modify the queue). Pick one or the other. - 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.
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 itsfold
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, which is usually not a good idea. fold
should probably operate on anyCollection
, not just aQueue
.
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!
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 anIllegalArgumentException
whenU
isnull
;null
is a reasonable input.- It traverses the
Queue
with bothQueue.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 itsfold
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 anyIterable
, not just aQueue
.
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!
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 things they might have objected to:
fold
shouldn't throw anIllegalArgumentException
whenU
isnull
;null
is a reasonable input.- It traverses the
Queue
with bothQueue.poll
(which removes the first element) and an iterator (which doesn't modify the queue). Pick one or the other. - 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.
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 itsfold
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, which is usually not a good idea. fold
should probably operate on anyCollection
, not just aQueue
.
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!