Interview questions - best way to learn the answers
-
Member 2941392 wrote:
Sorry to say, but I can remember all those definitions. Furthermore, teams I have worked with know what patterns are, and do talk about them occasionally.
Then presumably you are capable of teaching someone, on those rare occasions when it seems relevant because it did come up in a conversation. Which would certainly be more than enough in almost all situations where it is actually important.
Member 2941392 wrote:
Knowing what things are called is the first step in being able to communicate about them. It means you understand the nugget of information and can abstract it mentally and look at it and think about it.
One can only wonder then how did people discuss pattern implementation before the work 'pattern' was used to encapsulate it? Since all of the patterns in the GoF book, by definition, existed before the book how exactly are you proposing that they were used and understood?
Member 2941392 wrote:
There is an actual difference between being able to write a virtual function and knowning what polymorphism is.
And yet I have been using virtual functions for more than 25 years and yet have very, very seldom ever felt a need much less a requirement to classify a difference specific to "polymorphism." I have also had many conversations about virtual functions and almost none that mentioned polymorphism.
Member 2941392 wrote:
When I am a hiring manager, I look for this difference in a senior person, because not everybody gets it.
Myself I understand that my skill in programming is unlikely to translate into communication skills much less people skills. And that is very likely true for other programmers, regardless of their skill level.
Member 2941392 wrote:
My advice to you is, if you can't remember what (for instance) polymorphism is, then your training is not complete. You need to study oo design, not just memorize definitions. It's not just for interviewing, but for the good of your whole career.
I am quite certain that someone could have an incredible career without know an exact definition for polymorphism, not even really knowing what it means and most certainly without the ability to spew it out at a moments notice at the whim of any random interviewer who thinks
Ooh, wow. It almost soundslike somebody defending ignorance. I'm sure you can have a fine career and make many dollars without being able to communicate. I'm also pretty sure that people (unless they have a brain injury) can remember the words that name concepts that they understand. Your inability to remember the word probably indicates you don't grasp the concept. I hope you can have a fine career and make many dollars without understanding polymorphism or any other concept. I'm sure there will always be folks around with CS degrees and years of experience who can explain the concepts to you again and again, so that you need never internalize them. You're right. What bearing could understanding software concepts possibly have on writing programs? Only an idiot would interview for such knowledge! As for patterns, the whole point of the design pattern movement is to give patterns names so you can speak about them and remember them. While the patterns existed before they had names, many programmers, even experienced ones, weren't aware of using them. They developed the same things over and over again from first principles. They often made mistakes (google "Double checked locking" or "singleton" for examples). By naming and providing standard descriptions of patterns, you can talk about or code them by reference to a body of written-down knowledge. This is all in the introduction to the GoF book. A lot of less experienced, self-taught developers figure they're so smart they can program rings around their peers even if they have always to work from first principles. A lot of experienced devs know that nobody is that smart.
-
Eddy Vluggen wrote:
You don't have to answer everything correctly, you're not Google and no-one will be expecting that you can rehash all your studybooks. You will be judged on how you react when confronted with something that's not in your short-term memory. Will you propose to further investigate, or would you become angry?
That is idealistic. There is no reason to believe that programmers as a group have anything but average interview skills. At best.
jschell wrote:
That is idealistic.
Yes. Did I set the bar too high?
jschell wrote:
There is no reason to believe that programmers as a group have anything but average interview skills. At best.
He needs to stand out from the other solicitors :) "Programmers as a group" is a very broad public, with a lot of variation in skills. You don't need to encourage someone who loves to code to learn a language or a definition, they'll do that anyway.
I are Troll :suss:
-
That is my stock answer when anyone asks me about polymorphisms. Some get it, and smile, and some just don't. If they give me a strange look I explain about parameters types, method signatures, and such.
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
I use polymorphism all the time (as I imagine we all do) yet the word is too abstract (no pun intended) for me to spit out a concise definition on demand, but if you want me to describe how inheritance can be used to change the behavior based on type, I can do that readily. On the other hand, I have a friend who can wax eloquently on polymorphism for hours but couldn't explain type inheritance. He lives in a much more abstract world than me, while I live in a rather more concrete world. We have great discussions, because I can take his abstractions and put them into some really interesting implementation, and when I talk to him about implementation, he often points me to new ideas in abstraction. The point being, I don't really think it's a lack of understanding that I can't spit out the definition of polymorphism, it's more related to what domain (that word again) I live in and where I choose to focus my attention. Most IT techy-words I basically just bleep over, like Linus reading War and Peace, because I don't connect to abstract terms. Maybe I should have taken Latin in school. ;) Marc
In a recent job interview I was asked what polymorphism meant. I explained that when refrerring to software the term is the exact opposite of the proper meaning. Polymorphism traditionally means a thing that has different outward appearances -- a compound with different crystal structures or a species with different forms (the only example I can think of is a tadpole and frog). In software design it seems to mean different things that have the same outward appearance (interface). Anyway, I didn't get the job. BTW, Marc your articles on CP inspired me to write one - http://www.codeproject.com/KB/architecture/develmethodologies1.aspx.
Andrew Phillips http://www.hexedit.com andrew @ hexedit.com
-
I consider myself a good developer, fellow developers and managers as well as clients have told me the same. I code to standards and make sure it is done correctly. So why is it that in an interview when asked a question about code I get stumped and not able to answer it correctly? Am I the only one that does this? Can you BE a great developer without being able to tell you the definition of polymorphism or the like? I know I can do the work, very well. So what can I do to learn the definitions of things? I am thinking of making cue cards and going from there. They have helped me in the past. What do you think? What is the best way for you to learn? Also, do you know definitions and meanings of everything you do? Thanks
i feel the same
manoj sharma 09911087802 manoj.great@yahoo.com
-
In a recent job interview I was asked what polymorphism meant. I explained that when refrerring to software the term is the exact opposite of the proper meaning. Polymorphism traditionally means a thing that has different outward appearances -- a compound with different crystal structures or a species with different forms (the only example I can think of is a tadpole and frog). In software design it seems to mean different things that have the same outward appearance (interface). Anyway, I didn't get the job. BTW, Marc your articles on CP inspired me to write one - http://www.codeproject.com/KB/architecture/develmethodologies1.aspx.
Andrew Phillips http://www.hexedit.com andrew @ hexedit.com
Andrew Phillips wrote:
I explained that when refrerring to software the term is the exact opposite of the proper meaning.
Outstanding! I will have to use that, I always had an issue with that word, now I know why!
Andrew Phillips wrote:
BTW, Marc your articles on CP inspired me to write one -
I just scanned it, it's great! Gave you a five, I really like the simplicity of your analogy. One comment though, I was disappointed that you didn't write more about Iterative development, as that is actually the form that I find works best and so therefore I have a deeper personal investment in. :) If you're interested, I could write you up a couple paragraphs on how I found it to work, and its strengths and weaknesses, that you could then add to the article. Marc
-
>The way I see it, you learn karate so you need never use it. Wow, what a bad analogy :-)
-
c2423 wrote:
My speciality
lol, usually I just say "Learn how I write code - it might not teach you the right way, but at least you've eliminated one option."
-
>And yet I have been using virtual functions for more than 25 years and yet have very, very seldom ever felt a need much less a requirement >to classify a difference specific to "polymorphism." I've been using pencils for 40 years, but that doesn't make me an artist. Whether or not you're a good OO programmer doesn't have much to do with how long you've been "using" virtual functions, it has more to do with how well you understand OO programming. >I have also had many conversations about virtual functions and almost none that mentioned polymorphism. I have had many conversations about gas mileage, and none of them mentioned internal combustion. If I were speaking to my mechanic, I would not expect him to mention internal combustion. If I owned a car shop and were interviewing a mechanic, I would expect him to know what internal combustion was. If I'm speaking to my programming peers, we all know we know polymorphism because of implicit combination of phrases like "virtual", "at runtime", "inheritance", "type conversion", etc. But of course every one of us can "spew it out" at a random moment's notice if necessary if asked the definition. >Myself I understand that my skill in programming is unlikely to translate into communication skills much less people skills. Since the OP mentioned an interview, I'm assuming we're talking about the whole package here - software development in a team environment. Programming is a big part of that, but not all. If your "skill" is unlikely to translate into communication of your ideas, or people skills, you're much less likely to be a successful software developer. >I am quite certain that someone could have an incredible career without know an exact definition for polymorphism The first person to mention "exact definition" in this thread, I think, is you. >not even really knowing what it means and most certainly without the ability to spew it out at a moments notice at the whim of any random >interviewer who thinks term definition is actually objectively significant. "Spew" it out? Getting a little sarcastic, aren't we? "Random" interviewer, or the specific one that can grant you the job at the company you want? I find your arguments a little silly. If you called yourself an OO programmer and yet could not provide me with a basic explanation of polymorphism, you certainly wouldn't get a job at any company I've ever worked at. This is not rocket science, and it's not irrelevent academia or trivia. It's a fundamental concept of OO programming.
Jeff Connelly wrote:
I've been using pencils for 40 years, but that doesn't make me an artist.
Analogy does not apply. A better analogy would be that you are claiming that someone will be a better artist simply because they know that the 'H' in 4H means hardness rather than whether they can choose to use 4H versus 3B effectively.
Jeff Connelly wrote:
Whether or not you're a good OO programmer doesn't have much to do with how long you've been "using" virtual functions, it has more to do with how well you understand OO programming.
Which has nothing to do with term definition.
Jeff Connelly wrote:
I have had many conversations about gas mileage, and none of them mentioned internal combustion.
Analogy does not apply at all.
Jeff Connelly wrote:
If I'm speaking to my programming peers, we all know we know polymorphism because of implicit combination of phrases like "virtual", "at runtime", "inheritance", "type conversion", etc. But of course every one of us can "spew it out" at a random moment's notice if necessary if asked the definition.
Then this should be an easy question for you and for every one in this knowledgable group that you claim knows the definition. Which authorative source would you all immediately point to as the single and only definition for the term?
Jeff Connelly wrote:
Since the OP mentioned an interview, I'm assuming we're talking about the whole package here - software development in a team environment. Programming is a big part of that, but not all. If your "skill" is unlikely to translate into communication of your ideas, or people skills, you're much less likely to be a successful software developer.
Which has nothing to do with interview skills. An analogy back at you... The fact that I can hold a conversation around the water cooler doesn't mean that I am the best candidate or even an adequate candidate to attempt to close a 100 million dollar deal. Or even a 100,000 thousand dollar deal.
Jeff Connelly wrote:
If you called yourself an OO programmer and yet could not provide me with a basic explanation of polymorphism, you certainly wouldn't get a job at any company I've ever worked at.
For the p
-
Ooh, wow. It almost soundslike somebody defending ignorance. I'm sure you can have a fine career and make many dollars without being able to communicate. I'm also pretty sure that people (unless they have a brain injury) can remember the words that name concepts that they understand. Your inability to remember the word probably indicates you don't grasp the concept. I hope you can have a fine career and make many dollars without understanding polymorphism or any other concept. I'm sure there will always be folks around with CS degrees and years of experience who can explain the concepts to you again and again, so that you need never internalize them. You're right. What bearing could understanding software concepts possibly have on writing programs? Only an idiot would interview for such knowledge! As for patterns, the whole point of the design pattern movement is to give patterns names so you can speak about them and remember them. While the patterns existed before they had names, many programmers, even experienced ones, weren't aware of using them. They developed the same things over and over again from first principles. They often made mistakes (google "Double checked locking" or "singleton" for examples). By naming and providing standard descriptions of patterns, you can talk about or code them by reference to a body of written-down knowledge. This is all in the introduction to the GoF book. A lot of less experienced, self-taught developers figure they're so smart they can program rings around their peers even if they have always to work from first principles. A lot of experienced devs know that nobody is that smart.
<blockquote class="FQ"><div class="FQA">Member 2941392 wrote:</div> I hope you can have a fine career and make many dollars without understanding polymorphism or any other concept. I'm sure there will always be folks around with CS degrees and years of experience who can explain the concepts to you </blockquote> At this point I can only suppose that you do not understand the difference between term definition and concept understanding.
Member 2941392 wrote:
As for patterns, the whole point of the design pattern movement is to give patterns names so you can speak about them and remember them. While the patterns existed before they had names, many programmers, even experienced ones, weren't aware of using them. They developed the same things over and over again from first principles. They often made mistakes (google "Double checked locking" or "singleton" for examples). By naming and providing standard descriptions of patterns, you can talk about or code them by reference to a body of written-down knowledge. This is all in the introduction to the GoF book. A lot of less experienced, self-taught developers figure they're so smart they can program rings around their peers even if they have always to work from first principles. A lot of experienced devs know that nobody is that smart.
By definition and even as you mentioned, patterns are not based on term knowledge but on concepts. The fact that I can spew out the intent of Facade doesn't matter if I do not in fact know when to use and when not to use it. However if I do in fact know when to use and not use a Proxy but I mistakenly call it Facade for years and be very successful. And there are in fact interviewers that will mark someone down for failing to give the correct definition while completely ignoring the fact that the definition is correct for another term. And that is a failure on the part of the interviewer.
-
jschell wrote:
That is idealistic.
Yes. Did I set the bar too high?
jschell wrote:
There is no reason to believe that programmers as a group have anything but average interview skills. At best.
He needs to stand out from the other solicitors :) "Programmers as a group" is a very broad public, with a lot of variation in skills. You don't need to encourage someone who loves to code to learn a language or a definition, they'll do that anyway.
I are Troll :suss:
Eddy Vluggen wrote:
You don't need to encourage someone who loves to code to learn a language or a definition, they'll do that anyway.
I see no reason to expect that individuals in that group will learn to excel in communication and interview skills. Since they are in fact spending their time learning other skills. Nor is there any reason to believe that they will come to realize that their knowledge, in terms of human communication, will not match their (presumed) skills in programming. Thus there it is to some degree more likely that they will deem failure to 'correctly' define a term to indicate a failure in skill. While disregarding their own skill failure in correctly determining commnication problems (others as well as their own.)
-
Eddy Vluggen wrote:
You don't need to encourage someone who loves to code to learn a language or a definition, they'll do that anyway.
I see no reason to expect that individuals in that group will learn to excel in communication and interview skills. Since they are in fact spending their time learning other skills. Nor is there any reason to believe that they will come to realize that their knowledge, in terms of human communication, will not match their (presumed) skills in programming. Thus there it is to some degree more likely that they will deem failure to 'correctly' define a term to indicate a failure in skill. While disregarding their own skill failure in correctly determining commnication problems (others as well as their own.)
jschell wrote:
I see no reason to expect that individuals in that group will learn to excel in communication and interview skills.
Depends on the group. If it's a group o' students, in The Netherlands, learning "Information and Communication Science", learning for their masters' - then I expect them to be experts. And not only in intermachine or interhuman communication :)
jschell wrote:
Nor is there any reason to believe that they will come to realize that their knowledge, in terms of human communication, will not match their (presumed) skills in programming.
Your eloquence is hiding the message. I have reason to believe that any person learning a trade will focus on that trade, and I have reasons to believe that they're taught to reflect on their own skills. Yes, I might have put the bar high, but there's a very large pool to choose from. I wouldn't wanna hire someone who goes to this site after his first assignment and posts "Hej, I need medication-managmement app, PlZ SeNd M3 CoD3z".
I are Troll :suss:
-
Jeff Connelly wrote:
I've been using pencils for 40 years, but that doesn't make me an artist.
Analogy does not apply. A better analogy would be that you are claiming that someone will be a better artist simply because they know that the 'H' in 4H means hardness rather than whether they can choose to use 4H versus 3B effectively.
Jeff Connelly wrote:
Whether or not you're a good OO programmer doesn't have much to do with how long you've been "using" virtual functions, it has more to do with how well you understand OO programming.
Which has nothing to do with term definition.
Jeff Connelly wrote:
I have had many conversations about gas mileage, and none of them mentioned internal combustion.
Analogy does not apply at all.
Jeff Connelly wrote:
If I'm speaking to my programming peers, we all know we know polymorphism because of implicit combination of phrases like "virtual", "at runtime", "inheritance", "type conversion", etc. But of course every one of us can "spew it out" at a random moment's notice if necessary if asked the definition.
Then this should be an easy question for you and for every one in this knowledgable group that you claim knows the definition. Which authorative source would you all immediately point to as the single and only definition for the term?
Jeff Connelly wrote:
Since the OP mentioned an interview, I'm assuming we're talking about the whole package here - software development in a team environment. Programming is a big part of that, but not all. If your "skill" is unlikely to translate into communication of your ideas, or people skills, you're much less likely to be a successful software developer.
Which has nothing to do with interview skills. An analogy back at you... The fact that I can hold a conversation around the water cooler doesn't mean that I am the best candidate or even an adequate candidate to attempt to close a 100 million dollar deal. Or even a 100,000 thousand dollar deal.
Jeff Connelly wrote:
If you called yourself an OO programmer and yet could not provide me with a basic explanation of polymorphism, you certainly wouldn't get a job at any company I've ever worked at.
For the p
jschell wrote:
I've been using pencils for 40 years, but that doesn't make me an artist. Analogy does not apply.
That was pretty much my point.
jschell wrote:
I have had many conversations about gas mileage, and none of them mentioned internal combustion. Analogy does not apply at all.
Actually, it does, pretty well.
jschell wrote:
Which authorative source would you all immediately point to as the single and only definition for the term?
No one has mentioned anything about a "single and only definition". That's not the point - at all.
jschell wrote:
Since the OP mentioned an interview, I'm assuming we're talking about the whole package here - software development in a team environment. Programming is a big part of that, but not all. If your "skill" is unlikely to translate into communication of your ideas, or people skills, you're much less likely to be a successful software developer. Which has nothing to do with interview skills.
It has everything to do with interview skills.
jschell wrote:
It's a fundamental concept of OO programming. If you're not into OO, then fine. If you are, then you better know what it means. Wrong.
What I wrote was correct. You're being petty and argumentative.
-
<blockquote class="FQ"><div class="FQA">Member 2941392 wrote:</div> I hope you can have a fine career and make many dollars without understanding polymorphism or any other concept. I'm sure there will always be folks around with CS degrees and years of experience who can explain the concepts to you </blockquote> At this point I can only suppose that you do not understand the difference between term definition and concept understanding.
Member 2941392 wrote:
As for patterns, the whole point of the design pattern movement is to give patterns names so you can speak about them and remember them. While the patterns existed before they had names, many programmers, even experienced ones, weren't aware of using them. They developed the same things over and over again from first principles. They often made mistakes (google "Double checked locking" or "singleton" for examples). By naming and providing standard descriptions of patterns, you can talk about or code them by reference to a body of written-down knowledge. This is all in the introduction to the GoF book. A lot of less experienced, self-taught developers figure they're so smart they can program rings around their peers even if they have always to work from first principles. A lot of experienced devs know that nobody is that smart.
By definition and even as you mentioned, patterns are not based on term knowledge but on concepts. The fact that I can spew out the intent of Facade doesn't matter if I do not in fact know when to use and when not to use it. However if I do in fact know when to use and not use a Proxy but I mistakenly call it Facade for years and be very successful. And there are in fact interviewers that will mark someone down for failing to give the correct definition while completely ignoring the fact that the definition is correct for another term. And that is a failure on the part of the interviewer.
jschell wrote:
And there are in fact interviewers that will mark someone down for failing to give the correct definition while completely ignoring the fact that the definition is correct for another term. And that is a failure on the part of the interviewer.
Wow. All I can say is good luck to all who subscribe to your interview strategy, because they'll need lots of it!
-
jschell wrote:
And there are in fact interviewers that will mark someone down for failing to give the correct definition while completely ignoring the fact that the definition is correct for another term. And that is a failure on the part of the interviewer.
Wow. All I can say is good luck to all who subscribe to your interview strategy, because they'll need lots of it!
Jeff Connelly wrote:
All I can say is good luck to all who subscribe to your interview strategy, because they'll need lots of it!
All I can say is good luck to those that think their adhoc "strategies" for interviewing candidates will lead any more objective results than any other strategy.
-
jschell wrote:
I've been using pencils for 40 years, but that doesn't make me an artist. Analogy does not apply.
That was pretty much my point.
jschell wrote:
I have had many conversations about gas mileage, and none of them mentioned internal combustion. Analogy does not apply at all.
Actually, it does, pretty well.
jschell wrote:
Which authorative source would you all immediately point to as the single and only definition for the term?
No one has mentioned anything about a "single and only definition". That's not the point - at all.
jschell wrote:
Since the OP mentioned an interview, I'm assuming we're talking about the whole package here - software development in a team environment. Programming is a big part of that, but not all. If your "skill" is unlikely to translate into communication of your ideas, or people skills, you're much less likely to be a successful software developer. Which has nothing to do with interview skills.
It has everything to do with interview skills.
jschell wrote:
It's a fundamental concept of OO programming. If you're not into OO, then fine. If you are, then you better know what it means. Wrong.
What I wrote was correct. You're being petty and argumentative.
Jeff Connelly wrote:
No one has mentioned anything about a "single and only definition". That's not the point - at all.
It is the point because some interviewers will in fact be looking for a specific definition.
Jeff Connelly wrote:
It has everything to do with interview skills.
The ability to interact successfully with other team members does not mean that you will be a good interviewer. Sales people interact with people. Managers interact with people. That doesn't mean that a sale person will be a good manager.
Jeff Connelly wrote:
What I wrote was correct.
The fact that it is fundamental concept of an OO language, does not mean that it will fundamentally impact the success of a programmer. There will be good programmers who cannot verbally express what it means. There will be bad programmers that can provide an exact definition.
-
Jeff Connelly wrote:
All I can say is good luck to all who subscribe to your interview strategy, because they'll need lots of it!
All I can say is good luck to those that think their adhoc "strategies" for interviewing candidates will lead any more objective results than any other strategy.
jschell wrote:
All I can say is good luck to those that think their adhoc "strategies" for interviewing candidates will lead any more objective results than any other strategy.
Well, asking an OO programmer to explain what polymorphism, or any other fundamental concept, means would hardly make for an "adhoc strategy". But that's beside the point anyway. The point of this thread was to look at it from the interviewee's point of view. And for any experienced programmers to reply here, it would be irresponsible for us to say anything other than "yes, you should be able to give the meaning of basic OO concepts."
-
Jeff Connelly wrote:
No one has mentioned anything about a "single and only definition". That's not the point - at all.
It is the point because some interviewers will in fact be looking for a specific definition.
Jeff Connelly wrote:
It has everything to do with interview skills.
The ability to interact successfully with other team members does not mean that you will be a good interviewer. Sales people interact with people. Managers interact with people. That doesn't mean that a sale person will be a good manager.
Jeff Connelly wrote:
What I wrote was correct.
The fact that it is fundamental concept of an OO language, does not mean that it will fundamentally impact the success of a programmer. There will be good programmers who cannot verbally express what it means. There will be bad programmers that can provide an exact definition.
jschell wrote:
No one has mentioned anything about a "single and only definition". That's not the point - at all. It is the point because some interviewers will in fact be looking for a specific definition.
Maybe they will and maybe they won't, but you're the only one who's mentioned that so far. You're just trying to argue silly details. The point remains, an interviewee should know what basic OO concepts mean. <blockquote class="FQ"><div class="FQA">jschell wrote:</div>It has everything to do with interview skills. The ability to interact successfully with other team members does not mean that you will be a good interviewer.</blockquote> We were talking primarily about communication. You are leaving things out to suit your need to argue about this, and it's getting tiresome. <blockquote class="FQ"><div class="FQA">jschell wrote:</div>The fact that it is fundamental concept of an OO language, does not mean that it will fundamentally impact the success of a programmer. There will be good programmers who cannot verbally express what it means. There will be bad programmers that can provide an exact definition.</blockquote> Polymorphism is not a fundamental concept of a language, it's a fundamental concept of OO programming and design in general. I know no good OO programmers who cannot express what it means. The bad programmers I've known are confused about it and therefore cannot express what it means. Again, the OP did not mention "exact definition", you did. An exact definition is not the issue, nor are your other additions or changes of the topic to suit your argument.
-
jschell wrote:
No one has mentioned anything about a "single and only definition". That's not the point - at all. It is the point because some interviewers will in fact be looking for a specific definition.
Maybe they will and maybe they won't, but you're the only one who's mentioned that so far. You're just trying to argue silly details. The point remains, an interviewee should know what basic OO concepts mean. <blockquote class="FQ"><div class="FQA">jschell wrote:</div>It has everything to do with interview skills. The ability to interact successfully with other team members does not mean that you will be a good interviewer.</blockquote> We were talking primarily about communication. You are leaving things out to suit your need to argue about this, and it's getting tiresome. <blockquote class="FQ"><div class="FQA">jschell wrote:</div>The fact that it is fundamental concept of an OO language, does not mean that it will fundamentally impact the success of a programmer. There will be good programmers who cannot verbally express what it means. There will be bad programmers that can provide an exact definition.</blockquote> Polymorphism is not a fundamental concept of a language, it's a fundamental concept of OO programming and design in general. I know no good OO programmers who cannot express what it means. The bad programmers I've known are confused about it and therefore cannot express what it means. Again, the OP did not mention "exact definition", you did. An exact definition is not the issue, nor are your other additions or changes of the topic to suit your argument.
Jeff Connelly wrote:
Maybe they will and maybe they won't, but you're the only one who's mentioned that so far. You're just trying to argue silly details. The point remains, an interviewee should know what basic OO concepts mean.
Since I have been in interviews (plural) where it became obvious that the interviewer was looking for very exact answers it certainly seems relevant to me. I am also had conversations with peers that suggested the same as well when they interviewed.
Jeff Connelly wrote:
We were talking primarily about communication. You are leaving things out to suit your need to argue about this, and it's getting tiresome.
Since the topic is about "interview questions" it would seem relevant to me that interviews, and not just communication skills, would be relevant to the discussion. <blockquote class="FQ"><div class="FQA">Jeff Connelly wrote:</div>Polymorphism is not a fundamental concept of a language, it's a fundamental concept of OO programming and design in general. I know no good OO programmers who cannot express what it means. The bad programmers I've known are confused about it and therefore cannot express what it means. Again, the OP did not mention "exact definition", you did. An exact definition is not the issue, nor are your other additions or changes of the topic to suit your argument.</blockquote> Let me restate what I said. 1. Programming skill level does not equate to communication skill level. 2. Communication skill level does not equate to interview skills. But certainly more likely relevant than programming skill. 3. The ability to successfully interview a candidate is based on the ability to recognize that individuals do have different ways of communicating. None of that has anything to do with programming. 4. Some programmers are adamant about specific definitions and terms (you would certainly seem like an example of this.) Attempting to sum ALL of the above together into a interview philosophy without understanding all of the above means that skilled programmers go into interviews often ill-prepared for the interview process. And this is based on both my experience with being interviewed and participating in interviews with other programmers and listening to their discussions afterwards. The fact that I have known many skilled programmers and very few skilled interviewers and even fewer (probably zero) that did anyt
-
Jeff Connelly wrote:
Maybe they will and maybe they won't, but you're the only one who's mentioned that so far. You're just trying to argue silly details. The point remains, an interviewee should know what basic OO concepts mean.
Since I have been in interviews (plural) where it became obvious that the interviewer was looking for very exact answers it certainly seems relevant to me. I am also had conversations with peers that suggested the same as well when they interviewed.
Jeff Connelly wrote:
We were talking primarily about communication. You are leaving things out to suit your need to argue about this, and it's getting tiresome.
Since the topic is about "interview questions" it would seem relevant to me that interviews, and not just communication skills, would be relevant to the discussion. <blockquote class="FQ"><div class="FQA">Jeff Connelly wrote:</div>Polymorphism is not a fundamental concept of a language, it's a fundamental concept of OO programming and design in general. I know no good OO programmers who cannot express what it means. The bad programmers I've known are confused about it and therefore cannot express what it means. Again, the OP did not mention "exact definition", you did. An exact definition is not the issue, nor are your other additions or changes of the topic to suit your argument.</blockquote> Let me restate what I said. 1. Programming skill level does not equate to communication skill level. 2. Communication skill level does not equate to interview skills. But certainly more likely relevant than programming skill. 3. The ability to successfully interview a candidate is based on the ability to recognize that individuals do have different ways of communicating. None of that has anything to do with programming. 4. Some programmers are adamant about specific definitions and terms (you would certainly seem like an example of this.) Attempting to sum ALL of the above together into a interview philosophy without understanding all of the above means that skilled programmers go into interviews often ill-prepared for the interview process. And this is based on both my experience with being interviewed and participating in interviews with other programmers and listening to their discussions afterwards. The fact that I have known many skilled programmers and very few skilled interviewers and even fewer (probably zero) that did anyt
jschell wrote:
Since I have been in interviews (plural) where it became obvious that the interviewer was looking for very exact answers it certainly seems relevant to me.
I'm sure we can all agree that interviewers looking for very exact answers is not a good thing. However, there was nothing in the OP's post that suggested this problem, so I don't know why you insist on going down this path.
jschell wrote:
Communication skill level does not equate to interview skills.
I really don't know what you're talking about. It seems intuitively obvious to me that it pretty much does. That is, knowing it and being able to communicate it.
jschell wrote:
Some programmers are adamant about specific definitions and terms (you would certainly seem like an example of this.)
Again, I really don't know what you're talking about. You keep injecting phrases like "adamant about specific definitions and terms", but you are the only person using such phrases. You seem to be inventing them to bolster your point, whatever it is. I said an OOP candidate should be able to explain what polymorphism means. I don't know anyone who disagrees with that statement. You seem to be on some crusade, the point of which I don't understand, unless the point is merely practicing your contradiction skills.
jschell wrote:
I wouldn't even mind seeing some objective data about any profession that supports that certain questions produce more skilled workers.
I once read a web article about a hiring manager who tried to correlate long term performance and success with how someone performed on their interview. The only correlation he could ever find was that those with the shortest commute to work were the best performers. Of course he had no data on candidates who couldn't explain the meanings of basic concepts related to their areas of supposed expertise. Those candidates were never hired to begin with.
modified on Tuesday, November 16, 2010 4:01 PM