Experience Test Results

It's @Veradux speaking. Thank you for taking part in the experience test. The results are in, and Charlie has ran out of tears to cry! (that means good job to you) Congratulations to everyone who received a more significant role. It is time to end this stage of recruitment.

A surprisingly good percent of people had very solid answers. Out of 36 total participants, at least 10 people were given the opportunity to be a bigger part of the project. A lot of you pointed out many great flaws in the code, and went very in depth. It will be hard to mention all, so here's the long awaited answers we were looking for, for each question.

1. More than half of you absolutely nailed this one. But don't get too excited, the first question's goal was to just get you warmed up to the interviewing. ;) That's why I'll be quick with this one. The first code had:
   • Inconsistent formatting, no sign of sticking to a convention whatsoever
   • Awful spacing and readability
   • Unnecessary nesting with the if else's
   • Non-descriptive names
   • Spelling mistakes

2. The second question mainly tested your knowledge on exceptions! Quite the jump, but it's a fundamental part of Java. The code had plenty of struggles again, like:
   • A pointless try catch, because in this case, if there are dangers of out of bounds exceptions, then it has been written wrong
   • And if it wasn't pointless, it catches all exceptions, instead of specific ones
   • And even if it catches a specific one, it doesn't handle it in any way at all, it just prints something. The method will still return a half-completed result.
   • The start variable is never taken into account. The method always starts the counting from 0.
   • Unnecessary repeating of iterator++;, that can just be done once outside the conditions.
   • Misleading use of a while loop. I didn't personally consider this that big of a deal, but more people pointed it out than I expected. For loops are better suited when you know the number of iterations, while loops when you don't. Which is fair, I'll allow it.

3. This code mainly had a big, fat duplication. Still though, somehow everyone gave different answers and approaches! It was very interesting to see how you would all do it. Initially this was made to check your familiarity with methods. The idea was that this can be done by calling one method twice. Most other approaches to remove the duplication were valid as well.

4. This is where the difficulty makes another jump, with a question for the people who have had a bit of experience.
   • No use for the wrapper classes. You will most commonly see these used for generics, since you can't put a primitive in a generic. And we aren't doing any of that here. It causes unnecessary autoboxing and unboxing.
   • The constant concatenations to the result string are all going into the string pool that exists in Java. That means we're taking up unnecessary memory. A solution for that is the StringBuilder class.
   • The two comments do not add any meaning to the code. This was, interestingly enough, very controversial. I think only 3-4 people pointed them out as pointless. Many others even liked the comments, and wanted more of them! Comments should be used to describe WHY the code works the way that it does, more often than HOW it does it. The reason why the HOW comments should be avoided, is because the code should say that on its own. There shouldn't be a need for them, if possible. Which is the case in the example.