Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Java interview exercise. Question regarding, 'packaging and communication'.

  • 14-08-2016 01:55PM
    #1
    Adren
    Registered Users, Registered Users 2 Posts: 75 ✭✭


    Hi there,

    I was given a little exercise to complete for a graduate position. I have only done a HDip in Computer Science, so that's only about 8 months of Java stuck in with a whole other pile of stuf.. long story short.. I've only get the basics of coding, and OOD down.

    So I am wondering if could someone help me understand what the interviewer means by

    "I’m looking for a solution that indicates you know the basic tenants of software object based design, and a little about how developers communicate and work together (you show that by your packaging and communications patterns)"

    Think is I haven't worked with programmers yet, so I don't really know much about this.

    What exactly are we talking about here?

    Another question I have also (which probably pertains to the above enquiry) In the spec doc it mentions include your code together with supporting
    material (testing/assumptions/docs).

    I haven't done testing yet, but I think I can get my head around it using junit.
    But is there a formal way of documenting assumptions, and creating documents?

    It asks "Please follow the exercise as accurately as possible, keeping your assumptions to a minimum, but if/when you do make assumptions, please document them clearly"

    For instance is a word doc, with bullet points sufficient for this?

    Lastly it mentions
    "Please provide instructions that would enable an evaluator to run your game"

    Would this be as simple as describing in a separate word doc, called 'How To Execute Java File" and in that file just give the instructions of how to run a .jar file from the command prompt?

    Many thanks for your help,
    complete Java beginner here, hoping, hoping, to get a job programming.. eventually!

    Thanks again.


