Questions on OOP
-
Juan Carlos Cobas wrote: Any suggestion? Well, as for C++ questions, you might ask about the 4 C++ casts, single/multiple/virtual and public/protected/private inheritance, probably some stuff about the standard library. As for OO and related stuff, talk about Design Patterns, UML, ask the candidates about has-a and is-a and how you might implement them (Liskov Substitution Principle? I think that's what it's called), encapsulation, information hiding, object heirarchies, generic/template programming (orthoganal to OO). Note that not knowing some of this stuff isn't fatal - as long as the candidate shows an interest in learning it. -- Ian Darling "The moral of the story is that with a contrived example, you can prove anything." - Joel Spolsky
Thanks Ian, though I'm afraid they'll never find a programmer that will be able to answer those OOP questions :-)
-
Thanks Ian, though I'm afraid they'll never find a programmer that will be able to answer those OOP questions :-)
Juan Carlos Cobas wrote: Thanks Ian, though I'm afraid they'll never find a programmer that will be able to answer those OOP questions Well like I said, they don't have to know the specifics, just be interested in knowing about them. I think that's really the key thing. Get someone who: a) Is keen to learn stuff. b) Looks like they can get stuff done. The questions are window dressing for determining these two points. -- Ian Darling "The moral of the story is that with a contrived example, you can prove anything." - Joel Spolsky
-
Whats sad is I translated all the ASCII codes from memory :-D:omg::sigh: Roger Allen - Sonork 100.10016 If your dead and reading this, then you have no life!
So, did you get the job then? --Colin Mackay--
"In the confrontation between the stream and the rock, the stream always wins - not through strength but perseverance." (H. Jackson Brown) Enumerators in .NET: See how to customise foreach loops with C#
-
Thanks Ian, though I'm afraid they'll never find a programmer that will be able to answer those OOP questions :-)
Juan Carlos Cobas wrote: though I'm afraid they'll never find a programmer that will be able to answer those OOP questions You're kidding! Those were basic OOP subjects! :omg: Marc Latest AAL Article My blog Join my forum!
-
The company of a friend of mine is looking for a C/C++ programmer and he’s trying to collect some C/C++ questions for the interview. In addition to simple, plain C questions (he already has plenty of them), he is interested in questions dealing with basic OOP concepts Any suggestion? Thanks :-)
:) Better take a look at this http://www.joelonsoftware.com/articles/fog0000000073.html[^] ______________________________ Java: The living proof Moore's law won't solve all your problems
-
So, did you get the job then? --Colin Mackay--
"In the confrontation between the stream and the rock, the stream always wins - not through strength but perseverance." (H. Jackson Brown) Enumerators in .NET: See how to customise foreach loops with C#
I didn't realise I was applying for a job.... All the other questions look reasonable. I need to go look up all the C++ casts to be absolutley sure I would not suck if I did do the interview. The rest seemed OK. Roger Allen - Sonork 100.10016 If your dead and reading this, then you have no life!
-
Thanks Ian, though I'm afraid they'll never find a programmer that will be able to answer those OOP questions :-)
Those are questions I would expect a medium level developer skilled in OOP to know fairly well or at least enough to talk about them a little. Daniel
-
Whats sad is I translated all the ASCII codes from memory :-D:omg::sigh: Roger Allen - Sonork 100.10016 If your dead and reading this, then you have no life!
At least you know that you're a geek! :laugh: :rolleyes:
Who is 'General Failure'? And why is he reading my harddisk?!?
-
Juan Carlos Cobas wrote: though I'm afraid they'll never find a programmer that will be able to answer those OOP questions You're kidding! Those were basic OOP subjects! :omg: Marc Latest AAL Article My blog Join my forum!
Marc Clifton wrote: You're kidding! Those were basic OOP subjects! Really? I would not be able to answar a lot of them... Are you by that saying that I'm a bad programmer, and that I know nothing about OOP? - Anders Money talks, but all mine ever says is "Goodbye!" My Photos[^] nsms@spyf.dk <- Spam Collecting ;)
-
:) Better take a look at this http://www.joelonsoftware.com/articles/fog0000000073.html[^] ______________________________ Java: The living proof Moore's law won't solve all your problems
An illuminating post from Amanjit Gill . . . I figure I must be a half-wit who gets things halfway done, and while it has not been an obstacle on the job, it has been an impediment to getting one. Guerrilla interview techniques should probably be left to gang warfare. I think the original post on OOP techniques and interview questions, as well as the original suggestion have been misunderstood. The request was for areas of questionning that might be helpful in discovering potential in candidates, and the helpful reply was a set of topics. Posing a whole topic as a question would probably not yield meaningful results for two reasons: (1) It is not difficult to learn the definitions to these terms, but as the Amanjit Gill points out to us, asking for definitions won't find you a candidate who gets things done; (2) While rote recitation of canned definitions may indicate an interest, a programmers rendition of what a concept represents in terms of the way s/he has used it will be rambling and vague -- you wind up eliminating the very people whom you wish to choose. To make these helpful suggestions into solutions (a problem-solving exercise in itself), it would be good to take each topic supplied and create a question from it that relates directly to the job (or kind of job) that needs to be done. This may not be a brilliant suggestion, but at least I have summarized all the suggestions into an actionable synthesis of the solution . . . Ernie ---------------------------------- Ernest Clayton Cordell, II E-mail: ernie_cordell@hotmail.com Web page redirect at: http://come.to/ernie Resumee at http://www.perfectagent.com/seeme/ec77394
-
Those are questions I would expect a medium level developer skilled in OOP to know fairly well or at least enough to talk about them a little. Daniel
Daniel Wilson wrote: Those are questions I would expect a medium level developer skilled in OOP to know fairly well or at least enough to talk about them a little. Yes, the stuff about templates, private/public/protected stuff and virtual and abstract functions... But... not always the design patterns and uml stuff, i know several really good programmers that know nothing about that part... - Anders Money talks, but all mine ever says is "Goodbye!" My Photos[^] nsms@spyf.dk <- Spam Collecting ;)
-
Marc Clifton wrote: You're kidding! Those were basic OOP subjects! Really? I would not be able to answar a lot of them... Are you by that saying that I'm a bad programmer, and that I know nothing about OOP? - Anders Money talks, but all mine ever says is "Goodbye!" My Photos[^] nsms@spyf.dk <- Spam Collecting ;)
UML you can throw out the window, IMHO. It's big, bloated, and to get real functionality, like reverse engineering, you have to pay big bucks. I think there's a couple good freeware exceptions, however. As for design patterns, you probably already use them. The biggest thing about DP's is that it formalizes certain common OO architectures and gives them nerdy sounding names so that geeks can talk and sound like they're getting something done. Marc Latest AAL Article My blog Join my forum!
-
Juan Carlos Cobas wrote: Thanks Ian, though I'm afraid they'll never find a programmer that will be able to answer those OOP questions Well like I said, they don't have to know the specifics, just be interested in knowing about them. I think that's really the key thing. Get someone who: a) Is keen to learn stuff. b) Looks like they can get stuff done. The questions are window dressing for determining these two points. -- Ian Darling "The moral of the story is that with a contrived example, you can prove anything." - Joel Spolsky
"Can do, will do" rather than "Yeah, sure" ? The tigress is here :-D
-
Juan Carlos Cobas wrote: Any suggestion? Well, as for C++ questions, you might ask about the 4 C++ casts, single/multiple/virtual and public/protected/private inheritance, probably some stuff about the standard library. As for OO and related stuff, talk about Design Patterns, UML, ask the candidates about has-a and is-a and how you might implement them (Liskov Substitution Principle? I think that's what it's called), encapsulation, information hiding, object heirarchies, generic/template programming (orthoganal to OO). Note that not knowing some of this stuff isn't fatal - as long as the candidate shows an interest in learning it. -- Ian Darling "The moral of the story is that with a contrived example, you can prove anything." - Joel Spolsky
-
The company of a friend of mine is looking for a C/C++ programmer and he’s trying to collect some C/C++ questions for the interview. In addition to simple, plain C questions (he already has plenty of them), he is interested in questions dealing with basic OOP concepts Any suggestion? Thanks :-)
I don't think it is wise to ask C questions when looking for a C++ programmer. C questions always seem to be about arcane shortcuts and I don't think that is they type of programmer you want for commercial, object oriented design. You will end up with code that is unreadable and unmaintainable. Another beef of mine... unless you want to hire a programmer to do your CS homework, don't ask them CS homework-type questions. Ask them real-world stuff. Some things we do not because they are fun, but because, like push-ups, they build character.
-
An illuminating post from Amanjit Gill . . . I figure I must be a half-wit who gets things halfway done, and while it has not been an obstacle on the job, it has been an impediment to getting one. Guerrilla interview techniques should probably be left to gang warfare. I think the original post on OOP techniques and interview questions, as well as the original suggestion have been misunderstood. The request was for areas of questionning that might be helpful in discovering potential in candidates, and the helpful reply was a set of topics. Posing a whole topic as a question would probably not yield meaningful results for two reasons: (1) It is not difficult to learn the definitions to these terms, but as the Amanjit Gill points out to us, asking for definitions won't find you a candidate who gets things done; (2) While rote recitation of canned definitions may indicate an interest, a programmers rendition of what a concept represents in terms of the way s/he has used it will be rambling and vague -- you wind up eliminating the very people whom you wish to choose. To make these helpful suggestions into solutions (a problem-solving exercise in itself), it would be good to take each topic supplied and create a question from it that relates directly to the job (or kind of job) that needs to be done. This may not be a brilliant suggestion, but at least I have summarized all the suggestions into an actionable synthesis of the solution . . . Ernie ---------------------------------- Ernest Clayton Cordell, II E-mail: ernie_cordell@hotmail.com Web page redirect at: http://come.to/ernie Resumee at http://www.perfectagent.com/seeme/ec77394
Of course my post totally missed the point - basically the orignal poster probably already knew what they wanted and now just looked for a criteria on finding out the "perfect" c++ guy. Well the reason I am quoting Joel is a) he's basically always right :-) b) he shows the necessity of "getting things done". I think the latest OO-knowledge is NOT critical to getting things done - in essence if any OO-Wizardry does not reflect real life, you might be in trouble with the hired OO-Wizard. Of course, a lot of people get things done _and_ are OO-wizards. But getting things done nearlly always means a compromise - and this is sometimes opposite to the latest OO-Talk. Doesn't have too, but to me it seems so. Programs were shipped in time prior to the invention of UML/Objectory/whatever, and they were OO. MFC is just another one of those examples. Practical, but not high-end science. Or consider templates (as described in Modern c++ design). Hey, I wanted portable strings and containers, _not_ a new paradigm of programming. And the list goes on. I hope the original poster gets their Wiz and that guy gets things done :) ______________________________ Java: The living proof Moore's law won't solve all your problems
-
joshfl wrote: lol Now I'm confused. Why was on of my serious posts "lol" worthy, over the many other ones where I'm intentionally funny? :-D -- Ian Darling "The moral of the story is that with a contrived example, you can prove anything." - Joel Spolsky
-
"Can do, will do" rather than "Yeah, sure" ? The tigress is here :-D
Trollslayer wrote: "Can do, will do" rather than "Yeah, sure" ? Yeah, sure. :-) -- Ian Darling "The moral of the story is that with a contrived example, you can prove anything." - Joel Spolsky
-
Marc Clifton wrote: You're kidding! Those were basic OOP subjects! Really? I would not be able to answar a lot of them... Are you by that saying that I'm a bad programmer, and that I know nothing about OOP? - Anders Money talks, but all mine ever says is "Goodbye!" My Photos[^] nsms@spyf.dk <- Spam Collecting ;)
Really? Really, those are basic C++ OOP topics. Are you by that saying that I'm a bad programmer, and that I know nothing about OOP? I don't think he said that... although it sounds like you could use a new C++ OOP book. Good luck! :)
-
UML you can throw out the window, IMHO. It's big, bloated, and to get real functionality, like reverse engineering, you have to pay big bucks. I think there's a couple good freeware exceptions, however. As for design patterns, you probably already use them. The biggest thing about DP's is that it formalizes certain common OO architectures and gives them nerdy sounding names so that geeks can talk and sound like they're getting something done. Marc Latest AAL Article My blog Join my forum!
I agree. I have used UML and have generally found that after a short span of time, it starts to get in the way. As for Design Patterns, I happen to think that knowledge of how to properly use them is very important *if* you are espousing the benefits of OO. Used and understood properly, patterns make you very productive. Well, I think so ... :) I bet if people checked out this site they'd find they are using patterns already. They key though is to *know* that you are using them, and how and why/where.