I can't tell you enough about how much surprised I was when some developers applying for senior .NET development position, when being interviewed by me, could not answer very fundamental questions about a specific technology or programming language as well as were not aware of any trends in the field. What I found out was that usually this had something to do with their attitude towards "learning on the job".
Some of them even told me that they consider questions like "what are the differences between value type and reference type", "when should you use interface instead of abstract class", "compare 'protected' and 'internal' accessibility levels" and so on (I listed some others here) are theoretical and not useful for the job. They went on saying that they never found themselves think about these when doing their jobs and yet they could still get their jobs done and even got promoted to the senior position. Some even went as far as saying that things like design patterns were impractical for real-world projects. Reasons like such went on.
Most of these folks have many years of experience in software development, but they have the experience of doing the same things over and over again. Besides, instead of trying explore many technological possibilities to pick the most suitable way of accomplishing things, they only learn enough to get the job done. These developers are confused between getting the software built and getting the software built the right way and yet they think they are perfect examples of those who learn on the job the right way - which can't be more far from the truth.
The sign of this type is that their knowledge and skills are no broader than what they have applied in their past projects and no deeper than what barely necessary to finish the tasks assigned (and they usually refer to anything beyond that as "theoretical" or "impractical"). For example, they know how to code a data access layer to map relational data to the object model, but they have never heard about NHibernate, iBATIS.NET or even the term ORM tools; they know how to implement ASP.NET pages, but having no knowledge about the page life cycle; they know how to code or use a collection class, but they have never learned to use generics; they design a new system based on the way they designed previous systems instead of based on project-specific trade-offs and design principles; they use C# 2.0 without knowing about anonymous delegate and iterator; if you ask them to apply logging to an existing system, they will open one thousand something methods to add the Console.WriteLine() (not even logger.Info()) to each of them; and if their bosses don't ask them to write unit test (chances that the bosses will never do so), they do not know what on earth NUnit is. The list goes on…
Obvious is it to see, software built by these developers usually are work of hacks (negative hacks) and under-perform in terms of reliability, maintainability, extensibility, cost-effectiveness and so forth. In fact, because of their lack of breadth and depth in knowledge they can only pick a solution out of their limited number of solution alternatives, and they will need a great deal of time to troubleshoot / debug code when something goes wrong behind the abstractions. But, their learning attitude alone, which often implies a lack of motivation or interest in their career, will already make them look very bad in the hirer's eyes.
I always hesitate to follow-up with these developers, even just to offer a junior or mid-level position. I don't care if they have the ability to quickly learn about new things or not, because it is the fact that their multi-year experience shows me that they did not spend the effort to learn how to do things more effectively and chances are that they might continue with that in the future.
After reading this article, I realised how much core technical knowledge I am having... :( I have to study a lot... Friends! how about you?
0 comments:
Post a Comment