Interview questions - best way to learn the answers
-
Well, no, I don't know the definitions of all that I use. But I'm a little stumped by your example. I expected that you were getting some obtuse algorithmic question and you just froze in the headlights for a minute. But I didn't expect you to say something like polymorphism. That's a pretty easy one. So I'm a little confused about your definition of "good" or "great" developer. Unless you're a hardcore assembly language programmer, or you "get things done" without your manager knowing what you're doing and it's all hacks, I'm wondering what kind of things you're programming.
I agree it is pretty easy and although I can explain in general what polymorphism is, the definition itself I didn't know. The interview asked me for the definition and I plainly said that I didn't know the textbook definition, I know what it is thou. Your thoughts are exactly why I posted the question. Would me not knowing how to explain polymorphism really prevent me from being a great developer? In the 13 years I have done this, I have created a wide variety of things used in both windows and web environments. Code reviews tell managers what the code looks like and what it does, all great reviews and never had anyone come off like 'What is this?'. I make sure that my code is written to standard, whether the 'standard' be microsoft standard or the company's way. They do differ at times. But 'hacks' I never do, I know enough to know what is the right way to do it. However, I have had to redo a lot of code that others have done. I think that has become my specialty in this career is the ability to go through anyone's code whether VB or C# and fix the bug or rewrite if needed. That is usually the first thing I have to do when going to a client site and get handed an existing application that is broke. If you would like specifics on the things I have developed I'd be happy to give you a list hehe.
-
The trick there is to avoid YAGNI (You ain't going to need it). Right now I'm in the middle of ripping some code out of a solution that I over-engineered a while back. I'm finding that YAGNI sometimes doesn't go far enough. It kind of suggests, you probably won't need this, but there's no harm in having it. I'm finding cases where YABOWI (You are better off without it). Particularly when you're handing over code to someone for maintenance. Also it's fun to see how much code you can rip out of a solution without the users losing any functionality. -Richard
Hit any user to continue.
Richard A. Dalton wrote:
Also it's fun to see how much code you can rip out of a solution without the users losing any functionality.
Reminds me pulling chips out of HAL in 2001 A Space Odyssey. :) I've found a happy medium in declarative programming, using predominantly XML to describe the "what", and code to describe the "how". But even the how is separated out into a declarative portion, describing the sequence, or flow, so that the actual imperative code becomes small chunks of autonomous behaviors that can be easily tested (well, in theory at least). The end result is really nice, you get a very concise definition of what is necessary, the activities involved in the task, and then the implementors of each activity. And it passes the "if I remove one piece of information, does it actually fail like it should" test, so it demonstrates that nothing superfluous to the task is going on. :-D Marc
-
I agree it is pretty easy and although I can explain in general what polymorphism is, the definition itself I didn't know. The interview asked me for the definition and I plainly said that I didn't know the textbook definition, I know what it is thou. Your thoughts are exactly why I posted the question. Would me not knowing how to explain polymorphism really prevent me from being a great developer? In the 13 years I have done this, I have created a wide variety of things used in both windows and web environments. Code reviews tell managers what the code looks like and what it does, all great reviews and never had anyone come off like 'What is this?'. I make sure that my code is written to standard, whether the 'standard' be microsoft standard or the company's way. They do differ at times. But 'hacks' I never do, I know enough to know what is the right way to do it. However, I have had to redo a lot of code that others have done. I think that has become my specialty in this career is the ability to go through anyone's code whether VB or C# and fix the bug or rewrite if needed. That is usually the first thing I have to do when going to a client site and get handed an existing application that is broke. If you would like specifics on the things I have developed I'd be happy to give you a list hehe.
>I agree it is pretty easy and although I can explain in general what polymorphism is, the definition itself I didn't know. The interview >asked me for the definition and I plainly said that I didn't know the textbook definition, I know what it is thou. Your thoughts are exactly >why I posted the question. Would me not knowing how to explain polymorphism really prevent me from being a great developer? OK I guess we are discussing semantics here. My opinion is if you can explain what it is, then you know the definition - that is your definition. I very much doubt he asked "What is the textbook definition of polymorphism?" If not, then he wants it in your own words. There are some interviewers who are fishing for specific keywords or whatever, and those are the crappy interviewers. Normally they just want to hear you speak intelligently and competently, and that rarely has anything at all to do with textbook definitions, except that you shouldn't say anything that obviously contradicts a textbook definition. If you understand basically what polymorphism is, that would be virtually impossible to do. My guess is you are reading too much into what they are asking you. They just want to know if you're one of those guys who use inheritance to implement composition :-) (As I read recently in a blog, someone said in an interview that you can inherit Car from ParkingGarage, because ParkingGarages hold cars. If you inerherit Cars from Vehicles and give some reasonable answer as to why, you'll do fine on an inheritance question.) If I were asked to give a definition, I would say it's the ability for code to handle objects of different types interchangeably. That works as long as they have some behavior/interface in common that the code expects. I seriously doubt that's the textbook definition because I haven't looked it up, but it shows I have at least a rough understanding of the idea. We can go from there if he wants to delve. One thing to keep in mind is that if the interviewer likes you, he might continue to ask deeper questions to see what he has on his hands. Don't assume that if you get to a question that stumps you, that you've failed. Some candidates might never get to those questions. You might have already gotten past the threshold for "pass" (maybe he's looking for at least a 7 on a scale from 1 to 10). He might just want to know if you're actually an 8, 9 or 10 while he's got you there. So don't panic or get nervous.
-
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
For fun I looked this up on Wikipedia (edited): Polymorphism is the ability of one type, A, to appear as and be used like another type, B. In strongly typed languages, polymorphism usually means that type A somehow derives from type B, or type C implements an interface that represents type B. In weakly typed languages types are implicitly polymorphic. The strongly/weakly typed is good to throw in there - that hadn't occurred to me. Webster's says: the quality or state of existing in or assuming different forms Poly means "multiple", and morph means "form" or "transform" depending on whether it's a noun or verb. If you said "the ability of different types to be used in the same way", that sounds real simple and non-textbookish.
-
For fun I looked this up on Wikipedia (edited): Polymorphism is the ability of one type, A, to appear as and be used like another type, B. In strongly typed languages, polymorphism usually means that type A somehow derives from type B, or type C implements an interface that represents type B. In weakly typed languages types are implicitly polymorphic. The strongly/weakly typed is good to throw in there - that hadn't occurred to me. Webster's says: the quality or state of existing in or assuming different forms Poly means "multiple", and morph means "form" or "transform" depending on whether it's a noun or verb. If you said "the ability of different types to be used in the same way", that sounds real simple and non-textbookish.
The easiest way to explain it for most of us (who see it and use it every day), You create a class. It's type can be: 1.) unique 2.) an inherited (base) class 3.) a collection of either 1 and 2 plus a collection of interfaces In a nutshell this is Polymorphism (being able to reuse code) Example: 1.) public class MyUniqueClass { } 2.) public class MyCustomWebPage: System.Web.UI.Page { //You create a new class, and your inheriting from the base class System.Web.UI.Page (so you can utilize it's properties, methods, these have already been written, so why write them again etc.) } 3.) public class MyIssue : System.ServiceModel.DomainServices.Client.Entity, IEditableObject, INotifyPropertyChanged { //You create a new class, and your inheriting from the base class System.ServiceModel.DomainServices.Client.Entity AND you want to also utilize 2 interfaces, IEditableObject and INotifyPropertyChanged } *Remember you can only inherit 1 base class. BUT you can inherit as many interfaces as you like. This is important and something they will more than likely ask you.* This is often a good trick question they might ask you: "How many bases classes can you inherit from a single class?" Answer: 1 "How many interfaces can you inherit from a single class?" Answer: infinite Also, if you inherit any interfaces, you have to code in their abstract methods (or else you code will not compile - I am sure you have experienced this while coding). This is something they might ask you as well, which would stem a good conversation. -T
modified on Tuesday, November 9, 2010 1:10 PM
-
The easiest way to explain it for most of us (who see it and use it every day), You create a class. It's type can be: 1.) unique 2.) an inherited (base) class 3.) a collection of either 1 and 2 plus a collection of interfaces In a nutshell this is Polymorphism (being able to reuse code) Example: 1.) public class MyUniqueClass { } 2.) public class MyCustomWebPage: System.Web.UI.Page { //You create a new class, and your inheriting from the base class System.Web.UI.Page (so you can utilize it's properties, methods, these have already been written, so why write them again etc.) } 3.) public class MyIssue : System.ServiceModel.DomainServices.Client.Entity, IEditableObject, INotifyPropertyChanged { //You create a new class, and your inheriting from the base class System.ServiceModel.DomainServices.Client.Entity AND you want to also utilize 2 interfaces, IEditableObject and INotifyPropertyChanged } *Remember you can only inherit 1 base class. BUT you can inherit as many interfaces as you like. This is important and something they will more than likely ask you.* This is often a good trick question they might ask you: "How many bases classes can you inherit from a single class?" Answer: 1 "How many interfaces can you inherit from a single class?" Answer: infinite Also, if you inherit any interfaces, you have to code in their abstract methods (or else you code will not compile - I am sure you have experienced this while coding). This is something they might ask you as well, which would stem a good conversation. -T
modified on Tuesday, November 9, 2010 1:10 PM
>You create a class. >It's type can be: >1.) unique >2.) an inherited (base) class >3.) a collection of either 1 and 2 + a collection of interfaces >In a nutshell that is Polymorphism No, it's not. Don't mean to sound harsh, but it's simply not :-) Most definitions of Object Oriented Programming include 3 things 1 - classes/object/encapsulation 2 - inheritance 3 - polymorphism You have simply mentioned inheritance, not explained polymorphism. Polymorphism can not occur until runtime. You can see code that is polymorphic, or you can see code that might potentially be polymorphic, but objects changing forms, or representing different forms at different times, is strictly a dynamic issue. It is how the inherited classes and interfaces are used at runtime that distinguishes polymorphism.
-
>You create a class. >It's type can be: >1.) unique >2.) an inherited (base) class >3.) a collection of either 1 and 2 + a collection of interfaces >In a nutshell that is Polymorphism No, it's not. Don't mean to sound harsh, but it's simply not :-) Most definitions of Object Oriented Programming include 3 things 1 - classes/object/encapsulation 2 - inheritance 3 - polymorphism You have simply mentioned inheritance, not explained polymorphism. Polymorphism can not occur until runtime. You can see code that is polymorphic, or you can see code that might potentially be polymorphic, but objects changing forms, or representing different forms at different times, is strictly a dynamic issue. It is how the inherited classes and interfaces are used at runtime that distinguishes polymorphism.
Through inheritance, a class can be used as more than one type; it can be used as its own type, any base types, or any interface type if it implements interfaces. This is called polymorphism. In C#, every type is polymorphic...has nothing to do with run time, code changing during run time (dll getting dynamically created) is known as "reflection" correct?
-
The easiest way to explain it for most of us (who see it and use it every day), You create a class. It's type can be: 1.) unique 2.) an inherited (base) class 3.) a collection of either 1 and 2 plus a collection of interfaces In a nutshell this is Polymorphism (being able to reuse code) Example: 1.) public class MyUniqueClass { } 2.) public class MyCustomWebPage: System.Web.UI.Page { //You create a new class, and your inheriting from the base class System.Web.UI.Page (so you can utilize it's properties, methods, these have already been written, so why write them again etc.) } 3.) public class MyIssue : System.ServiceModel.DomainServices.Client.Entity, IEditableObject, INotifyPropertyChanged { //You create a new class, and your inheriting from the base class System.ServiceModel.DomainServices.Client.Entity AND you want to also utilize 2 interfaces, IEditableObject and INotifyPropertyChanged } *Remember you can only inherit 1 base class. BUT you can inherit as many interfaces as you like. This is important and something they will more than likely ask you.* This is often a good trick question they might ask you: "How many bases classes can you inherit from a single class?" Answer: 1 "How many interfaces can you inherit from a single class?" Answer: infinite Also, if you inherit any interfaces, you have to code in their abstract methods (or else you code will not compile - I am sure you have experienced this while coding). This is something they might ask you as well, which would stem a good conversation. -T
modified on Tuesday, November 9, 2010 1:10 PM
>Remember you can only inherit 1 base class. BUT you can inherit as many interfaces as you like. This is important and something they will >more than likely ask you.* >This is often a good trick question they might ask you: >"How many bases classes can you inherit from a single class?" >Answer: 1 In OO terms (and especially since you didn't specify a language), this isn't true. Some definitions of OO *require* that multiple inheritance be allowed. (C++ allows it, BTW). Some definitions don't. But simply saying that multiple inheritance isn't allowed doesn't make any sense unless you give more context than you have. C++, Perl, Python and Eiffel support multiple inheritance. C#, Smalltalk, and Java do not. Smalltalk does not support multiple interface inheritance.
-
>Remember you can only inherit 1 base class. BUT you can inherit as many interfaces as you like. This is important and something they will >more than likely ask you.* >This is often a good trick question they might ask you: >"How many bases classes can you inherit from a single class?" >Answer: 1 In OO terms (and especially since you didn't specify a language), this isn't true. Some definitions of OO *require* that multiple inheritance be allowed. (C++ allows it, BTW). Some definitions don't. But simply saying that multiple inheritance isn't allowed doesn't make any sense unless you give more context than you have. C++, Perl, Python and Eiffel support multiple inheritance. C#, Smalltalk, and Java do not. Smalltalk does not support multiple interface inheritance.
-
Through inheritance, a class can be used as more than one type; it can be used as its own type, any base types, or any interface type if it implements interfaces. This is called polymorphism. In C#, every type is polymorphic...has nothing to do with run time, code changing during run time (dll getting dynamically created) is known as "reflection" correct?
>Through inheritance, a class can be used as more than one type The key phrase there is "can be used". You have no "usage" in your example. All you have is inheritance. You don't have polymorphism until the types get used as different types. I know where you got that definition, and typical of Microsoft it is somewhat poorly worded. But technically, because it says "can be used", I wouldn't call it incorrect. But your original "nutshell" definition is incorrect. I'm not giving you a hard time, I just wouldn't want you to answer that way in an interview.
-
>Through inheritance, a class can be used as more than one type The key phrase there is "can be used". You have no "usage" in your example. All you have is inheritance. You don't have polymorphism until the types get used as different types. I know where you got that definition, and typical of Microsoft it is somewhat poorly worded. But technically, because it says "can be used", I wouldn't call it incorrect. But your original "nutshell" definition is incorrect. I'm not giving you a hard time, I just wouldn't want you to answer that way in an interview.
-
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
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. 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. There is an actual difference between being able to write a virtual function and knowning what polymorphism is. When I am a hiring manager, I look for this difference in a senior person, because not everybody gets it. 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.
-
Through inheritance, a class can be used as more than one type; it can be used as its own type, any base types, or any interface type if it implements interfaces. This is called polymorphism. In C#, every type is polymorphic...has nothing to do with run time, code changing during run time (dll getting dynamically created) is known as "reflection" correct?
>code changing during run time (dll getting dynamically created) is known as "reflection" correct? Well, I think you're jumbling several different issues together. Reflection is a different issue. Often, if you're using reflection in .NET, you're doing "anti-OO". You're finding out stuff about the object type when polymorphism would not require you to do that. (DLL creation is a third topic altogether). Here are 2 code snippet examples in C#. The first is an exmaple of polymorphism. The second is an example of using reflection to do a similar thing. abstract class Animal { public virtual void Move( ) { Console.WriteLine("An animal is moving"); } } class Bird : Animal { public override void Move( ) { Console.WriteLine("A bird is flying"); } } class Fish : Animal { public override void Move( ) { Console.WriteLine("A fish is swimming"); } } // An object of type Animal can hold an Animal, Bird or any // other subtype. Classes are static, objects are dynamic, // so using bird1 in this way can be considered polymorphism. Animal bird1 = new Bird(); Fish fish1 = new Fish(); // this by itself is not polymorphism foo(bird1); foo(fish1); void foo( Animal animal ) { animal.Move(); // Polymorphism // Where this goes is dynamically determined at runtime, // and if you only were shown only the foo function, you // could not tell where this goes } Or... // Reflection // You are asking the object to "look at itself" (reflect) to determine // what type it is from its metadata. if (animal.GetType() == typeof(Bird)) { Console.WriteLine("A bird is flying"); } else if (animal.GetType() == typeof(Fish)) { Console.WriteLine("A fish is swimming"); }
-
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
We mentioned earlier interviewers that were fishing for specific answers. Here is one you might run into. For C++ and C#, sometimes they want to hear the word "virtual" when speaking about OO or polymorphism. Because this is the keyword that enables polymorphism. If you do not have the keyword virtual in your code, then you do not have polymorphism. (Some would argue that you could, though, simply by having derived class objects being assigned to base class variables, even if virtual methods are not overridden anywhere. Others would argue that you would have to have polymorphic *behavior*, and that requires overridden methods.) If you see the word virtual, then you know there is at least potential for polymorphism. You would have to inspect the code to see if that method is ever overridden. Polymorphism doesn't necessarily exist simply because of the virtual keyword. In math that's called a "necessary but not sufficent condition". Without the virtual keyword, there's no polymorphism. With it, there might be polymorphism.
-
Chris Losinger wrote:
in my 17 years of programming, i have never had a discussion with a co-worker about a "pattern".
Switch to Java (or SmallTalk if it still exists) and you'll have plenty of such discussions.
Nemanja Trifunovic wrote:
Switch to Java (or SmallTalk if it still exists) and you'll have plenty of such discussions.
Not in my experience. Even on the java forums (the Sun ones) discussion of patterns is low. And even lower still when one removes the questions from inexperienced users.
-
OK, this'll be a little long because this is a huge bug bear of mine. The only reason you can't explain something is that you don't understand it. I have never met anyone who was unable to explain something that they understood. I meet lots of people who think they understand things but can't explain them, and on pressing they discover they don't. I fall into this category myself quite often. I saw this so many times when lecturing. People could give the text book definition of something but couldn't explain it. It's the difference between knowing and understanding. I test knowledge by whether or not someone can "teach" it. So in an interview situation I would ask the person to "teach" me how something works, or why some technique can be handy. Testbook definitions are meaningless in that situation. If you find you are stumped when it comes to explaining polymorphism it's because a) you don't actually understand it and b) while compensating for not understanding it you are getting hung up on the text book definition. For the record, my significant other has exactly the same problem as you, also with Polymorphism funnily enough. Now, you can use techniques in your code without fully understanding them. The hundrends of libraries, tools, frameworks and principles etc that we have to use mean that we spend big chunks of our time using things that we only superficially know (but don't understand). I still need my cheat sheets for a significant number of technologies. And that's fine, it's fine with technologies and tools to not get them on a deep level. If I had someone sitting in front of me who had trouble remembering the exact syntax of how to mock an object using Rhino Mocks, It would be interesting, but I wouldn't care too much. If they couldn't explain in their own words why you would want to mock an object I'd be more concerned. If I had someone sitting in front of me who claimed to be good at OO but who couldn't teach me about polymorphism I'd be very concerned. The best way test whether you understand something is to find someone who doesn't understand it and try to teach them. If you feel you get stuck on Polymorphism then use it. Create a demo and show it to a work colleague. You will feel the click in your head when you move from knowledge to understanding (for me it's "duhn duhn" the sound from Law And Order, it might be different for you). Stick at it, but forget about memorising text books. -Richard
Hit any user to continue.
Richard A. Dalton wrote:
The only reason you can't explain something is that you don't understand it. I have never met anyone who was unable to explain something that they understood. I meet lots of people who think they understand things but can't explain them, and on pressing they discover they don't. ....
However that applies to the interviewer as well. And given that the mostly likely reason that the interviewer is in that position has absolutely nothing to do with their people skills it is probably just as possible that one will end up in a guessing game where one succeeds only by spewing out exactly the right technical term.
-
Swelborn wrote:
So why is it that in an interview when asked a question about code I get stumped and not able to answer it correctly?
That's the way it's set up :)
Swelborn wrote:
Can you BE a great developer without being able to tell you the definition of polymorphism or the like?
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?
Swelborn wrote:
I know I can do the work, very well. So what can I do to learn the definitions of things?
Being able to sum up (correct) definitions doesn't impress me - too many developers who can vaguely tell what's on the stack and what isn't, while not being able to implement basic error-handling. Show me that you understand the definition, I want to make sure that you know what you're doing. And it's a bonus if you have a strategy for the moments that you're confronted with a question/situation that you don't know the answer to.
Swelborn wrote:
What is the best way for you to learn?
To teach :)
Swelborn wrote:
Also, do you know definitions and meanings of everything you do?
Yes/no. Once there's a need to explain something, you'll need to define some things. The most concise explanation is often equal to the definition of a subject.
I are Troll :suss:
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.
-
>code changing during run time (dll getting dynamically created) is known as "reflection" correct? Well, I think you're jumbling several different issues together. Reflection is a different issue. Often, if you're using reflection in .NET, you're doing "anti-OO". You're finding out stuff about the object type when polymorphism would not require you to do that. (DLL creation is a third topic altogether). Here are 2 code snippet examples in C#. The first is an exmaple of polymorphism. The second is an example of using reflection to do a similar thing. abstract class Animal { public virtual void Move( ) { Console.WriteLine("An animal is moving"); } } class Bird : Animal { public override void Move( ) { Console.WriteLine("A bird is flying"); } } class Fish : Animal { public override void Move( ) { Console.WriteLine("A fish is swimming"); } } // An object of type Animal can hold an Animal, Bird or any // other subtype. Classes are static, objects are dynamic, // so using bird1 in this way can be considered polymorphism. Animal bird1 = new Bird(); Fish fish1 = new Fish(); // this by itself is not polymorphism foo(bird1); foo(fish1); void foo( Animal animal ) { animal.Move(); // Polymorphism // Where this goes is dynamically determined at runtime, // and if you only were shown only the foo function, you // could not tell where this goes } Or... // Reflection // You are asking the object to "look at itself" (reflect) to determine // what type it is from its metadata. if (animal.GetType() == typeof(Bird)) { Console.WriteLine("A bird is flying"); } else if (animal.GetType() == typeof(Fish)) { Console.WriteLine("A fish is swimming"); }
-
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. 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. There is an actual difference between being able to write a virtual function and knowning what polymorphism is. When I am a hiring manager, I look for this difference in a senior person, because not everybody gets it. 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.
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
-
Marc Clifton wrote:
Personally, what I find much more difficult, interesting, and useful, is learning the lingo of the domain, be it Wall St. or aeronautics or *cough* the entertainment sector, boatyards, etc.
The way I earn my living, this is essential. I don't suppose I write academic-standard code (but hey, it compiles, runs, and is stable :) ) but when I get a project, the first thing I do is really understand the client's business, to the point where I can sit in a management meeting and understand everything, jargon and all. I also interview all the users who are going to work on the system, because their understanding of the problem is often very different to management's at the fine detail level. This also gives the users some feeling of ownership in the project, and this can be hugely useful further down the road. Oops - wandered off topic there, sorry. :-O
Chris C-B wrote:
but when I get a project, the first thing I do is really understand the client's business, to the point where I can sit in a management meeting and understand everything, jargon and all.
That's ok if the client actually understands their own business. My boss, for example, asked me to create a servicing database for the machines we make, only problem was he doesn't understand how the services are organised in the first place! :doh: And what makes this little tale even better, is the fact that he wanted ME to design the database functionality to model servicing when he can't tell me what procedures are used in the first place. I wouldn't mind if it were a really big company employing 100s of people, but it's not; it's a two man band with 4 staff on the shop floor. Talk about pissing in the wind.
Nobody can get the truth out of me because even I don't know what it is. I keep myself in a constant state of utter confusion. - Col. Flagg