Take the 2-minute tour ×

More specifically, what do you feel Junior, Intermediate, and Senior programmers should know about OO design and programming?

I'm hoping that having some appropriate expectations will help us during the recruiting process.

share|improve this question
What sort of programmer? I'd expect the level of expertise to be different between embedded programming and writing desktop apps. –  David Thornley Oct 15 '10 at 15:13
Wouldn't the correct answer depend on the job requirements? If someone was going to work on functional software, would the OO requirements be different from those of a web shop or a video game? –  dash-tom-bang Oct 15 '10 at 16:51
add comment

2 Answers

If they develop in a OO language, I guess the answer is that they should understand the OO design and programming at 100%

However, if you are hiring a junior, I think you can be more flexible, and judge its ability to learn new concepts rather that its knowledge level at the time of the interview.

share|improve this answer
+1 for "ability to learn new concepts". –  Liggy Oct 15 '10 at 13:35
add comment

All levels should :

  1. Know Design Patterns (this is mostly understood to be the compilation by GoF, but also some other such as Dependency Injection, etc).

  2. Understand how to model the interactions thru Use Cases a.k.a. "user stories".

  3. Is careful with inheritance. (EDIT, by request from OP: Basically, inheritance is recommended to be used very carefully as it leads to so-called "white-box reuse" (meaning that implementation details of base class are no longer hidden), which breaks the spirit of OOP. If you really need to reuse a class functionality you can often yield much bettter results by object composition, as it does not change the OOP landscape and leads to a cleaner design. This is summed up by the famous principle : "Favor composition of objects over inheritance". This does not mean however that inheritance should always be avoided, just that other venues should be explored first.)

  4. Programs to interface rather than to class.

  5. Understands UML and is able to describe his design through UML.

  6. Never, ever comes up with the "best possible" design right in the first iteration.

  7. Can identify potential problems with own design = understands contraints under which interfaces and classes are usable.

share|improve this answer
Great points! Can you perhaps elaborate on "Is careful with inheritance"? –  Liggy Oct 15 '10 at 13:37
I've never met a developer who used UML in real world stuff. I'm sure it's great for management, but is it part of understanding object orientation? Not for me. –  glenatron Oct 15 '10 at 13:41
@glenatron - I once worked with a guy who literally said - "I never needed to make any notes". Does that mean his point is valid? I'm sure for him it's valid, but for me - no. –  Jas Oct 15 '10 at 13:45
@Liggy, I've edited my answer to include a bit of explanation for poit 3 (Inheritance). Hope it helps. –  Jas Oct 15 '10 at 13:52
-1 because of #2 and #5. These are good practices but have nothing to do with OOP. UML is a tool often used for capturing OO design, but it is not at all required. –  Matt Olenik Oct 15 '10 at 14:38
show 10 more comments

Your Answer


