Ask HN: Shouldn't a recent CS grad know how to throw an exception? | Hacker News Reader

Ask HN: Shouldn't a recent CS grad know how to throw an exception?

7 pointssuperEb38 comments

I'm looking to hire CS grads for an entry-level Java developer position. The general hiring process is this:

1. Apply (or get referred by a recruiter) with resume

2. Provide one- or two-sentence answers to some simple prescreen questions

3. Do a phone interview with member of dev team

4. Visit office for a face-to-face interview, and complete a code exercise while in office

5. Receive offer of employment

Now what has happened several times is that a candidate will do well enough on #1 and #2, talk a good game on #3, come in for #4 and totally bomb because they don't know how to throw a freakin' exception!

I am completely dumb-founded by this. How do you get through a complete CS program in college and expect me to hire you as a professional Java developer without knowing one of the basic principles of the language?

Are my expectations really that unreasonable, or do CS programs in general neglect exception handling when teaching OO?

View on HN

Your expectations are really that unreasonable... if you're hiring CS grads without work experience. CS degree programs are not Java developer training, and it's unlikely any kind of classwork would require throwing an exception in any language; catching one maybe. For my own anecdoctal CS program experience, I wrote more functional code than OO, and was never required to use Java in any course.

You're expecting specific professional experience from people that don't have any. Exception handling is not an academic topic. It doesn't help students learn about data structures, algorithms, language development, compiler theory, etc... it's just a control flow construct used by some languages and not others. It's something they'll learn on the job if their job requires it -- easily enough, I'm sure.

If you want that specific knowledge, then require a year of work experience with Java in the job listing. Graduates don't have that by default.

Thanks for your input, Dan. Based on your college experience, it sounds like you would not have been applying for a Java developer position right out of school, correct? But these candidates are. The position they are applying for is officially titled "Jr Java Developer".

What else do you expect a new graduate to apply for but a junior developer position? If you want to hire recent graduates, at the lower salary that comes with versus hiring someone with experience, you're going to have to let them do some on-the-job learning. Test their ability to problem solve and communicate in the interview. Ask for code samples and solve some algorithmic problems together. Do a "fizzbuzz" test by e-mail if you're getting applicants that have never written code at all -- but filtering for a CS degree probably already handles that.

I did a few internships in college. I interviewed with Microsoft. They looked at my resume, code samples I gave them (in C++, Python and PHP), and ran through a phone interview where I solved some problems over the phone in pseudocode. They hired me into a product team as a C#.NET software developer with no experience in C#, .NET or Windows programming. I learned the syntax and libraries on the job and was solving bugs on the second day.

I'm pretty bad at analogies, but this is the best I've got: You want to hire a mechanic. You're a Ford dealer. You're refusing to hire young, trained and certified mechanics because they can't tell you about a specific quirk of the 2009 Ford Escape brake assembly. They weren't trained with Ford-specific knowledge, and they'd figure out the brake thing within 20 minutes of seeing it, but you're balking that these mechanics applied to a Ford dealer without that Ford knowledge.

I disagree.

Exceptions are not some obscure, theoretical language construct and Java exceptions aren't an arcane, experts-only part of the language. If I'm hiring for a "Jr. Java Developer", I expect them to know Java. Not every detail, not the edge cases, the really weird stuff, the 3rd party libraries, the frameworks. But they should know the core language features and syntax. If he's told me he knows Java, and I have to give him a pass on exceptions, is it cool if he can't create a derived class? Doesn't know the type system? Operator precedence? How little competence is okay?

I have an expectation that if you are applying for a "Jr. Java Developer", no matter what you did or did not learn in school, you'd better have picked up a book or cranked up Google and gotten familiar with Java. Why? Because as a programmer, that's going to be the rest of your career. Good programmers are always going to need to be learning something new, often quickly, and usually doing it on their own. If you aren't willing to do that to get the job, why would I expect you to do it once you have the job. And if you can't pick up a passing level of competence in the core language features in a couple of days of prep, then you probably don't need to be working in programming.

Unless it's Lisp. Totally cool if it takes months to wrap your brain around that.

It would be a good idea to make the phone screen more rigorous. Use some etherpad clone-du-jour and have them write code in the phone screen. This way you'll filter out the bozos more efficiently.

You shouldn't expect somebody hired for an entry-level Java position to even know Java. I mean, at least if you're trying to hire somebody who'd be good, they'll have experience in other languages, and the cost of them catching up on Java is miniscule compared to the cost of them catching up with your codebase, with being a professional programmer in general, and it's certainly less than the cost of searching for somebody who's not quite as smart and talented but has better Java-specific knowledge. If you find somebody who has weak knowledge in _everything_, they might still be okay, but if you find somebody who has fairly good knowledge of other aspects of programming (be it another language, or data structures, or HTML or web programming or some protocols and such) then it's a sign that they're not dumb and are worth considering. You should be comfortable simulating how quickly they'd pick up Java when starting.

Edit: Of course, there _are_ a lot of fresh graduates who are scrubs that can't code, signed up for the video games or the money, and thought they'd just focus on grades and they just suck in general. People with general Java background knowledge who just don't know that Java has exceptions are one thing, people who mess up the exception-throwing syntax or forget about checked exceptions are another. What kind of person are they -- did they go to film school or did they go to "films"? People who went to film school will know what their professors told them to know, people who went to films might not have looked at Java specifically but will have a bunch of other knowledge about programming that they looked at outside of class.

