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
(Namaste, or Namaskaram, or Vanakkum : your choice), Sri Navaneeth, An interesting question : from my point of view you are very prudently weighing the cost/benefit and risk of using some of your "political capital" and "cred" with management against a possible valuable addition to your team. Is there perhaps a "middle path" here where you propose to hire the employee first as a contractor, or on a three month trial basis, with specific written notice to the employee that they are expected to demonstrate mastery of certain OO skills and concepts within that period. Another thought : have you discussed the candidate and your views with the other members of the team he or she would be actually working with closely ? Did they have the opportunity to interview the candidate ? I think if your team is saying the candidate is "worth the risk" then he or she has a much better chance at success than if your team strongly oppose the candidate. Now the "ruthless bastards" I've worked with in the past would offer the candidate a slightly lower job position with a really lower rate of pay with the promise for an up-or-out performance review within six months (and that would be stretched out indefinitely). But I am pretty sure you are not one of those :) best, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
-
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
Yes, but you need to see their code to judge it for yourself. Too many hacks can talk a good game.
-
Yes, but you need to see their code to judge it for yourself. Too many hacks can talk a good game.
PIEBALDconsult wrote:
Too many hacks can talk a good game.
Hacks usually give themselves away fairly quickly; I'm more leery of those who can spew all the buzzwords.
-
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.
spot on :thumbsup:
Viral My Site Tips & Tracks
-
IMHO, hire him (or her). Every company has a "culture" and yours happens to embrace design patterns and class responsibilites. I've been using OOP principles since Turbo Pascal introduced the concept in version 5.5, and never heard of either until recently. Who the hell cares about the buzzword of the day? He's got a solid foundation, and probably can be trained easily enough into your particular mindset to be a real asset. Good fundamentals are hard to find in any technical candidate these days - grab him.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
Excellent comment. :)
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
Doesn't make sense, every house has a style, it may be adopted as a design pattern, and there seems to be hundreds of the bloody things, or it may be internally developed. You expect a dev to know the particular patterns you are using. I consider that a long stretch. I recall a contract in the late 90's I think, VB5 anyway, where the project lead said we develop in this style and when I said I had never used that style he stated that he didn't ask wether I had but wether I WOULD use their standard. I instantly accepted the contract. Learning a patternt/practice is infinately easier than learning to code decently. Hire the bloke (assumed) and give him the doco on the pattern/practice.
Never underestimate the power of human stupidity RAH
-
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.
I'd beg to differ. What if a candidate isn't exposed to any kind of design pattern mumbo-jumbos at all, for all the years of his work? I've seen and worked with some excellent developers, who can write fast and efficient code, but don't know a thing about design pattern. I'd see knowing design patterns and other flashy stuff a plus, but I'd never miss a good developer who has a solid grasp of the fundamentals, with problem solving skills, no matter what he knows or not knows about design patterns. A good developer can always learn this stuff and cope with your organization (if design pattern and other buzz is a part of your organization's culture). Just my thought though... :)
It is a crappy thing, but it's life -^ Carlo Pallini
-
Yes, but you need to see their code to judge it for yourself. Too many hacks can talk a good game.
Code looks perfect to me.
Navaneeth How to use google | Ask smart questions
-
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 the end, the client is only happy with the solution, not the way how it was implimented. Internally you should care if his code is understandable, robust etc... but who cares if it's not according to pattern A or B?
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive -
Doesn't make sense, every house has a style, it may be adopted as a design pattern, and there seems to be hundreds of the bloody things, or it may be internally developed. You expect a dev to know the particular patterns you are using. I consider that a long stretch. I recall a contract in the late 90's I think, VB5 anyway, where the project lead said we develop in this style and when I said I had never used that style he stated that he didn't ask wether I had but wether I WOULD use their standard. I instantly accepted the contract. Learning a patternt/practice is infinately easier than learning to code decently. Hire the bloke (assumed) and give him the doco on the pattern/practice.
Never underestimate the power of human stupidity RAH
That is so true. Every company has their own standard(s), methods etc. I don't think it's fair to expect someone to know all :omg:
-
I'd beg to differ. What if a candidate isn't exposed to any kind of design pattern mumbo-jumbos at all, for all the years of his work? I've seen and worked with some excellent developers, who can write fast and efficient code, but don't know a thing about design pattern. I'd see knowing design patterns and other flashy stuff a plus, but I'd never miss a good developer who has a solid grasp of the fundamentals, with problem solving skills, no matter what he knows or not knows about design patterns. A good developer can always learn this stuff and cope with your organization (if design pattern and other buzz is a part of your organization's culture). Just my thought though... :)
It is a crappy thing, but it's life -^ Carlo Pallini
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.
-
You must work at Microsoft where the motto is; anything not done in COM isn't worth doing? :)
modified on Thursday, August 13, 2009 12:45 AM
Joe Woodbury wrote:
You must work at Microsoft where the motto is; anything not done in COM isn't worth doing?
COMis quite outdated, even atMicrosoft.If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Joe Woodbury wrote:
You must work at Microsoft where the motto is; anything not done in COM isn't worth doing?
COMis quite outdated, even atMicrosoft.If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]CPallini wrote:
COM is quite outdated, even at Microsoft.
Really! How come most of the new windows 7 stuff is in COM: Jump lists, Ribbon, Direct Write, new Media APIs.
-
CPallini wrote:
COM is quite outdated, even at Microsoft.
Really! How come most of the new windows 7 stuff is in COM: Jump lists, Ribbon, Direct Write, new Media APIs.
Ah, OK:
COMis the blazing MS technology of the moment! My bad: I supposed they blowing on theNETfire! :-DIf the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
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
The ability to get on with the job and produce solid, maintainable code is far more important than being able to articulate the ins and outs of OO or know all the latest buzz words or can decribe th einner workings of the 'Useless' pattern. Besides, most people wouldn't know or don't understand OO anyway: many of the companies I have worked at ask lots of questions about OO and patterns at interview but when you get to working they never use them anyway or the workers on the ground don't have a clue.
-
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
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.
-
In the end, the client is only happy with the solution, not the way how it was implimented. Internally you should care if his code is understandable, robust etc... but who cares if it's not according to pattern A or B?
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview ArchiveI 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).
-
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).
note that I didn't say that design patterns aren't useful, on the contrary. as you said:
KramII wrote:
Design patterns are tried and trusted methods of solving certain classes of problem
but a client, in the end, wouldn't give a sh*t :-D.
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive -
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.
Good one.
Navaneeth How to use google | Ask smart questions
-
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.