Should I expect them to be knowledgeable of complicated concepts if they are not knowledgeable of simple concepts?
I'm sorry, I know I'm being obtuse here. I just didn't think that being able to code `throw new Exception();` in an interview for a Java developer position was too much to ask. I guess I'm wrong.
It tells you that it's trivia. There is a world of trivia surrounding any topic, and 100% of the time you will be able to nail somebody on not knowing something that's simple to learn if you just pick the right piece of trivia.
> Should I expect them to be knowledgeable of complicated concepts if they are not knowledgeable of simple concepts?
OK, so Cocoa has this OO IPC technology called Distributed Objects. It's really brain-dead simple (like four lines of code to set up), but it's pretty archaic. I have more than a decade of experience in Objective-C/Cocoa at this point and feel pretty confident saying I have a solid understanding of the language and framework — but if you asked me to write some code using Distributed Objects, I would have to go look it up. I'd have it down in a couple of minutes once I knew it was needed, but I could not produce it on the spot because you can't hold every piece of trivia in your mind all the time, and this particular bit of trivia has never been needed for the things I've done.
Focusing on the precise reason I don't know Distributed Objects is really a red herring. I was trying to give a personal example of where I could be criticized for not knowing something simple. The point is that it's simple to learn, just like the syntax for throwing exceptions. But I don't know it because my experience just hasn't taken me there yet.
Basically, what you're seeing here is just a lack of experience with real-world Java programming. It's like knowing all the cross-browser compatibility gotchas in JavaScript. Not knowing this doesn't indicate a deeper problem with their education, because the point of a computer science education is not to teach every piece of Java trivia. As they gain experience, they will easily pick up all the trivia that's relevant to their job, and the other trivia (like Distributed Objects) will remain unknown.
Well, why didn't they look that up before the interview? Because they didn't know that'd be the one detail out of thousands of bits of syntax and library knowledge you pick up when you do work in a certain language. The only way to pick them all up is experience -- and again -- you already know they don't have it.
If you don't want to hire college graduates for a junior developer position without work experience, then take junior off the title and bump up the pay. Add a work experience requirement. It sounds like you'll be a lot happier with that.
A developer that cannot take basic requirements and codify them into working software is not a developer. A logician, scientist, or mathematician, maybe, but not a developer. And our hiring process is designed to help distinguish the developers from the non-developers.
You can test whether someone can turn requirements into working code without testing for specific bits of trivia. Simply saying "solve this in the language you're most comfortable with" does away with that flaw in your process, while still allowing you to see whether they can code, whether they write tests, whether they think of edge/corner cases, whether they handle errors or malformed inputs, how they think about problem solving, etc.
There are plenty of companies that hire developers without finding out they hired people who can't code only after investing in them. They don't do it by adding language trivia to the interviews. If it's too difficult for you, you can outsource that part: https://www.interviewstreet.com/recruit2/