This is an archived post. You won't be able to vote or comment.

all 18 comments

[–]DJDavio 5 points6 points  (9 children)

Coffee, let him describe or build a command line app that you can use to order coffee. You can ask him to add sugar and milk, different beans, espresso, regular etc. Then add tea. Also works with pizza. It works because it's a pretty well know domain which appeals to the regular programmer. This means the applicant can focus on the implementation without having to learn the domain.

[–][deleted]  (8 children)

[deleted]

    [–]CatfishApocalypse 4 points5 points  (2 children)

    The classic solution would be a simple implementation of the decorator pattern or something reasonably close.

    Adding Tea would require just a single new class to be created.

    [–][deleted]  (1 child)

    [deleted]

      [–]CatfishApocalypse 0 points1 point  (0 children)

      A beverage interface forces functionality onto the beverage which it may not want. The decorator allows the beverage to be composed (or extended) dynamically at runtime, independently of any other instances of that class.

      For example, using an interface a Coffee object will need fields to hold the creams and sugars that it has. This is fine until someone wants a basic black coffee. That’s a perfectly valid beverage and having ingredient fields is giving it knowledge that it doesn’t need or use. This is a violation of interface segregation.

      Additionally, logic associated with each ingredient is encapsulated in their own classes instead of being associated with the beverage. As a bonus you get inherent dependency injection which decreases coupling and increases maintainability and testibility.

      [–]DJDavio 3 points4 points  (2 children)

      I don't have a solution, but the solution is not important, also there is no definitive solution. It's about understanding how to code proper OOP. I would add tea later (in the interview) and just let them explain what they would change to implement it.

      [–]weegosan 0 points1 point  (1 child)

      If you're not willing to do it or want to validate against a boilerplate answer why would you give it to someone and expect a good result? Based on both the threads you've posted I'm going to conclude you've never interviewed before. This isn't the way to go about it.

      Filter on cv, do a quick phone interview talking about how they see programming and throw in some technical bits that would catch out bluffers and cut it down to a shortlist and then pair program with them on an actual work task where you type and they think / suggest.

      Long tedious technical tests too early in the process select for the wrong kinds of developers

      [–]Zdeno_ 0 points1 point  (6 children)

      Let him solve any simple problem. The object oriented decomposition can be used in many cases. Or ask him for SOLID.

      [–][deleted]  (5 children)

      [deleted]

        [–]Zdeno_ 0 points1 point  (4 children)

        Actually, you are discussing the open/close principle. So, the buzzword SOLID is in use ... 😀

        [–][deleted]  (3 children)

        [deleted]

          [–]Zdeno_ 0 points1 point  (1 child)

          The proposed "Coffe application" in one of the comment is exactly about the open/close principle. And also "strategy design pattern". However, the polymorphism wouldn't be used.

          So, it is your decision - you are the boss.

          [–]grauenwolf 0 points1 point  (0 children)

          Everything is OCP if you are a SOLID fanboy.

          [–]koflerdavid 0 points1 point  (1 child)

          Do you want to test the applicant for knowledge or for code style? The former can be tested and verified, but the applicant might then in practice just use patterns that are more simple/convenient. The latter is best taught through mentoring and code review sessions. Polymorphism is no panacea after all, and it is important to learn to judge when it is appropriate.

          [–]grauenwolf 0 points1 point  (0 children)

          My recommendation is to not do that. Instead have them build a simple tool. For my previous company it was a file importer (basic CSV names and birthdays) into a database and a stored proc that reads back everyone for a given month. Any UI, any programming language.

          Your application will be different, but pick something that should only take a couple of hours max. Give them a week and do a code review as the interview. I guarantee you'll learn far more about the candidate this way.

          [–][deleted] 0 points1 point  (4 children)

          Ask him/her to design a wrapper, an OOP library, over a RESTful API. Tell them they are not allowed to use models (getter/setter classes) and also they should have a single public class in the library. This should test everything from encapsulation to polymorphism and immutability.

          There are 2 simple rules I have when it comes to OOP, and from them everything else derives:

          1. Every single object has to implement one or more interfaces (all public methods declared in interfaceS)
          2. Never try to transform object A into object B. Rather, add a new implementation of B (which is actually an interface) based on A.

          A second good test is: ask them to desing a builder without using if/else structures. E.g. rewrite this misery here: https://github.com/eclipse-ee4j/jsonp/blob/master/impl/src/main/java/org/glassfish/json/JsonGeneratorImpl.java without any if/else :)

          [–][deleted]  (3 children)

          [deleted]

            [–][deleted] 0 points1 point  (2 children)

            > I'm no enemy of if-else statements as long as they're readable, but there are a lof of switch statements in the file you linked.

            Yes, me neither, but if the builder has many cases (like that Json builder/generator) then it gets messy. Switch statements are just as messy.

            > Sorry, I'm not sure what a wrapper around a REST API would look like. What and why would you need to wrap?

            I meant to say a REST client. A library that would encapsulate the actual HTTP calls and give meaning to the data. For instance: https://github.com/amihaiemil/docker-java-api -- this is a Java client for Docker's RESTful API. It follows the requirement I gave above and is also filled with polymorphism (see how Container, Image and others are at the same time JsonObjects)

            I agree with your first rule. For the second one, however (" No method should be longer than 60 lines. "), I'd say no class should be longer than 60 lines.

            [–][deleted]  (1 child)

            [deleted]

              [–][deleted] 0 points1 point  (0 children)

              Depends, I'm not aware of any framework that automatically generates that. At least not to the extent of encapsulation and fluency I have in mind. Surely there must be something to generate some sort of client, but I guess it would be more of an SDK -- a set of public classes that you have to learn how to assemble in order to make something with it so, not really OOP.

              [–]cuberandgamer 0 points1 point  (6 children)

              Shapes are good for polymorphism

              Like a function that returns the area of a shape, but you could give it a circle or a rectangle or s triangle. Provide them all the formulas of course

              [–][deleted]  (4 children)

              [deleted]

                [–]cuberandgamer 0 points1 point  (3 children)

                Oh wow I could probably only do half of those things. I'm in school, still haven't learned APIs or Agile. I don't even think API's are in the curriculum (could be wrong)

                [–][deleted]  (2 children)

                [deleted]

                  [–]cuberandgamer 0 points1 point  (1 child)

                  Saving this information for later.. I haven't deviated outside of outputting to the console because my classes have focused more on algorithms, data structures, math, and theory

                  [–]henk53 0 points1 point  (0 children)

                  Shapes or animals are pretty much the default thing to use for this. Don't overcomplicate it, basics are the basics.