How do you get a useful idea of the skill level of a Java developer? There are of course many options to test basic knowledge of Java. More advanced tests might get into specific technologies. This test is different. It is designed not simply to test recall of facts, but rather test problem solving ability. It is not a speed test, the task outline is reasonably simple and a period of one day is specified. Any Java capable developer will be able to complete the test in much less than this. This is also not a 'trick' test, in that there are no obscure bugs trying to trick developers. Neither is any technology outside Java and some basic Spring used.
This week I am posting the test itself for those who want to take a look and perhaps try it out themselves. Next week I will be posting an example solution and the text notes that will allow you to evaluate applicant solutions.
The reason I am posting it here is because I am interested in whether this style of test will be generally useful, both for testing applicants for Java positions and for teaching new developers through example. It will be a jumping off point for a larger discussion of what we value in developer skills. And perhaps I'm simply barking up the wrong tree :-)
Instructions to Applicant
Vladimir Antanov has fled the country with his girlfriend Sonya. My company employed Antanov to maintain our critical communication systems. We urgently need to add a new feature the the existing software, and knowing you are a Master Java Developer we have chosen you to modify the software to communicate with our new clients.
Please find attached the project and source code. Currently the system processes notifications and sends them to email, database or a web service. We need to add another endpoint - JMS.
The JMS connection requires configuration details:
Server Name
Port
Queue Name
You have one day to create a new fork of the project and apply your changes. Once complete please post the URL for your fork in the comments below. You can find the repository here:
https://bitbucket.org/cheetah100/poorexample/src/master/
Note: We don't expect an actual JMS connector - follow the same pattern as the existing senders which simply output to the console.
Note that the repository URL has changed to BitBucket as of October 2024
Top comments (10)
Okay I gave this a go and went ahead and made some changes. Here's the link git.nzoss.org.nz/brian/poorexample This was a fun little thing. I'm interested to see part 2. I'm self taught but I have never used Spring Boot.
You correctly moved the configuration of each sender into the senders themselves. You also correctly added a interface and modified the senders to implement this rather than disparate calls.
The one thing that could have been done better is in the 'Alert' package, where you have a AlertHandler which would need to be modified if another sender is introduced. Ideally you want to end up with a system where you can simply code a new type of sender and add it to the bean configuration.
I see exactly what you mean. I made it more complicated than it needed to be, your solution was much simpler. I'll have to see if I can find some 'refactoring challenges' online, because this seems like a good way improve my coding/critical thinking skills. Thanks for taking the time to look it over and giving your feedback.
Peter,
This morning I've made an attempt at your test.
Currently I'm doing a Computer Science degree and only did OOP and Java in one module. Along with a bit of OOP in PHP.
As I've never developed in a commercial environment, I haven't come across Maven or Spring.
Overall I struggled more with Github than I did with Java.
It took me less than 1 hour, so I'm not sure if I missed anything?
My attempt is at
I look forward to some feedback.
Thanks,
Simon
Hi Simon, congratulations on completing the task as written.
Take another look at the code with the eyes of a code reviewer. Ask yourself how you might improve or refactor the code base while introducing the new functionality. If you do make improvements note down what the changes are and how they make the code better, but keep them to yourself for now.
Next week when I publish my solution I plan to have a discussion about the different approaches people took.
Thank you Peter.
I did see quite a few changes that could be made.
I've removed the link from my post, until other people have had a go.
I'm not sure what your goals are, but it seems kind of easy? It took me 15 minutes. Given that, I'm assuming I must've missed something. I did actively resist the urge to fix things I disliked in the code, because that wasn't asked, and my assumption jumping into anything existing is to at least first mimic it as written.
For the sake of data-gathering as I think that's your goal in terms of where it is in relation to stuff: I've been programming for almost two years total, working professionally in 100% un-Java-related fields for about four months total. I have no idea what Spring is, but it was really very clear-cut. I'm still working out how to run it, but IntelliJ at least confirms build success. I've taken two semesters of Java at a local community college, but I'm super rusty because my last course in it was a few months ago at this point.
If you really do want the repo, here: github.com/aleph-naught2tog/poorex...
Okay, I'm kinda jumping the gun here in terms of revealing part of the purpose of the test, but one of the first aspects is to see if the applicant will resolve poor coding issues in addition to simply following the specification. The intent was to identify confident coders who will fix code quality issues proactively rather than simply follow the minimal work to complete a user story. The name of the project is 'poorexample' for a reason; it exhibits several common poor coding techniques. The instructions said applicants have a day, which is way more than any coder needs to complete the task as you correctly identified. The reason was so they would not feel overtly time constrained.
In relation to running it there is a BootStrap class which has a main method that can be run directly in the IDE.
What I recommend is taking another look to identify all the aspects you think are an issue and how you would fix them. Perhaps make the modifications to your repo and add comments to the code, or as a separate file. On Saturday I will be posting my solution.
I actually wrote this back in 2013, so as you say it is a little dated by the approach in Spring. It has been useful in the past to me as it was possible to identify which applicants had a grasp of good coding practices. It is certainly not a IQ test. Hopefully this will inspire others to write similar tests for other languages. You are right about post test interviews, in that this test is used as a foundation to explore their reasoning processes. I appreciate your feedback.
Solution is now available.
dev.to/cheetah100/java-developer-l...