Don’t hire a Java programmer. They’re six-a-penny. Hire a software developer who understands that writing code is the easy part, and can tell you about stuff that matters, like requirements capture, design patterns, test planning, impact analysis, good logging practice and project documentation. If they’re a walking API reference, they probably don’t know what the internet’s for.
Update: It’s been (fairly) pointed out that I haven’t actually answered the given question, so I’ll address that here.
- What are some common pit-falls when working with dates and/or times, and what can/should be done to mitigate them?
- What is inversion of control, and why is it a good thing?
- What design principles can be used to facilitate coding for accessibility?
- In a service-oriented architecture, what considerations should be borne in mind when deciding between client-side and server-side validation?
- Stakeholders are debating whether some existing behaviour should be changed, or left as-is. One of them asks you “Can’t you just make it configurable?” What is your answer?
It may be argued that these questions aren’t exactly tailored for Java programmers, but I’d consider them more important to any programmer than anything language-specific, and as such, they are questions I’d ask to gauge the quality of a Java programmer.
Update 2: Notes on the above:
- In my experience, dates and times account for a disproportionate share of coding defects. Recognising common errors with time-zones (and their impact on dates), daylight saving time, locale-based formatting, etc. is vital. But more so are recognising the importance of suitable representations when persisting or (de)serialising data; consistent use of mature, non-lossy APIs throughout business logic; avoiding any string manipulation until last-minute rendering, and so on. These are design considerations; getting them right from the start makes coding a breeze. What’s more, these principles apply to pretty much every other complex data type; if a candidate can get dates/times right, the rest should follow.
- Largely speaks for itself, and tests their “big picture” aptitude, but in particular, this a great opportunity for them to demonstrate an appreciation for test-driven development.
- Understanding the uses of, say, encapsulation and abstraction is a good thing. But the real point of this question is to see whether a candidate is used to considering accessibility from the get-go. It should never be an afterthought.
- Another “big picture” question, and good to see how security-conscious they are.
- The point here isn’t to see how they’d handle stakeholders. It is to see whether they themselves recognise the ongoing costs (complexity, testing, maintenance, etc.) associated with adding configurable behaviour properly. If they don’t, there’s a good chance they will cut corners to deliver.