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.
I checked out your test. I think its a fun little puzzle that anyone that has a basic understanding of core Java should be able to solve.
It tests out knowledge of interfaces, inheritance and dependency injection and building/running with Maven.
The user has to have some basic familiarity with spring and the way it's configured. You might even stump (for a little while) some of the newer Spring users who are used to Java configuration and have probably always started a project using Spring Boot.
You could also do some basic evaluation of familiarity with clean code concepts based on the submitted code.
I think it makes sense as a level 1 challenge to screen out a large pool of candidates for people who have a sold grasp of Java basics. Later you can make the tests more specific with regards to various technologies you need or types of problems that you generally solve.
I don't have many suggestions but maybe you could add a Gradle variant (if this makes sense for your organization). Also, as a companion to the submitted code you could ask for candidates to write what they liked about the project and what they would change and how.
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.
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.
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.
Solution is now available.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.