SharePoint Jobs Demystified

The "SharePoint" job market seems to be bustling, despite the economic woes. Perhaps companies that invested in the product are now trying to poke at that ROI that Microsoft promised at the beginning. Companies need to make changes to improve their processes, in order to save money, and to play catchup as they jump headlong into the Data Age.

I'm pretty sure that SharePoint jobs come in three categories:

"SharePoint Developer"

Oh happy day, if you have 5 years of .NET development experience with C# -and- you know the SharePoint 2007 Object Model or API. There are a plethora of job ops out there for someone with these skills, but be wary: Companies without a well defined set of objectives for their SharePoint development solution will be tough to work for.

For the most part, SharePoint devs will be working with large data sets outside of SharePoint. What SharePoint does with this data falls into two categories: query and display or convert into a SharePoint structure. Gosh it sounds like Perl!

"SharePoint Architect"

Here, they need someone to manage SharePoint from the server point of view. Here you need hearty skills in MS SQL, IIS, and, well, SharePoint of all flavors. There's usually a migration involved, and you name it, they range from WSS 2.0 and Portal Server migrations to the state of the art MOSS 2007.

Architects need to know how to cluster MS SQL boxes, distribute WFE servers, and to setup search indexing and queries on a massive scale.

"SharePoint Specialist"

My momma told me I was special, yet it turns out I was a specialist. The specialist is a trenches kind of person. They live with the SharePoint end-user and guide them to the proper care and feeding of a SharePoint site. This is a thankless job. You have users that hate SharePoint with a passion, yet you need to train them how to use it effectively.


Often times, companies are looking for that:

"SharePoint Einstein"