Comment by dangrossman | Hacker News Reader

Comment by dangrossman | Hacker News Reader

Parent Full thread

That they don't know how to throw an exception in Java doesn't mean they don't know what an exception is and how it can be used to control program flow -- why not ask them about it? All it tells you is that they have no professional experience as a Java programmer... which you already knew before interviewing them.

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.

I would venture to guess that you have not done much hiring and, thus, have not been burned by taking on developers, spending time and money to get them up to speed on application architecture, domain knowledge, and team processes, only to find out that they don't know how to write code.

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.

That's what you think your hiring process is designed to do. Instead it's screening for particular pieces of trivia instead of knowledge and competency. It's only going to get worse as vanilla Java becomes more and more relegated to maintenance of old codebases. It's not a language most CS programs use to teach at this point.

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/

Reply on news.ycombinator.com