4 ms·
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. I
by jbranchaud 13y ago
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.
- suyash 13y agoAgree, sad reality of most CS courses taught at school, the hw problems do not resemble real world professional problems.
- EpicEng 13y agoEh... 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.
- dangrossman 13y agoIn 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.
- superEb 13y agoSo 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.
- dangrossman 13y agoThat 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.
- superEb 13y agoI 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.
- dangrossman 13y agoThat'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/ https://www.interviewstreet.com/recruit2/
- gngeal 13y agoAgree, 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.xml#Exceptions 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.)