Interview questions - best way to learn the answers
-
AWdrius wrote:
but when working in team you need to know how certain patterns are named to make communication faster and more fluent.
in my 17 years of programming, i have never had a discussion with a co-worker about a "pattern".
In the interview for my first programming job, they asked me if I knew "design patterns". At the time, I had no idea what that phrase meant. So after being hired, I downloaded the original GoF book and started reading. I got about 3 chapters in, flipped through the rest, then deleted it to not waste the 500KB of disk space on such inane blather. Design Patterns are a fancy names for basic algorithms and techniques that should be obvious to anyone who actually understands indirection and a few basic (lists, trees) data structures. What struck me the most was that the authors say this in the first chapter. In fact, the authors actually insult their readers since needing to read the book means they are sub-par programmers to start with. :P This could be because they aren't programmers at all yet (just starting off). But most often in my experience the people who use the names for 'patterns' and harp on the supposed greatness of design patterns simply have no real understanding of what they are doing, and are doubly ignorant in thinking they have reached a professional level of coding. I have unfortunately worked with many of them, and cleaned up their broken, messy, brain damaged code often.
I have nothing against VB or .NET; all Turing-complete languages are respectable. It just seems that some languages attract one echelon of programmers, and other languages attract an entirely different echelon of programmers. :P
-
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
This is probably one of the best threads I've read in a while. I'm glad to know that I'm not the only one out there. I'm a software architect, but I'm also an Infantryman in the Army National Guard. For those of you in foreign countries, this basically means that I am a volunteer military reservist. I've been called up for military duty five times during my programming career. My last deployment was to Iraq. My memory has not been the same since I returned from a one year deployment to Iraq. My programming ability is still there, but I have a hard time some remembering syntax and definitions. I've compensated for this by writing a private blog that functions as a knowledge base. When I do something at work that I know I will have to remember, I write what I did in the blog and save it. Now, this process, or syntax or procedure is in the blog so that I can search for it and find it if I can't remember how I did something. I can't even begin to describe the frustration I encountered when I returned from Iraq and I started interviewing for work. I could not remember the answer basic syntactical questions. I found that drawing my answers on a notepad or a white board before I spoke helped me remember things in interviews sometimes, but many interviewers just found this odd. Usually, other software architects would just look smug as I squirmed in a chair trying to remember how to write a join command in SQL. I knew when to use a join command, but for the life of me, I could not write one from memory. The funny thing is that I could remember high level things just fine. If you asked me a logical programming question, I could describe how I could do something. I could describe how I did things in the past and why. I could tell you the difference between an Interface and an Abstract class and when you would want to use one or the other. I flew through the technical phone screens just fine, but when I was face to face with someone and had to describe how I would access a SQL database, I just couldn't write it without using IntelliSense or Google. My brain just didn't have the words anymore. I'm getting better with remembering syntax. A lot of this comes from me forcing myself to memorize things that I used to be able to remember with ease just a few years ago. The Code Project has helped. I check the Q&A forums once a day to see if I can answer any questions. So no, brother. You are not the only one.
-
Great topic, great debate. Trust me, your not the only person who has developed for 10 years only to get stumped by not preparing for a tech interview! We are cocky, we are arrogant and sometimes we are lazy...hehe A while back I failed epically - same problems you had, guy asked me to define reflection, polymorphism, etc. I had been coding SQL all day and was like....ok I was not prepared for this sorry I fail!! I was expecting question tied to data grids, ajax, add/edit forms, SQL etc - things more relevant to the job I was applying for...go figure! lol! Looking back, I cannot say I blame them for the theoretical questions though. They have no way of knowing how good you are. So these questions stem conversation that can help them determine that. With that being said, all tech interviewers now a days, it seems they are asking the exact same questions for the most part, it's quite humorous actually.... 1.) Polymorphism 2.) Encapsulation 3.) Reflection 4.) Inheritance 5.) String Builder versus String 6.) Static versus non-static (instanced) 7.) Constructor (what is it?) Just brush up on those concepts, like all of us, you use them everyday - just do not talk about them, and you will be fine. :D -T
Excellent reply thank you for the time on this and you are exactly right. The last position I interviewed for had those 7 questions - add to it Immutable - what is it? After asking what immutable was they asked about StringBuilder and String difference. I remember reading about StringBuilder and it had something to do with immutable values or something like that..yea I still need to study up hehe. I always thought instead of the questions about definitions and the like, why don't they just plop a laptop on my lap and give me a technical document with what they want and let me create it. Then I can show them my true skills.
-
mmm.. after all, I'm not alone in this. I have the exact same problem. To make it worse, I get angry, when I cannot able to explain it properly, even though I would have done it correctly. I stopped fighting it. I'm going with the flow... ;-) Whoever gives me job, I take. If they think I don't deserve it because I couldn't explain, then I let it be like that. Do I sound so down....
-
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
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.
-
AWdrius wrote:
but when working in team you need to know how certain patterns are named to make communication faster and more fluent.
in my 17 years of programming, i have never had a discussion with a co-worker about a "pattern".
>in my 17 years of programming, i have never had a discussion with a co-worker about a "pattern". That seems very strange to me.
-
Chris Losinger wrote:
in my 17 years of programming, i have never had a discussion with a co-worker about a "pattern".
Is polymorphism a pattern though? We talk about patterns all the time at work since they are common ways of solving problems. But I doubt any of us could give a text book definition of polymorphism. I know I can't.
Todd Smith
The OP didn't say "textbook definition", he just said being able to provide a definition for something as common as polymorhphism. Honestly, if you can't explain what polymorhphism is or a singleton or a "pattern" for that matter, I really am confused what's going on out there.
-
I don't think you should worry about the definitions. In fact if I asked someone about polymorphism and they answered me: "the ability to manipulate objects of distinct classes using only knowledge of their common properties without regard for their exact class", it would be more of alarm sign to me than anything else. A good answer would be something like: "yeah, that's the fancy word for executing the same code with different types"; if also they mentioned static vs. runtime polymorphism, than I would know they knew what they are talking about.
>A good answer would be something like: "yeah, that's the fancy word for executing the same code with different types"; if also they >mentioned static vs. runtime polymorphism, than I would know they knew what they are talking about. It's hardly a "fancy word", and anyway that's a definition. You might as well call "algorithm" a fancy word. This thread is sounding very odd.
-
This is probably one of the best threads I've read in a while. I'm glad to know that I'm not the only one out there. I'm a software architect, but I'm also an Infantryman in the Army National Guard. For those of you in foreign countries, this basically means that I am a volunteer military reservist. I've been called up for military duty five times during my programming career. My last deployment was to Iraq. My memory has not been the same since I returned from a one year deployment to Iraq. My programming ability is still there, but I have a hard time some remembering syntax and definitions. I've compensated for this by writing a private blog that functions as a knowledge base. When I do something at work that I know I will have to remember, I write what I did in the blog and save it. Now, this process, or syntax or procedure is in the blog so that I can search for it and find it if I can't remember how I did something. I can't even begin to describe the frustration I encountered when I returned from Iraq and I started interviewing for work. I could not remember the answer basic syntactical questions. I found that drawing my answers on a notepad or a white board before I spoke helped me remember things in interviews sometimes, but many interviewers just found this odd. Usually, other software architects would just look smug as I squirmed in a chair trying to remember how to write a join command in SQL. I knew when to use a join command, but for the life of me, I could not write one from memory. The funny thing is that I could remember high level things just fine. If you asked me a logical programming question, I could describe how I could do something. I could describe how I did things in the past and why. I could tell you the difference between an Interface and an Abstract class and when you would want to use one or the other. I flew through the technical phone screens just fine, but when I was face to face with someone and had to describe how I would access a SQL database, I just couldn't write it without using IntelliSense or Google. My brain just didn't have the words anymore. I'm getting better with remembering syntax. A lot of this comes from me forcing myself to memorize things that I used to be able to remember with ease just a few years ago. The Code Project has helped. I check the Q&A forums once a day to see if I can answer any questions. So no, brother. You are not the only one.
First off, thank you for serving as a Reserve. Hoorah! I agree this has been a great discussion and I am so glad I am not alone in this, because to be honest it does feel like everyone has their skills together but me. That was another thing that I could of probably done better, writing on the chalk board pseudo code. The one that stumped me was writing out a recursive function. I failed that one even though I could do it if I had the IDE up. What is it about being in my 'element' that gets my brain working? I made a Word document with about 10 terms that I need to memorize or at least know enough about what it is to describe it in my own words. I have interviews Wednesday and Friday so if I can get them down I am hoping the outcome will be different.
-
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.
After every sentence I felt like saying "exactly". Well said Richard.
-
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
>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. Questionable.
-
Marc Clifton wrote:
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.
That's it in a nutshell, it's where you focus your attention. Programmers work on two levels. On one hand we produce concrete functioning software that contains specific lines of code, classes etc. It's something you can debug through and see the cogs turning. On the other hand we spend a lot of time in our head, as Fred Brook's said we build castles in the air, out of air. To a great extent the design patterns movement emerged to capture this abstract world. There's an old saying that there's no problem that can't be solved with another layer of abstraction. That applies as much to the way you think about programming as it does to the layers of abstraction in your code. When you want to learn something you can do so by learning from real concrete examples. In your words you focus on that domain. Other people like your friend prefer to try and generalise problems and solutions and think about them in more theoretical abstract ways. I think most people are inclined to one camp or the other, but you can get great benefits by forcing yourself to look at the world from the view of the other camp. As a programmer you will find yourself shifting from concrete to abstract in your code constantly, so why not develop that skill and apply it to the way you learn? -Richard
Hit any user to continue.
>That's it in a nutshell, it's where you focus your attention. >Programmers work on two levels. On one hand we produce concrete functioning software that contains specific lines of code, classes etc. I'm not buying it. If you can't explain why this concrete pseudo-snippet works, you don't understand polymorphism or you haven't used it. This sort of thing happens in OO code all the time. Now maybe someone has never programmed in OO, which is fine. Or maybe they have what is called an "object based" system only, which is fine. But in terms of OO programming, the following is not exactly "domain" knowledge or "where I focus my attention". class B : A class C : A A b = new B A c = new C foo(b) foo(c) void foo(A a) ...
-
The way I see it, you learn karate so you need never use it. Learn the patterns because they are conscience raising, but not because they solve all problems magically.
>The way I see it, you learn karate so you need never use it. Wow, what a bad analogy :-)
-
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
anticipate what questions may be asked, so i prepare in advance and get some really good answers put together... i try to do as much research as possible. find out about what sw team i am joining, what they do, what technologies they use, what their strengths and weaknesses may be, and try to find out as much as i can about some of the people i am going to interview with. however, in another life i had to interview someone for a mechanic's position in a coca-cola plant i worked in -- i was a plant engineer before becoming a software engineer.... this guy was facinating to listen to... i asked him to "tell me a story about a time you had to troubleshoot and repair something really significant"... needless to say he recanted a facinating experience he had troubleshooting and repairing an ammonia-based A/C or refrigeration unit that had mechanical controls. the guy was really an instrumentation technician. i always remember sitting down with him, how relaxed he was, and how he was so proud of himself for doing something nobody else in his shop dared to do. he was much younger and less experienced than his colleages. i could identify with his love for troubleshooting and fixing things.... so i too take that same approach if i am ever interviewed... over the years, i like many of you have accumulated many "aaahaaa" moments where you solve some really cool "puzzle"... in fact, sometimes i tell myself afterward in a loud voice ... "dude you are the bomb!"... just remember all those "good times"... and tell them in a very relaxed way... like you are telling a really good [truthful] story... that's really what they want to hear...
David
-
Great topic, great debate. Trust me, your not the only person who has developed for 10 years only to get stumped by not preparing for a tech interview! We are cocky, we are arrogant and sometimes we are lazy...hehe A while back I failed epically - same problems you had, guy asked me to define reflection, polymorphism, etc. I had been coding SQL all day and was like....ok I was not prepared for this sorry I fail!! I was expecting question tied to data grids, ajax, add/edit forms, SQL etc - things more relevant to the job I was applying for...go figure! lol! Looking back, I cannot say I blame them for the theoretical questions though. They have no way of knowing how good you are. So these questions stem conversation that can help them determine that. With that being said, all tech interviewers now a days, it seems they are asking the exact same questions for the most part, it's quite humorous actually.... 1.) Polymorphism 2.) Encapsulation 3.) Reflection 4.) Inheritance 5.) String Builder versus String 6.) Static versus non-static (instanced) 7.) Constructor (what is it?) Just brush up on those concepts, like all of us, you use them everyday - just do not talk about them, and you will be fine. :D -T
>1.) Polymorphism >2.) Encapsulation >3.) Reflection >4.) Inheritance >5.) String Builder versus String >6.) Static versus non-static (instanced) >7.) Constructor (what is it?) OK this is a good example for discussion, because out of those, 5) stands out as the oddball. There are a million items like 5) that a lot of programmers might not know. However the other 6, anyone who calls themselves a professional developer should be able to cobble together some sort of description for (3 might not be OO per se, but anyway...) You need to look at it from a hiring managers point of view. There are TONS of developers out there who are coding really bad OO. And it turns out almost 100% of the time, those are the exact same programmers who don't understand the above concepts. They use inheritance for composition (hey it works, right?) They use static methods and casting when they should use class methods and polymorphism (hey it works, right?) They get programs to function properly, but are actually steaming piles of unmaintainable dog doo. And one of the main reasons is they do not, in fact, understand the above terms. On the other hand, hiring mgrs who ask mostly questions about things like 5) are the ones who don't get it. You can easily put together questions or pieces from a large library (such as .NET) that any particular programmer won't know. (StringBuilder vs String is kind of an easy one, but of course you can get more obscure than that.)
-
Also never forget, you are not powerless in an interview... Imagine being asked for a definition of Polymorphism and beginning your answer with.. "Well there are a few types of polymorphism...In terms of OO programming in .Net it usually means different types of object being able to react to the same messages, by implementing a common interface." Now, some interviewers will put a tick on their sheet and move on to the next question. But some interviewers will pick up on fact that you said there were different types of Polymorphism. And they'll ask you about that. Now a few things have happened. One, you've moved the discussion onto a topic that you know something about (assuming in this case you know something about Polymorphism). Two, you've got the interviewer listening to you and interacting rather than simply reading off questions and hearing pre-fab answers. It might even turn into a lively discussion, and it hammers home the idea that you can hold your own when a discussion goes off script. Finally, you learned something about the interviewer. This is likely to be someone you'll be working with. Will chats with this person be interesting? How do they react if your opinion doesn't match theirs exactly? Always remember, most interviewers desperately want you to be a witty, likeable genius who'll fit right in and be perfect for the role. Also, never forget that you are interviewing them too, in desperation to "Pass" or "Win" the interview some people lose sight of whether the job even sounds right for them. -Rd
Hit any user to continue.
Another good answer. Regarding humor, once I know the interviewer is hearing me and knows that I'm at least competent, I might say something like "for example, sometimes my wife is sweet as honey, and sometimes she's a shrew and I never know which one is going to show up at home each night but I'm always supposed to treat her the same!" That's a pretty reasonable definition of polymorphism, that you couldn't come up with if you didn't understand it. Or if you want a better analogy, talk about customers coming into a store - some are men, some are women, some are nice, some are cranky, yet they all have the same "interface" and you use the same protocal talking to them. Again, the OP never said "textbook definition". We are talking about understanding and explaining - that's what the interview is about.
-
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.