4 ms·

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 t

by superEb 13y ago

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.

dangrossman 13y ago
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.
- superEb 13y ago
  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.
  - dangrossman 13y ago
    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/ https://www.interviewstreet.com/recruit2/
chc 13y ago
> 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.
- superEb 13y ago
  Are you saying that exception handling is trivial and so old that it's irrelevant to know how to do it?
  - chc 13y ago
    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.

by superEb 13y ago

dangrossman 13y ago

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.

superEb 13y ago
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.
- dangrossman 13y ago
  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/ https://www.interviewstreet.com/recruit2/

chc 13y ago

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

superEb 13y ago
Are you saying that exception handling is trivial and so old that it's irrelevant to know how to do it?
- chc 13y ago
  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.