How to conduct a correct interview?
I have passed many of them in both roles.
My opinion when I conduct such interviews is get to know whether a candidate is a problem-solving type.
What does it mean?
Does it mean that he will be able to know all technologies with all low-level details?..
I doubt.
Very often I interview candidates who are quite good at low-level details but have the lack of architectural skills and can't really provide a solution to my test task.
Do you need a developer who has low-level knowledge and don't have a glue how to solve problems?
Possibly, no.
I won't insist. May be there are situations when it does not matter whether a developer problem-solving type or not -- all what he is supposed to do is to serve as a codemonkey all day long.
But I am stick the following opinion: I'd rather hire a problem-solving type developer with good learning skills than developer who has impressive knowledge in web services, ASP .Net, or whatever-technology but was not able to understand a task and provide a good solution to solve it (no low-level details required -- they can be easily picked up from Google).
Tuesday, December 11, 2012
Saturday, December 8, 2012
improving education with www.codeacademy.com
I can recommend www.codeacademy.com site to everyone who needs to refresh his/her web-related knowledge, or even learn a new one.
It won't take a lot of time, but I found that this academy can save a lot of time :)
In example, I did not know CSS very well, but one of the courses gave me enough experience in a few hours. :)
It won't take a lot of time, but I found that this academy can save a lot of time :)
In example, I did not know CSS very well, but one of the courses gave me enough experience in a few hours. :)
S.O.L.I.D. presentation conducted!
Last Friday I conducted S.O.L.I.D. principles presentation in my company, EPAM Systems.
While I was working at Tau Craft, I tried to do it step-by-step, explaining one principle at a time.
But I stopped on the second stage -- Open-Closed Principle as I felt that I need to rethink my approach, them postponed it until this time.
Now I took a completely different approach supplying each principle with a huge amount of examples in Visual Studio 2012.
Combining live coding with theoretical part the whole things seemed more logical and memorable, so my auditory was quite satisfied (that was demonstrated by high course rates).
Let's see one good metaphor for Open-Closed Principle:
I found it during preparation and now believe that it's the best example I have ever seen! :)
There were some problems with Liskov Substitution Principle, but it went just fine thought it still needs to be improved (will do it).
The most debatable case was Dependency Inversion Principle:
We spent plenty of time discussing of how much granularity should be used.
And yes! Remember one thing: Dependency Inversion is not equal to Dependency Injection! They are often mixed out, but they should not! :)
Let's have a look at an example.
Before DIP applied:
On this picture the layering is ok (consider namespace as an assembly/module).
UI depends on Business, Business depends on Data Access.
The DIP violated because two things:
1. UI depends on low-level detail (uses PointOfSaleTerminal class.
2. No abstractions at all.
After fixing we acquired the following picture:
In this case dependencies were TRULY INVERTED!
All modules now depends on interface class.
I must mention that the key idea is that Dependency Injection is just a tool to implement Dependency Inversion.
You can find a good article about it in Dependency Injection is NOT The Same As The Dependency Inversion Principle by Derick Bailey
While I was working at Tau Craft, I tried to do it step-by-step, explaining one principle at a time.
But I stopped on the second stage -- Open-Closed Principle as I felt that I need to rethink my approach, them postponed it until this time.
Now I took a completely different approach supplying each principle with a huge amount of examples in Visual Studio 2012.
Combining live coding with theoretical part the whole things seemed more logical and memorable, so my auditory was quite satisfied (that was demonstrated by high course rates).
Let's see one good metaphor for Open-Closed Principle:
 |
| OCP |
I found it during preparation and now believe that it's the best example I have ever seen! :)
There were some problems with Liskov Substitution Principle, but it went just fine thought it still needs to be improved (will do it).
The most debatable case was Dependency Inversion Principle:
 |
| DIP |
We spent plenty of time discussing of how much granularity should be used.
And yes! Remember one thing: Dependency Inversion is not equal to Dependency Injection! They are often mixed out, but they should not! :)
Let's have a look at an example.
Before DIP applied:
UI depends on Business, Business depends on Data Access.
The DIP violated because two things:
1. UI depends on low-level detail (uses PointOfSaleTerminal class.
2. No abstractions at all.
After fixing we acquired the following picture:
In this case dependencies were TRULY INVERTED!
All modules now depends on interface class.
I must mention that the key idea is that Dependency Injection is just a tool to implement Dependency Inversion.
You can find a good article about it in Dependency Injection is NOT The Same As The Dependency Inversion Principle by Derick Bailey
Subscribe to:
Posts (Atom)