Questions on OOP
-
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.
-
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! :)
Dan Colasanti wrote: I don't think he said that... although it sounds like you could use a new C++ OOP book. Aha, just because I dont use UML and dont know anything about design patterns? Hmmm, I have been programming using OOP in quite a few years now, and I do know what virtual/abstract methods is, and I do know what protected/private/public and all that stuff is and how to use it. Hmmm, I have a nice job, and have had a few other jobs, as a programmer, and I have never ever needed that stuff, why should I start to learn it when I dont need it? - Anders Money talks, but all mine ever says is "Goodbye!" My Photos[^] nsms@spyf.dk <- Spam Collecting ;)
-
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
First I apologize for being so late in re-posting -- I had other fish to fry (well, actually it was fetuccine Alfredo). I don't think your post was off-the-mark at all -- I fully realized that you were quoting, but I was somewhat "fuzzy" on whose opinion you were presenting because I'm new here and I haven't learned all the personalities yet. I said that your response was illuminating and I meant it -- it did cause me to take a long, hard look at myself -- thus, the self-deprecating comment. Several people responding to the original post commented in one way or another about "getting things done," but I gave you credit for noticing the importance of -- err, is it Joel's? -- emphasis. You were the lucky beneficiary of my input because you were the last one to have responded at the moment when I saw fit to put my two cents (do I hear three?) worth in (preposition at the end of a sentence). You might say that I was critiquing "the gist of the list" because so many people were talking about how they didn't think they could pass such a test. Asked about the general topics, I think any "expert" (should we ever find such animal) would be hard put to come up with a meaningful response. You could be the ideal candidate for the job, but if asked a question too general, there would be so many possible answers that the possibility of drowning in the cognitive swamp would be overwhelming in figures alone, let alone the swamp of emotional pressure one feels in an "important" interview. Some people seem to think that overloading candidates is some kind of cute game where the objective is to confound the wisdom of the respondent: I'm pretty sure that the aim is getting someone who can do the job you need to do, to accomplish the aim you want to accomplish. For this reason, I make the remark (based on Joel's comments, not yours) that "guerrilla tactics" should be left to revolutionary armies -- and not directed at people who show up with the essential aim of giving you a hand. Sure, there are some people out there who are solely motivated by the prospect of a paycheck, but when you put out an advertisement that names skills, products and experience, you attract the attention of people who are interested in that particular ad. I don't think it is wise to overblow the competency required for the job, either -- in doing so, you are putting off those who have just enough and maybe not an erg more of the potential to reach your dreams. I'm not saying this to you in particular, but in response to simi
-
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.
Andrew McCarter wrote: 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 agree. I've been immersing myself in DP's for the last month and was rather humbled to discover that I was learning some things about OOD. That site BTW is excellent--I've been using it as a reference for a long time. Marc Latest AAL Article My blog Join my forum!