本文发表在 rolia.net 枫下论坛A lot questions need real experience(hands-on) in those specific area in order to provide a in-deepth answer, although not too difficult. I just feel the questions are too much tie to java language instead of basic OO concepts. I would like to add some OO questions prepared for senior programmers. Does not matter if they even don't give them an answer.
e.g. Explain the difference between Abstract Class and Interface, when and why you choose one instead of another.
e.g. A saw many programmers like to use Class.forName(). What do you think about it?
e.g Can you draw a UML digram for the Role-base access control system. (access control is used in very project so to be a good sample. I want to see how complicated can he imagine. Maybe too specific?)
... and a bit of production experience?
e.g. Can you explain how to do a proper performance/load/stress testing?
I am also very concern about her/his experience in process and methodologies. The cadidate's fit into your current org's methodology is much more important than a bit trade-off in skills. XPers are very different animals from normal RUP persons. So I would like to ask them:
e.g. What do you think about XP?
e.g. What do you think about re-fectoring?
Those questions are easy to figure out whether the person has some real experience in e.g. refectoring or just read them from a book.
Finally, I would like to shorten the list to less than 10 questions. To me, most of questions are better being discussed in conversation instead of written in paper. You know, we programmers, hardly write code in paper. It's very un-comfortable to answer programming questions in paper. e.g. for the life cycle question, most probably I will just write a few states.
I would like to put only those need a bit time to think or better to use a paper to explain,e.g. drawing.
As you guys mentioned, usually it's not difficult to find a person matches your skill level. 10 questions are more than enough to see that. So the more importand is the person's personality. By exercise those questions within a conversation, you can know a lot more. The way he approaches a problem, his manners, honest or whatever. That's why most of successful interview in based on the feeling you give to the interviewer rather than your static skill set.
Just a bit thought. I remember there is a good article in theserverside on "how to interview a programmer"更多精彩文章及讨论,请光临枫下论坛 rolia.net
e.g. Explain the difference between Abstract Class and Interface, when and why you choose one instead of another.
e.g. A saw many programmers like to use Class.forName(). What do you think about it?
e.g Can you draw a UML digram for the Role-base access control system. (access control is used in very project so to be a good sample. I want to see how complicated can he imagine. Maybe too specific?)
... and a bit of production experience?
e.g. Can you explain how to do a proper performance/load/stress testing?
I am also very concern about her/his experience in process and methodologies. The cadidate's fit into your current org's methodology is much more important than a bit trade-off in skills. XPers are very different animals from normal RUP persons. So I would like to ask them:
e.g. What do you think about XP?
e.g. What do you think about re-fectoring?
Those questions are easy to figure out whether the person has some real experience in e.g. refectoring or just read them from a book.
Finally, I would like to shorten the list to less than 10 questions. To me, most of questions are better being discussed in conversation instead of written in paper. You know, we programmers, hardly write code in paper. It's very un-comfortable to answer programming questions in paper. e.g. for the life cycle question, most probably I will just write a few states.
I would like to put only those need a bit time to think or better to use a paper to explain,e.g. drawing.
As you guys mentioned, usually it's not difficult to find a person matches your skill level. 10 questions are more than enough to see that. So the more importand is the person's personality. By exercise those questions within a conversation, you can know a lot more. The way he approaches a problem, his manners, honest or whatever. That's why most of successful interview in based on the feeling you give to the interviewer rather than your static skill set.
Just a bit thought. I remember there is a good article in theserverside on "how to interview a programmer"更多精彩文章及讨论,请光临枫下论坛 rolia.net