Hacker News Reader

Comment by jbranchaud | Hacker News Reader

Granted, I know how to throw an exception, but the large majority of my undergrad career was about solving problems that were evaluated on 'well-formed' data. It was rare for the code to need to be able to handle exceptions. Perhaps this is the culprit.

View on HN

Agree, sad reality of most CS courses taught at school, the hw problems do not resemble real world professional problems.

Eh... It would be equally sad if students spent the bulk of their time learning the ins and outs of one or two languages. Languages are tools, easy to learn. Concepts span multiple languages. Exception handling is specific to a given language.

In a good CS program, you learn how a CPU is built up from transistors to logic gates to ALUs and other components. You learn how machine code is executed on that CPU. You learn how higher level languages are compiled to those simpler instructions the CPU can understand. You learn how to write compilers and interpreters, then develop your own programming language that's compiled or interpreted by your own program, and implement a real algorithm in your language. At this point, a homework problem of "handle this exception when the file is not found in Java" is about as enlightening as teaching a master mechanic "handle being handed the wrong size wrench while attaching this part".

Learning the specifics of a programming language some employer uses on the job is about as hard as a salesman picking up a new industry's jargon. It takes a few days, but it's nothing any capable graduate can't handle at that point. There's nothing sad about this reality.

So it's a simple concept that takes no time to learn, and they haven't yet learned it before showing up for an interview. Doesn't that tell me something right there?

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.

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/

> So it's a simple concept that takes no time to learn, and they haven't yet learned it before showing up for an interview. Doesn't that tell me something right there?

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.

Are you saying that exception handling is trivial and so old that it's irrelevant to know how to do it?

I'm saying the syntax for throwing an exception in Java is trivial, and that there are many programs you could write where throwing your own exceptions is irrelevant.

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.

Agree, sad reality of most CS courses taught at school, the hw problems do not resemble real world professional problems.

Google doesn't use exceptions at all, at least in C++ code (http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...), so according to you, their problems don't "resemble real world professional problems"? (Whatever "real world" and "professional" means - whenever I see these terms, it's red warning lights all over for me.)

Reply on news.ycombinator.com