Skip to main content
Code Review

Return to Answer

added 267 characters in body
Source Link
Anonymous
  • 2.2k
  • 10
  • 14

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 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, which is. It's usually not a good idea to modify arguments unnecessarily, because it tends to create bugs.
  • fold should probably operate onaccept any CollectionIterable, 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!

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 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.
  • 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 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, which is usually not a good idea.
  • fold should probably operate on any Collection, 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!

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!

Source Link
Anonymous
  • 2.2k
  • 10
  • 14

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 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.
  • 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 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, which is usually not a good idea.
  • fold should probably operate on any Collection, 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!

lang-java

AltStyle によって変換されたページ (->オリジナル) /