Here's my review of one of the four interviewers at Guidewire. His primary issue was that he had only one solution in mind, which was syntactically and semantically broken. Yet, he dogmatically tried to push me towards it the entire time. It went flawlessly with the other three interviewers that day, both in terms of their interviewing style and my performance, which makes this all the more painful a loss.

The scenario is that a customer orders a coffee from a vending machine by selecting a choice from several categories, such as size, flavor, and creamer type. Given their choices, we then have to figure out the cost. The twist is that the various creamer choices cost slightly more if you get an extra-large coffee. For example, if you choose milk as your creamer, it's normally 50 cents; but if you also choose XL as your size, the milk costs 60 cents.

The interviewer’s solution (in Java) was to have an enum for each category: Size, Creamer, Flavor, etc. Each choice in a category is one of the instances of the enum: enum Creamer{ NONE, MILK, HALF_N_HALF }. Rather than have each enum instance store its normal cost as an int, we cleverly set the int value of the instances to the cost of the choice: enum Creamer{ NONE = 0, MILK = 50, HALF_N_HALF = 45 }. To deal with the fact that creamer cost depends on the size you choose, we add the method getPriceGivenSize(Size). If later on there are new dependencies between categories (I asked him this "what if"), we just add methods, such as getPriceGivenFlavor(Flavor), getPriceGivenSizeAndFlavor(Size, Flavor), etc. The contents of these methods are simply switch statements which return a value based on the Size/Flavor passed in.

So here’s my critique of his solution. First off, it’s entirely hard-coded. To add a new choice/category, change a cost, or add/change a dependency between categories, you have to directly edit the Java code that runs the vending machine, recompile, and reinstall it. How do we know when to use the "int value" of the enum to get the cost of a choice, versus calling getPriceGivenSize(), or even getPriceGivenSizeAndFlavor()? In other words, there’s no real way for the client to describe the business logic (costs and dependencies), and no way to use that business logic when figuring the cost to charge the customer. The idea of setting the enum instances to their cost is unsound because it breaks as soon as we have two choices that cost the same amount. Also, the interviewer was thinking of a syntax, MILK = 50, which is only available in C/C++, not Java. Conversely, enum methods aren’t available to enums in C/C++.

His confusion about enums is ironic. After giving me several hints to try to push me towards his expected solution, he suspected I simply didn’t know enough about enums to think of his MILK = 50 solution. So he had me look up information about Java enums on the internet during the interview. I mildly protested that I already knew plenty about Java enums and their use, which isn’t much, really, but he still had me go through the motions.

Despite the constant misdirection, I came up with a perfectly good solution and presented it to him. He admitted that he didn’t understand my solution and spent the next 10 minutes at the board describing his solution, as I fully detail above. We’re running out of time at this point. I patiently waited for him to finish his presentation and then reflected back my understanding of his solution to him so he knew that I got it. I then asked to try presenting my solution to him again on the board. After he started to get it, I had to deflect a couple straw-man arguments against it, and then finally, he seemed to "understand" the solution. He walked out of the room to get the next guy without saying bye or shaking my hand. He seemed upset.

Support dependent costs between categories. Please reference the question mentioned above.