Technical Interview Preparation - Essential Skills

Over the years I have interviewed hundreds of candidates for technical positions as well as project management. It is frustrating to see how ill-prepared candidates are for such interviews. For clearing a technical interview for a developer or a senior developer, it is important that a candidate be knowledgeable in a few subjects.
I will first list what are essential skills and then we will cover what makes you an expert. The focus mostly is on Microsoft technologies.

Essential Skills
1. HTML - it is a must, to know HTML. It is pointless in this day and age to say you only know desktop apps.
2. Javascript - atleast to the extent of the standard way of getting the value of a text box; to handle a click event.
3. Regular Expressions - most people do not know regular expressions. Try to find out how to validate strings using regular expressions in Javascript, and a server side language such as Java, C# or VB.NET.
4. XML, XPath, Parsers - Know something about well-formed XML; about parsing XML documents; and querying XML documents using XPath. Try using a client side parser and a server side parser.
5. XSLT - is good to know.
6. Object Oriented Programming (OOP) - Polymorphism, Inheritance, Encapsulation, Overloading, Interfaces, Abstract Classes. You should be able to create a simple class model.
7. Collections - Arrays, Hashtables, Vectors, Dictionaries; whatever they are called, learn how to use a list of objects of same type or different types and how to use them in any language of your choice.
8. Database Access - in any framework of your choice; .NET, Java or PHP.
9. SQL - It is essential to know how you can query a set of related database tables.
10. Table Design - for a typical scenario such as online shopping or student registration or an address book. You need to be able to design tables and relate them using keys.
11. Tools - such as source control.
12. Deployment - you need to understand how the servers are laid out in a production system. You need to know how your development code is transferred to QA.
12. Concepts such as what a web server is; what a database server is; what is QA; the role of a client and a server and so on.

If you knew all of the above, a company will consider recruiting you and training you. You can learn most of these with Open Source tools.
Of course, for real expertise, you need to know a lot more in web applications and desktop applications. I will list that out in subsequent posts.

The role of project managers

What is the role of a project manager in a software development consultancy?
I have worked in different structures in India and the USA. In India, in Cognizant and other companies, technical staff became Project Managers (PM). They guide the project from collecting requirements to delivery. But they also technically mentored developers; they were in charge of technical architecture. They conducted the appraisals of technical staff.
In the USA I was exposed to a different structure (that my company called the Matrix structure). Developers reported to a tech lead and then a set of architects and so on upto the CTO. The PMs were part of a completely different reporting hierarchy. They actually went to a different VP. On projects, the PMs and Tech Leads work together. PMs have no say in technical decisions. They are in fact, completely non-technical. Appraisals and mentoring are done by the Tech Leads.
I, as a technical person, felt comfortable working in the second structure. But I need to mention that the second structure was not for a software consulting company.

When I came back to India and joined my current company, I noticed that the structure was similar to the American model. I fit in fine.
But I do see that there are some confusions about what a project manager's role is with respect to developers. I am trying to gain some clarity on that.

In the Software Development methodologies such as Microsoft Solution Framework(MSF) or Rational Unified Process (RUP), the project manager has an important role. That role is to handle requirements, change requests and risk. We should note that developers ALSO have a very important role. In the eyes of these processes, every role has a value. As such all the roles are in the same level. I want to reemphasize this - in a software project, the PM has a role at the same level as a developer or a Tech Lead.
As a part of their role, they have certain responsibilities.

In consulting organizations, PM is ALSO a Position. You enter an organization as a PM. That has commensurate pay and other perks. They also have certain administrative responsibilities.
Thus the PM has a position as well as a role. In a project, the PM has to play their role. The division of labor between the Tech Lead, developers and the PM is clear. As long as we stick to that we should be fine.
But, I have seen PMs forgetting this and get antsy with developers. I have seen this so often with Indian PMs that it is annoying. For example, PMs try to second guess the Tech Lead's estimates. I had one PM sending an email questioning a row in a database table. PMs also tend to take MORE ownership than necessary in a project lifecycle. Some of them yell and scream and write nasty emails to the technical staff. This commonly leads to unhappy developers.
As part of their role, PMs have to be in constant consultation with their technical staff - particularly with Tech Leads. It is important to have a good relationship with tech leads.
We have to keep the technical staff happy - that is a priority in any organization that depends on software development.

I have talked about this with some PMs and their response is that they are answerable to clients. This is such a cliche - I have never heard of any PM being fired because a technical mishap happened in a project. Developers deal with very uncertain technology; and they have to stick to very tight timelines. That is a given and MOST clients understand that.
Obviously there is another side of the coin - there IS unprofessional behavior among technical staff as well. But that can be combated using standard warnings and escalations.