Interview questions - best way to learn the answers
-
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
Todd Smith wrote:
Is polymorphism a pattern though?
No, polymorphism is one of the fundamental forces, but it's not a pattern.
-
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".
Up until we started using MVVM I could also ditto this, now the discussion is how to implement it!
Never underestimate the power of human stupidity RAH
-
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 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
Swelborn wrote:
Can you BE a great developer without being able to tell you the definition of polymorphism or the like?
My favorite definition of polymorphism is that it is a geeky way of saying that different nouns can have the same verb applied to them.
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
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.
-
Swelborn wrote:
Can you BE a great developer without being able to tell you the definition of polymorphism or the like?
Yes. You don't need to know the technical definitions of things to use them well. A lot of "new" design patterns are only things that experienced programmers have been doing for years - it's just that now they have a name.
I agree and the amount of things a developer needs to know is become greater and greater. I have been developing for over 13 years, but I have to admit, I am self taught and only took a few classes in college. So I focused more on the job at hand and what needed to get done so I can complete it. I feel, thanks to being around other great developers, that I write my code the way any true developer would. Never really had any complaints about it. I feel it's time to break out the books and start learning more definitions and what the names are.
-
The best way to learn is by doing. You can't possibly know everything. I found that interviewers are quite happy to look at your code on a laptop, especially if they can watch the code execute. Many times, the fact that they can actually see your code (and see it running) eliminates their feeling that they should test you.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
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.
-
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:
-
Swelborn wrote:
Can you BE a great developer without being able to tell you the definition of polymorphism or the like?
My favorite definition of polymorphism is that it is a geeky way of saying that different nouns can have the same verb applied to them.
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
Chris C-B wrote:
because their understanding of the problem is often very different to management's at the fine detail level.
That is SO true. And not just at the fine detail level, but even the large picture. When there's a difference of perception of the problem at the high level between management and users, that's a huge red flag for me that the project is going to end up in flames--the disconnect that management has with users typically portends that users will not, ultimately, be supportive of the effort. And therefore, my livelihood, haha.
Chris C-B wrote:
This also gives the users some feeling of ownership in the project, and this can be hugely useful further down the road.
Exactly! Marc
Marc Clifton wrote:
When there's a difference of perception of the problem at the high level between management and users, that's a huge red flag for me that the project is going to end up in flames
I agree, a significant problem. However, I learnt a long time ago that if you really want to get something done, then you can't afford to care who gets the credit. When I identify a disconnect between management and staff, I will think hard to come up with a solution. I then have a meeting with the boss-man (usually the MD) and explain the problem, and lead the conversation around to the point where HE comes up with my solution. I then thank him, tell him he's a really smart fellow, and congratulate him on his in-depth knowledge of his business. I try to hide my smirk until I have left the office. :)
-
Thanks for the reply. I have actually offered to bring in a cd with my code on it but the recruiter I was working with went against the idea. But I think its a great idea as well.
No, not just a CD. Nobody in a corporate environment will put an unknown CD into a machine on their network. Take your own notebook.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
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
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.
-
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 pretend I'm explaining it to a clever, but junior developer.
-
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 can so much relate this to me. People who work(/ed) with me appreciate my programming skills but when it comes to answering these jargons, I get stumped too. Thanks for writing this post. I am reading all the replies and hope they would help me a lot. Thanks again! :thumbsup:
..Go Green..
-
Marc Clifton wrote:
When there's a difference of perception of the problem at the high level between management and users, that's a huge red flag for me that the project is going to end up in flames
I agree, a significant problem. However, I learnt a long time ago that if you really want to get something done, then you can't afford to care who gets the credit. When I identify a disconnect between management and staff, I will think hard to come up with a solution. I then have a meeting with the boss-man (usually the MD) and explain the problem, and lead the conversation around to the point where HE comes up with my solution. I then thank him, tell him he's a really smart fellow, and congratulate him on his in-depth knowledge of his business. I try to hide my smirk until I have left the office. :)
Chris C-B wrote:
I learnt a long time ago that if you really want to get something done, then you can't afford to care who gets the credit.
Absolutely! I'm much more interested in the solution than in the ego stroking. Sort of orthogonal though to many people in management, haha.
Chris C-B wrote:
I then thank him, tell him he's a really smart fellow, and congratulate him on his in-depth knowledge of his business.
ROTF! That is the Dale Carnegie way! Marc
-
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.
Richard A. Dalton wrote:
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?
Absolutely, and that is actually what I try to do as much as possible--I discovered early on that coding to solve the domain problem at hand paints oneself into a corner because the problem (and the domain) are constantly changing, sometimes slowly, sometimes rather quickly, and without a certain level of abstraction, the implementation keeps having to be replaced, or worse, patched to handle new conditions. Avoiding that is what I truly view as "agile" programming. :) Marc
-
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
-
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
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
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