Comments

  • #2
    pillphil
    Registered Users, Registered Users 2 Posts: 792 ✭✭✭pillphil


    Adren wrote: »
    Hi there,

    I was given a little exercise to complete for a graduate position. I have only done a HDip in Computer Science, so that's only about 8 months of Java stuck in with a whole other pile of stuf.. long story short.. I've only get the basics of coding, and OOD down.

    So I am wondering if could someone help me understand what the interviewer means by

    "I’m looking for a solution that indicates you know the basic tenants of software object based design, and a little about how developers communicate and work together (you show that by your packaging and communications patterns)"

    I think this is about creating modular reusable code and placing the classes in appropriate packages. Also, comment your code well. Javadoc will create a nice html document if you comment your code in a specific way.

    Think is I haven't worked with programmers yet, so I don't really know much about this.

    What exactly are we talking about here?

    Another question I have also (which probably pertains to the above enquiry) In the spec doc it mentions include your code together with supporting
    material (testing/assumptions/docs).

    I haven't done testing yet, but I think I can get my head around it using junit.
    But is there a formal way of documenting assumptions, and creating documents?



    It asks "Please follow the exercise as accurately as possible, keeping your assumptions to a minimum, but if/when you do make assumptions, please document them clearly"

    For instance is a word doc, with bullet points sufficient for this?

    Something like this, there may be better samples available. http://www.construx.com/Software_Design_Specification/
    Might not need to be as in dept a this. Google design specifications and see what you think.

    You may need to do some manual testing of the application too, don't forget to document it

    Lastly it mentions
    "Please provide instructions that would enable an evaluator to run your game"

    Would this be as simple as describing in a separate word doc, called 'How To Execute Java File" and in that file just give the instructions of how to run a .jar file from the command prompt?

    I think it's more instructions on how to use the application, not so much how to run it initially. Although no harm in including that.

    Also, if you have anything other than an executable java file, such as a database that requires setup, you should include that too. Or create a file to set it up automatically.

    Many thanks for your help,
    complete Java beginner here, hoping, hoping, to get a job programming.. eventually!

    Thanks again.

    The message you have entered is too short. Please lengthen your message to at least 1 characters.


  • #3
    aidanathome
    Registered Users, Registered Users 2 Posts: 172 ✭✭aidanathome


    Adren wrote: »
    "I’m looking for a solution that indicates you know the basic tenants of software object based design, and a little about how developers communicate and work together (you show that by your packaging and communications patterns)"

    Think is I haven't worked with programmers yet, so I don't really know much about this.

    What exactly are we talking about here?
    IMO, source control would be the main method for managing/sharing content between developers. I can only guess that's they mean here. You could commit your code to a repository on github, as a means of demonstrating this?
    Adren wrote: »
    Another question I have also (which probably pertains to the above enquiry) In the spec doc it mentions include your code together with supporting
    material (testing/assumptions/docs).

    I haven't done testing yet, but I think I can get my head around it using junit.
    But is there a formal way of documenting assumptions, and creating documents?

    It asks "Please follow the exercise as accurately as possible, keeping your assumptions to a minimum, but if/when you do make assumptions, please document them clearly"

    For instance is a word doc, with bullet points sufficient for this?
    Every company has different ways of doing documentation. A word document would suffice where it's clearly broken into different sections, as needed. Print it as PDF and send that on, would be a slightly better way of guaranteeing formatting.
    Adren wrote: »
    Lastly it mentions
    "Please provide instructions that would enable an evaluator to run your game"

    Would this be as simple as describing in a separate word doc, called 'How To Execute Java File" and in that file just give the instructions of how to run a .jar file from the command prompt?

    Many thanks for your help,
    complete Java beginner here, hoping, hoping, to get a job programming.. eventually!

    Thanks again.
    Yes, pretty much. Basically a readme. The exact format of the command(s) that they need to use to run it. Do they need Java 8, or any other dependencies? These should be clearly stated.

    Best of luck with it!


  • #4
    14ned
    Registered Users, Registered Users 2 Posts: 768 ✭✭✭14ned


    aidanathome wrote: »
    IMO, source control would be the main method for managing/sharing content between developers. I can only guess that's they mean here. You could commit your code to a repository on github, as a means of demonstrating this?

    As a sweeping generalisation I'd have said the issue tracker/pull requests is how teams share content with one another, whilst source control is how team members share content with one another. As software matures, the dev team shrinks into a maintenance team and almost all changes tend to go via the issue tracker.

    I'd also mention in any interview that any dev shop with any quality will do code peer review to share understanding of content committed across a team. There are variations on how each shop does that, some pair up programmers who always review one another's work, some require two or three or even four team members to review and approve every single commit entering HEAD, other shops only have peer review of a sprint's changes happen at the end of each sprint. It varies according to the philosophy at that shop, the maturity of the software etc but if a dev shop isn't doing regular peer review, there is usually not an aspiration for quality and product longevity.

    If the role you're applying for is with a team not doing regular code peer review, I'd strongly consider walking away unless they have a superb reason for not doing so (and taking with a pinch of salt "we intend to implement that next month" etc).

    Niall


  • #5
    Decos
    Registered Users, Registered Users 2 Posts: 243 ✭✭Decos


    Adren wrote: »
    "I’m looking for a solution that indicates you know the basic tenants of software object based design, and a little about how developers communicate and work together (you show that by your packaging and communications patterns)"

    Think is I haven't worked with programmers yet, so I don't really know much about this.

    What exactly are we talking about here?

    Id agree with philphil above, it sounds like they're looking for you to use sensible clear concise class and package names for your files as well as sticking to naming conventions and commenting your code appropriately.

    I really don't think they're referring to source control here. Its a graduate position so they'll probably assume you don't know much about that anyway.


  • #6
    yes there
    Registered Users, Registered Users 2 Posts: 306 ✭✭yes there


    14ned wrote:
    If the role you're applying for is with a team not doing regular code peer review, I'd strongly consider walking away unless they have a superb reason for not doing so (and taking with a pinch of salt "we intend to implement that next month" etc).

    Assuming code reviews are done right. I have seen both ways.


  • Advertisement
Advertisement