I've done quite a few technical tests in my time and I would say that your best bet is to just code something fairly simple that demonstrates understanding of programming concepts, patterns and structures. The actual subject matter is irrelevant... I got asked to code a chicken once (yeah, exactly) the tester said 'everybody knows what a chicken is and does, what I want to see is how you choose to represent it and its behaviour in code'...
You don't want the tester(s) to have to understand the concept of the program, as well the code you've written. Think about it, whenever you read a good coding book, they never use complex examples, it's always simple stuff that everyone knows.
When I did the chicken test, I thought about the structure of a chicken, which parts of it could be abstracted out to ease the creation of other animals, which behaviours could be extracted into interfaces, especially those that would be shared by other things, the decisions involved in these processes. Then the interactions that would occur between a chicken and the outside world, how it could be tested, maintained, extended.
It's not all about how well you can solve the problem, but also how well the solution will stand the test of time, how easy will others be able to pick up your work and continue it, intergrate with it, or fix bugs in it.
There's also a trade of between the perfect peice of software, and software thats finished on time. In the world outside uni, the most elegant solution may not (usually wont) be the right one because the customer isnt prepared to pay the time it takes. So make judgement calls based on that, and even add comments to the effect of "in a perfect world this may have been done differently..." etc, and draw conclusions... blah blah blah
Really exiting world you're getting into mate, take it from me. I'm 10 years in now and still learn new stuff everyday. Also, I actually quite like Java (i'm a C# guy now), but there is BIG money in Java, so stick with it.
Good luck in your interview
