We typically don't look too deeply into the overall design on a candidate's code. Most coding tasks just aren't big enough to warrant it.
When we do, it is typically because the candidate has done something… peculiar. For example, we have had a candidate that send a submission with no less than 17 classes to manager reading a CSV file and populating a dictionary. At some point we knew that this candidate wasn't going to move forward, but it became a challenge, to try to outline how the data actually traveled through that particular maze. But as much as we love Mr. Goldberg, I'm afraid that dear Rubbie isn't going to be remembered for much longer.
Here is how this candidate code started:
static void Main(string[] args) { //Call for parsing method HelperClass cr = new HelperClass(); cr.CsvParser(); cr.ToArray(); cr.Sort(); cr.UnifyIdLists(); //ask the user to enter input string input = cr.InputReader();
I actually started explaining the issues in this code, but I run out of… pretty much everything.
I have a challenge for you, can you think of a single OOP principle that isn't being broken here?
For… fun, I guess, you can also look at the following code, which come just after the one above:
Start: //check input type switch (cr.InputTester(input)) { case 0: //valid email structure, but the input is not found in the file List<int> emails = new List<int>(); emails = cr.EmailSearcher(input); if (emails.Count == 0) { Console.WriteLine("The input you have entered has not been found in the file. \nPlease try again."); input = cr.InputReader(); goto Start; }
I guess someone heard that loops are a performance bottleneck in most applications and decided to do away with them.
