Are OO skills important when someone has a good technical knowledge
-
Recently I interviewed one guy and found that he is very good in technical stuff. He got a good understanding about C++ and C#. But his OO skills was not up to the level that my company was expecting. He knows and can create classes or interfaces, create good and readable code but he doesn't know to apply design patterns, handling the class responsibilities etc. IMO, OO skills like these can be developed easily when one starts working on projects. Technical knowledge and the willingness to learn matters. What will you do if you were in my position? Do you think advanced OO knowledge is needed to work on a project? Any thoughts?
Navaneeth How to use google | Ask smart questions
Hmm. I'm old enough that my formal academic training predates both object-oriented programming and the notion of design patterns. As I see it, OOP and design patterns formalized and documented practices that more capable and experienced programmers used to develop reliable, maintainable software. I picked up a lot of these practices over the years through solving my own problems and by looking at the code of others. I've seen great object-oriented code written in assembly language. I've seen abominations written in C++ and C# that ostentatiously applied design patterns. I think it's important, perhaps vital, that you understand the ideas behind object-oriented programming and design patterns. Being able to recite pseudo-code for the Observer pattern, or to diagram a design using UML, is less critical.
Software Zen:
delete this; -
Depends on the seniority level at which you are hiring. If he has 1-3 years experience yes definitely hire him 3-5 years experience it is a maybe 5+ years experience then don't hire him also he might not know a pattern by name but he might be able to design something which looks iike one of the pattern or the design is very good. Then definitely hire him. Knowing pattern names only is no qualification.
However - those of us with over 30 years of programming experience - haven't got the the buzz words. I have to bone up on those damn things every time I need to talk to clients. I had no problem learning the OOP style of programming - (I had been trying to program that way for 25 years without the support of the languages) however I had a hard time beating my way through the f...ing terminology. And design patterns ... It is called programming skills.
-
Good one.
Navaneeth How to use google | Ask smart questions
I used to write design patterns without knowing that there was a pattern for that I think you should hire that guy If he is so good, he is not gonna have trouble learning design patterns But if you hire him, you should give him some homework (read the entire Gamma book). You people has no problem if they have to do something for work at home if they think that is a good thing.
Saludos!! ____Juan
-
Use my statement to your boss/management... You can teach a good programmer OO more easily than you can teach someone who knows OO but is a bad programmer to improve their coding... Of course, you could just let it unfold, let them break it, then smugly say "I told you so", but I don't think that will help!
I don't have ADHD, I have ADOS... Attention Deficit oooh SHINY!! Booger Mobile (n) - A bright green 1964 Ford Falcon - our entry into the Camp Quality esCarpade!! Do something wonderful - make a donation to Camp Quality today!!
I couldn't disagree more. There are those who grok OO and those who don't. No matter how much you can teach someone the theory of OO if they don't get it they're never going to apply it well if you force it upon them. This should in no way be taken as a judgement on a person's programming ability, you can write fantastic code in a non-OO manner. It's just a culture thing, and having a few dissenting voices in the team may not be such a bad thing depending on your style. Me? I don't get RDMSs. I can use them well enough, but they always seem somewhat arbitary to me. I don't think I'd get along (coding-wise) with someone who tried to use tables for everything for example.
-
Recently I interviewed one guy and found that he is very good in technical stuff. He got a good understanding about C++ and C#. But his OO skills was not up to the level that my company was expecting. He knows and can create classes or interfaces, create good and readable code but he doesn't know to apply design patterns, handling the class responsibilities etc. IMO, OO skills like these can be developed easily when one starts working on projects. Technical knowledge and the willingness to learn matters. What will you do if you were in my position? Do you think advanced OO knowledge is needed to work on a project? Any thoughts?
Navaneeth How to use google | Ask smart questions
In terms of OO skills, one should be competent at writing classes with a good understanding about OO concepts. However, remember OO is a concept. It is also a concept that has been proven over the years to be an utter failure which SOA has already begun to mimic. OO has not been failure because of what it is but how it has been applied. Its most touted feature has been that of re-use but an in-depth study in this area (Unfortunately, I can't remember the paper...) has demonstrated that re-use after all these years has been dismally, almost nill except at the small group level. Inheritance, which is another touted feature has been touted as the second coming in programming panaceas. Nothing could be further from the truth. Most inheritance hierarchies have been a nightmare to develop and even worse to maintain. It has very little real use in business applications except in specific cases. Ted Patton, of COM\COM+ fame in his second book on the subject described the nightmarish results of the over enthusiastic use of inheritance hierarchies. Most are poorly designed and subsequently produce maintenance fiascoes. Design Patterns are solutions looking for problems. This is not to say they do not serve a purpose but how many people develop projects looking for the proper design pattern to implement first... Not many. Though in some cases it would serve them well if they had. The reason is that design patterns are natural outgrowths as to how most of us as developers think when designing processes. we don't think about using an MVC for example, but many of us implement some level of MVC in many of our projects. Design patterns are best used when used as a guide for particular types of processes but when you start limiting yourself to that type of thought you become very narrowly focused. So how do you look at all this? OO is about one thing only! Organization and encapsulation of both data and logic. This is where OO truly shines way beyond procedural programming. However, it comes at a cost since most OO is not very efficient internally, especially when using polymorphism. It also can lead to as much confusion when written in esoteric fashion as any other programming language construct. I have been in the field over 35 years and still going quite strong at it as a senior software engineer. Everything has its place and its good points but putting too much emphasis on concepts and not enough on the natural abilities of the candidates you interview will have you always looking for the wro
-
However - those of us with over 30 years of programming experience - haven't got the the buzz words. I have to bone up on those damn things every time I need to talk to clients. I had no problem learning the OOP style of programming - (I had been trying to program that way for 25 years without the support of the languages) however I had a hard time beating my way through the f...ing terminology. And design patterns ... It is called programming skills.
LenaBr wrote:
I had no problem learning the OOP style of programming
... and that's what is more important as I said. An experience developer comes up with solutions automatically without reading about them. He may design using IOC pattern without knowing that whatever he designed is called IOC.
-
LenaBr wrote:
I had no problem learning the OOP style of programming
... and that's what is more important as I said. An experience developer comes up with solutions automatically without reading about them. He may design using IOC pattern without knowing that whatever he designed is called IOC.
Rama Krishna Vavilala wrote:
An experience developer comes up with solutions automatically without reading about them. He may design using IOC pattern without knowing that whatever he designed is called IOC.
Somehow, I missed it in your previous post. Now, it all makes perfect sense. :)
It is a crappy thing, but it's life -^ Carlo Pallini
-
Recently I interviewed one guy and found that he is very good in technical stuff. He got a good understanding about C++ and C#. But his OO skills was not up to the level that my company was expecting. He knows and can create classes or interfaces, create good and readable code but he doesn't know to apply design patterns, handling the class responsibilities etc. IMO, OO skills like these can be developed easily when one starts working on projects. Technical knowledge and the willingness to learn matters. What will you do if you were in my position? Do you think advanced OO knowledge is needed to work on a project? Any thoughts?
Navaneeth How to use google | Ask smart questions
He knows how to use interfaces but doesn't understand OOP? I say go for it if he has the experience to back him up. It sounds like you're not looking for a lead programmer, which makes it even more of a moot point. On a side note... When it comes to design patterns, most people are thinking of GoF, but I think that Martin Fowler's PoEAA is much more applicable for the kind of software I am usually hired to write. The next time I am asked to name some design patterns at an interview, my response will be "Repository, MVP, Domain Model, Layer Super Type, Lazy Load, IoC, Plugin, Etc...." Those are patterns I actually use. It seems like a lot of the GoF patterns have been implemented (at least in Visual Studio) in Microsoft's own way. For example, observer is baked into the event keyword. Bridging a base class is as simple as using the built-in refactor tools. Iterator is baked into the foreach keyword. Factory / strategy can both be done using other techniques, and it usually boils down to preference. (MS tends to promote using ctors instead of factories when possible to keep code more readable anyway). If I was writing an OS, or a development lanuguage, or some manufacturing software, I might get some good usage out of the GoF stuff. But for business programming, PoEAA all the way, since it builds on the GoF patterns and makes them more relevant to my problem domain. Jordan
-
Recently I interviewed one guy and found that he is very good in technical stuff. He got a good understanding about C++ and C#. But his OO skills was not up to the level that my company was expecting. He knows and can create classes or interfaces, create good and readable code but he doesn't know to apply design patterns, handling the class responsibilities etc. IMO, OO skills like these can be developed easily when one starts working on projects. Technical knowledge and the willingness to learn matters. What will you do if you were in my position? Do you think advanced OO knowledge is needed to work on a project? Any thoughts?
Navaneeth How to use google | Ask smart questions
How can a candidate know OO languages like C# and C++ that well but not know OO design? Perhaps they haven't been exposed to OO design. Unlikely, but perhaps possible if only a few years out of college. Perhaps they know OO design, but not by your terminology. Your interview should have caught that, and it'll be easier to sell corporate one someone who has the skills and only needs to learn terminology. Perhaps they know OO design, but not design patterns. Not all shops are heavily into patterns, or heavily into a using the full suite of patterns, but they can be learned fairly easily if you grasp the language and OO design. If its none of the above, then that's a red flag, and a different candidate might be the better choice. If you really think they are a possibility, put them on the back burner while you keep looking for a while.
patbob
-
I reiterate, it is not neccessary to memorize GOF design patterns or even know all of them.
Rajesh R Subramanian wrote:
A good developer can always learn this stuff and cope with your organization
As I said, for 1-3 exprience I will hire the candidate becaue at this stage he can start learning and become good in OOP. Beacuse at this stage the developer can learn very fast. One who has 5+ year experience in modern days should have already done that. At least they should have known some OOP concepts and some patterns. For example, Factory method and Abstract Factory is too common to miss in 5 years.uage If developer does not know it, it only implies that the developer is not a good learner. Of course the exception to this rule is one who does not have experience with C++/C#/Java or other OOP language.
I'd probably fail that OOP interview because I haven't bothered to learn the GOF lingo. I have 20+ years of experience programming and I learned OOP directly from the people who invented the concept (this was long before C++). I was writing OO production code in the mid 80's. I browsed through the GOF design patterns book once and couldn't figure out what the big deal was. Practically every design pattern in there was something I'd done before -- I didn't see any reason to read about something I've already been doing for years. And don't tell me having a common language to describe something makes it easier to communicate designs. It's my experience that as soon as you put a label on something and say it's a "foo" then people think they know what it is even when they don't have a clue and couldn't write one themselves. And, by the way, OOP is not the holy grail of programming. It's a tool and it's appropriate for certain problems. It's not appropriate for others. You are way better off with a programmer who is familiar with all the tools and pick the tool that's right for the job.
-
I can't agree. My view is that better design => more maintainable => lower LCO + rapid changes => happy customer. Design patterns are tried and trusted methods of solving certain classes of problem. They (1) help developers avoid reinventing the wheel (2) help developers avoid common design pitfalls and (3) provide us with a common lanuage and approach that aids communication - either through out code or when (and I have heard it happens) developers actually talk to each other. Each of these benefits should have a quantifiable (but not necessarily direct) benefit to our clients. Of course, design patterns are not a silver bullet, but they are a useful tool in out arsenal (or if you prefer: weapon in our toolkit).
KramII wrote:
My view is that better design => more maintainable => lower LCO + rapid changes => happy customer. Design patterns are tried and trusted methods of solving certain classes of problem. They (1) help developers avoid reinventing the wheel (2) help developers avoid common design pitfalls and (3) provide us with a common lanuage and approach that aids communication - either through out code or when (and I have heard it happens) developers actually talk to each other. Each of these benefits should have a quantifiable (but not necessarily direct) benefit to our clients. Of course, design patterns are not a silver bullet, but they are a useful tool in out arsenal (or if you prefer: weapon in our toolkit).
Lot of feel good words. Which could be applied to anything at all. The fact that someone can recite a pattern definition has absolutely nothing to do with whether they can apply the pattern. And I seriously doubt that by itself patterns have any significant impact on lowering maintenance costs. There are proven ways of doing that and they all involve methodologies that for the most part exist entirely outside of actual code construction. Patterns are quantification of common practices that existed before the term "pattern" existed. And good programmers (presumably) created them without knowing either the names or attributes of them.
-
There is a common myth that OO and patterns are inherently related, and knowing OO means you have to know patterns. This is a complete nonsense - a pattern is merely a fancy way of saying that somebody has solved a particular problem in a particular way. It's a formalisation of a recognised problem and solution, that's all - and it's perfectly possible to go through your career writing good solid code without having a clue about what a particular pattern is called. It's completely acceptable to be able to write code that reproduces the Chain of Responsibility pattern without knowing that's what it's called. Ultimately, if your code does what it's supposed to in an efficient and maintainable fashion, that's far more important. I'd be more concerned to find out if he understood techniques like composition and aggregation. It doesn't matter if he doesn't know what they are called - as long as he can explain the basic principles; and you'd find this out by giving him problems to solve that are best solved using the relevant techniques. It's disturbing that so many people are putting emphasis on coding skills, without realising that design skills are just as important for a developer. At some point, you have to come out from the code editor. A good coder must, at some point, be able to pull a design together - if you can't, you're just a code monkey.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
I was hoping someone would point out that design patterns are not part of OO.:thumbsup:
-
I'd probably fail that OOP interview because I haven't bothered to learn the GOF lingo. I have 20+ years of experience programming and I learned OOP directly from the people who invented the concept (this was long before C++). I was writing OO production code in the mid 80's. I browsed through the GOF design patterns book once and couldn't figure out what the big deal was. Practically every design pattern in there was something I'd done before -- I didn't see any reason to read about something I've already been doing for years. And don't tell me having a common language to describe something makes it easier to communicate designs. It's my experience that as soon as you put a label on something and say it's a "foo" then people think they know what it is even when they don't have a clue and couldn't write one themselves. And, by the way, OOP is not the holy grail of programming. It's a tool and it's appropriate for certain problems. It's not appropriate for others. You are way better off with a programmer who is familiar with all the tools and pick the tool that's right for the job.
But after being stuck in FORTRAN (77/90/95) for the past 6 years, I can say that that tool set makes a large number of problems easier to solve and I miss that dearly.
-
But after being stuck in FORTRAN (77/90/95) for the past 6 years, I can say that that tool set makes a large number of problems easier to solve and I miss that dearly.
-
KramII wrote:
My view is that better design => more maintainable => lower LCO + rapid changes => happy customer. Design patterns are tried and trusted methods of solving certain classes of problem. They (1) help developers avoid reinventing the wheel (2) help developers avoid common design pitfalls and (3) provide us with a common lanuage and approach that aids communication - either through out code or when (and I have heard it happens) developers actually talk to each other. Each of these benefits should have a quantifiable (but not necessarily direct) benefit to our clients. Of course, design patterns are not a silver bullet, but they are a useful tool in out arsenal (or if you prefer: weapon in our toolkit).
Lot of feel good words. Which could be applied to anything at all. The fact that someone can recite a pattern definition has absolutely nothing to do with whether they can apply the pattern. And I seriously doubt that by itself patterns have any significant impact on lowering maintenance costs. There are proven ways of doing that and they all involve methodologies that for the most part exist entirely outside of actual code construction. Patterns are quantification of common practices that existed before the term "pattern" existed. And good programmers (presumably) created them without knowing either the names or attributes of them.
-
:wtf: Ouch! In my last post I was almost going to say you could write OO code in any language if you were good enough. But I am not sure I know anyone who could do it in FORTRAN. I feel for you.
I've incorporated as many elements as I can without being able to go with the kludge of a OOP language that they attempted to make with FORTRAN 2003. The liberty that they've taken with operators alone would make your blood boil. Languages designed by committee rarely result in anything usable. But hey, I was able to get some people to start using pointers and dynamically allocated arrays. That was a MAJOR accomplishment. Oh and recursion was another thing that I taught some people. Just imagine what you would have taught a person in a high school computer science class about 18 years ago and that is what I'm stuck trying to bring people up to. :) But all in all, I don't mind all that much, since I do get to work on interplanetary spacecraft for NASA.
-
I've incorporated as many elements as I can without being able to go with the kludge of a OOP language that they attempted to make with FORTRAN 2003. The liberty that they've taken with operators alone would make your blood boil. Languages designed by committee rarely result in anything usable. But hey, I was able to get some people to start using pointers and dynamically allocated arrays. That was a MAJOR accomplishment. Oh and recursion was another thing that I taught some people. Just imagine what you would have taught a person in a high school computer science class about 18 years ago and that is what I'm stuck trying to bring people up to. :) But all in all, I don't mind all that much, since I do get to work on interplanetary spacecraft for NASA.
OO FORTRAN??? :omg: :wtf: :confused: I haven't written FORTRAN in 20 years. I had no idea anyone had tried to morph it into a OO language. Frankly FORTRAN was fine for what it did. It would have been smarter just to added recursion to FORTRAN 77 and then make it possible to call FORTRAN libraries from another language and left well enough alone.
-
OO FORTRAN??? :omg: :wtf: :confused: I haven't written FORTRAN in 20 years. I had no idea anyone had tried to morph it into a OO language. Frankly FORTRAN was fine for what it did. It would have been smarter just to added recursion to FORTRAN 77 and then make it possible to call FORTRAN libraries from another language and left well enough alone.
They finally turned it into what we'd almost think of as a full citizen in the procedural world with pointers, recursion and the like in FORTRAN 90/95. It still is missing major bits that each compiler has a tendency to try to fix in different ways. If there were a good universal way to call FORTRAN libraries from other languages, I would be using it, as having to write code that ends up needing to be compatible with Linux, Windows and OSX is just plain painful when attempting to put any type of standardized TCP interface on it. I eventually just gave up due to lack of time/money, so we just run the code on whatever platform and log onto that machine to use it.
-
In that case, (on a serious note) you could refer him to me if you didn't happen to take him in. We are looking for C++ (on Windows) developers. :)
It is a crappy thing, but it's life -^ Carlo Pallini
:) We are planning to hire him.
Navaneeth How to use google | Ask smart questions
-
KramII wrote:
My view is that better design => more maintainable => lower LCO + rapid changes => happy customer. Design patterns are tried and trusted methods of solving certain classes of problem. They (1) help developers avoid reinventing the wheel (2) help developers avoid common design pitfalls and (3) provide us with a common lanuage and approach that aids communication - either through out code or when (and I have heard it happens) developers actually talk to each other. Each of these benefits should have a quantifiable (but not necessarily direct) benefit to our clients. Of course, design patterns are not a silver bullet, but they are a useful tool in out arsenal (or if you prefer: weapon in our toolkit).
Lot of feel good words. Which could be applied to anything at all. The fact that someone can recite a pattern definition has absolutely nothing to do with whether they can apply the pattern. And I seriously doubt that by itself patterns have any significant impact on lowering maintenance costs. There are proven ways of doing that and they all involve methodologies that for the most part exist entirely outside of actual code construction. Patterns are quantification of common practices that existed before the term "pattern" existed. And good programmers (presumably) created them without knowing either the names or attributes of them.
...which could be applied to anything at all.
I'm not sure what you mean. They certainly wouldn't to the "all we care about is the deliverables" school of thought that I (mistakenly) attributed to the original comment. There is far more to good practice than producing an apparently good result for the customer, but which neglects the longer-term interests of both the cleint and the developer.
The fact that someone can recite a pattern definition has absolutely nothing to do with whether they can apply the pattern.
Absolutely! But that really can be said about pretty much any skill.
And I seriously doubt that by itself patterns have any significant impact on lowering maintenance costs.
I don't think I said "by itself". I think I said they are *one* of the tools we have available to us. Combined with those other tools (some of which are, I admit, *far* more important) patterns can indeed lower the cost of maintenance. Moreover, the I am convinced that the language of patterns (including their names, the literature) can be a useful comminication tool between developers. And good communication leads to lower costs.
There are proven ways of doing that and they all involve methodologies that for the most part exist entirely outside of actual code construction.
Ever read "Code Complete"? McConnell shows that there are also proven ways - and importent - ways of lowinging maintenance costs within code construction, too.
Patterns are quantification of common practices that existed before the term "pattern" existed.
Of course. But were they as widely used? As well understood? A tool for communication?
And good programmers (presumably) created them without knowing either the names or attributes of them.
And we will continue to do so. But not all of us are "good" programmers - at least not all the time. Not all of us want to re-invent the wheel. And some of us see the benfit of a shared language and approach. Don't get me wrong. I really do think there are more important things than patterns - perhaps they are over-emphasised in some circles - but I also find them a useful tool in providing best value for my clients.