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
Wednesday, November 28, 2012
Mock Object Frameworks and CRC Cards Presentations
Today provided Mock Object Frameworks presentation with live coding session.
Looks like people prefers coding sessions over just presentation, so I shortened the introduction as much as possible.
I covered only the most important parts:
- why we use mock objects (a funny example was given);
- how to transform a system which can't be tested into a system which can be tested with using of mock objects
- types of mock objects: stubs and mocks themselves
- how to implement mock objects/stubs manually and with using of two major frameworks: Moq and Rhino Mocks.
I was thinking of providing one more mock object framework -- Microsoft Fakes -- but failed to do so. Some strange "Not supported" exception were thrown during "test ride" trying to raise an event from mock object. Furthermore, Microsoft Fakes framework distributed among VS 2012 Ultimate edition only, which is not suitable for the most of my listeners.
The next presentation will be about CRC cards. Will try to figure out how to conduct it in the most efficient way :)
Looks like people prefers coding sessions over just presentation, so I shortened the introduction as much as possible.
I covered only the most important parts:
- why we use mock objects (a funny example was given);
- how to transform a system which can't be tested into a system which can be tested with using of mock objects
- types of mock objects: stubs and mocks themselves
- how to implement mock objects/stubs manually and with using of two major frameworks: Moq and Rhino Mocks.
I was thinking of providing one more mock object framework -- Microsoft Fakes -- but failed to do so. Some strange "Not supported" exception were thrown during "test ride" trying to raise an event from mock object. Furthermore, Microsoft Fakes framework distributed among VS 2012 Ultimate edition only, which is not suitable for the most of my listeners.
The next presentation will be about CRC cards. Will try to figure out how to conduct it in the most efficient way :)
Sunday, November 25, 2012
Webinars
I think that seminars are useless in terms of learning how to conduct interesting presentation.
The main aspect of every presentation is auditory reaction. It's hardly possible to see that reaction while doing it in webinar-fashion way.
The main aspect of every presentation is auditory reaction. It's hardly possible to see that reaction while doing it in webinar-fashion way.
Two lectures provided last week
Two lectures provided last week:
- Event-Driven Architecture. It was the hardest one. I tried to explain this advanced topic to people, with code example (Rhino Service Bus). As the result I may conclude that 2h is not enough for it. Will conduct once more, 4h-long this time.
The following example was used to describe event-driven system, and I am not sure if it was ok. Need to revise whole presentation.
- Introduction to UML. Actually, this was the easiest one. I spent about 5h to prepare it (a dozen of slides and a lecture plan). It was the nice one! :) Hope that it will be estimated with high scores! :)
The plan was simple: need to provide UML in scope which is widely used by developers.
I stressed that UML is useful for developers for communication purposes and provided UML in terms how to describe both static and behavior aspects of any system.
Static:
- class diagram
- deployment diagram
- component diagram
Dynamic:
- sequence diagram
- interaction diagram
Several examples were provided to establish connection between diagrams and codebase.
Wednesday, November 21, 2012
Event-Driven Architecture Presentation completed -- first round!
Провел презентацию Event-Driven Architecture, ушло 2 часа.
Подготовка заняла 16 часов.
Много примеров из жизни, но все же несколько сумбурно. Думаю, в следующий раз необходимо теоретические основы и примеры из жизни сократить до 40-30 минут, а вот практики -- побольше!
Обнаружилось, что присутствующим собственно эта практика в наибольшей степени интересна.
А вот послезавтра, 23 ноября, буду проводить новую презентацию, по UML - Introduction
Придется поработать над практическими примерами! :)
Надеюсь, все успею сделать как надо.
Подготовка заняла 16 часов.
Много примеров из жизни, но все же несколько сумбурно. Думаю, в следующий раз необходимо теоретические основы и примеры из жизни сократить до 40-30 минут, а вот практики -- побольше!
Обнаружилось, что присутствующим собственно эта практика в наибольшей степени интересна.
А вот послезавтра, 23 ноября, буду проводить новую презентацию, по UML - Introduction
Придется поработать над практическими примерами! :)
Надеюсь, все успею сделать как надо.
Subscribe to:
Posts (Atom)