Exceptions are not "thrown" but caused, raised at best... The way Exceptions are provided in Java are bad if you'd ask me. Anyway you should expect CS graduates with experience in Python, Ruby, C++, Java, ML, Haskell or similar languages to be able to handle exceptions. Anyway. The question remains why you even want a CS graduate to do Java? Also there are slight differences in the semantics of exceptions in aforementioned languages though i.e. C++ Exceptions are "thrown" without operator new but is syntactically quite similar.

So. Do you think throwing exceptions is a must have for entry-level Java development? I don't. It is not important during most simple projects (which you'd do in your curriculum), is most often ignored or rethrown, or looked up and understood in a few minutes. Aren't patterns more important? Or general ideas? Java is just another language which will become a burden (Luke COBOL). Just my thoughts...

>> ...C++ Exceptions are "thrown" without operator new...

Reading this reminded me how dependent I am on intelisense for a lot of languages. I work in C++ and Java all day every day, and if you asked me how to throw an exception in either, without sitting at a computer (where I'd remember or grope for it), I'd give the syntax for the wrong language 50% of the time.

Maybe assessing people by putting them in front of a computer with an IDE would be useful?

Good point. I failed to mention that the coding exercise is done sitting at a computer with an IDE.

A CS program would not necessarily teach that. Some schools which use Java as an intro language might have one lecture on exceptions. Otherwise it might be covered in a "Software Engineering" elective.

The list of things a new graduate won't know is endless. What matters is what they do know, and even more what they do when they don't know.

I think, "What do you know about exceptions?" is the sort of question which can indicate both. Probably makes for a more interesting interview as well.

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.

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.)

Most of my CS assignments did something like this:

try { doSomethingBad(); } catch(Exception e){ }

Rarely did we have to think about throwing exceptions, just capturing them.

A related question has been bugging me recently: why is there such a mismatch between the expectations of employers and the skills of CS graduates? There turns out to be a lot of research from the ACM SIGCSE (Computer Science Education) community. The McCracken Group paper "A multi-national, multi-institutional study of assessment of programming skills of first-year CS students" and several follow-on studies suggest that getting students to learn programming is truly difficult, a universal observation not just limited to the US. Student performance are often bimodal in intro classes. Also, our conventional assessment tools do not measure programming skill very well. I haven't encountered any data on this, but anecdotally, it seems the expectation gap is considerably different from say the expectation-skill gap in electrical and mechanical engineers. If anyone has any perspective on this, I am really interested in hearing about it.

Aside: At least in some (advanced?) compiler courses, we do teach students how to implement exception handling semantics in a compiler. This is of course very different from learning how to use exception handling facilities in a given language.

I can honestly say that in my course work I can't remember ever having to throw an exception. With that being said, I would think anyone who has done any work outside of course work should at least know how to throw an exception.

I know I did.

I'm not so sure. It is not all that hard to write a moderate-sized Java program without throwing any exceptions yourself. (You'll probably need to catch an exception at some point, but throwing your own tends to fall on the "optional" side of the fence.)

Having just graduated from a UK degree in CS i can im not surprised some people cannot do simple tasks like that. University doesn't really prepare you for a certain language or skill, its up to the individual to take that bit of knowledge and apply it further - (in there own time)

Personally i gained more in my own time / placement however university gave me the tools and direction.

I would recommend finding grads that have completed time in industry, the difference between those that did and those that didnt shocked even myself on returning for my final year.

I *would expect to grad to be able to throw and exception and catch them tbh.

I'd say it depends. If they consider Java to be their primary language and they haven't spent enough time coding in it to have ever encountered exceptions, then they haven't spent enough time coding, period (I'm assuming exceptions weren't the only gap in their knowledge, and this was just an example?). If they consider something else to be their primary language, and are otherwise solid on their CS fundamentals, then by all means, cut them some slack.

My CS program focused strongly on OO and our core language was Java. Exceptions were a regular subject and part of assignments. It seems insane that someone could have a CS degree and not know something so simple and fundamental.

Java is not computer science

I would suggest most of us are engineers, not scientists.

And, on that note, I would say that learning to build robust systems is important. I split my time between CS and EE at college, and in many ways the EE stuff was more useful because after a certain point it wasn't enough to create an amplifier with a few transistors - you had to design an amp that did common-mode rejection, handled noise, dealt with normal tolerances of parts, and so on.

Exceptions are a way of building robust code (not the only way). I would say I'd want that mode of thinking taught. Very, very few graduates are actually going to go on and do original research into algorithms or teach. An engineering education goes a long way in my book.

Sadly, you seem to have spent a lot of time and money on subjects you could have taught yourself in a few weeks of light reading.

Java is not computer science. Exception handling is not computer science. "Something so simple and fundamental" yes, but again, completely unrelated to computer science.

Anyone with half a brain can learn a new language via self study. I would be royally pissed if that's what I was taught in college. I'd go back and ask for a refund.

All of CS can be learnt from books.

True, but not all of them are as easily learned as a new language is. This is coming from someone who didn't go to college and has been working in the industry for almost ten years now.

Agreed.

If it's stated that the position is a Java position, then you would reasonably expect the people applying to know how to throw an exception. Computer science has nothing to do with it.

I got a java job out of college and would have (and still probably) would fail your test. I can't remember the last time I used an exception in Java

Seems reasonable, assuming you asked about Java experience and they say they're familiar with the language.

Reply on news.ycombinator.com