I was just wondering what skills and technologies I need to know to in order to start a career path in Sharepoint. I know that it primarily depends on the job I am applying for but there must be a number of baseline skills that are common among most Sharepoint jobs.
Btw, I'm currently a CS student who has only learnt Java.
to begin with you won't need a development language nor development experience to learn how to use the out-of-the-box features and the basic CMS stuff, but when you start custom development you'll need: -
books i recommend: -
beginner
advanced
I am answering this because you said "Start with SharePoint" and not "Start with SharePoint Development" and this is not an indictment or an endorsement of SharePoint but ...
If you are economically hard up and are looking for a minimum set of skills, I can say with some authority, because our company does a lot of SharePoint work, that many many companies actually are not interested in any kind of customization or development work of any type. Most of the 'development' work, actually ends up being a lot of infrastructure work, setting of lists, configuring configuring configuring, maybe some skinning, maybe deploying some off of the shelf components, maybe a workflow here and there if they are fancy.
So it is conceivable that at a minimum all you might need is a SharePoint admin certification and some mad interviewing skills and you might be able to land a job somewhere doing SharePoint. However, the HUGE caveat here is that will only take you so far. If you do not have knowledge of the ASP.NET framework that it is built on top of, much less web programming in general, or any kind of C#/VB if you are doing a workflow, then you will run into a road block pretty fast. I'd direct you at @OmarQa answer for more info.
One of the most brilliant developers I ever met worked primarily in custom SharePoint development and was deep in code most days. Another I knew came from a non-technical background and tired to do a little coding as possible but that what the people wanted so he did well. So keep in mind there is a huge spectrum to work within.
I've been developing for SharePoint 2007 (MOSS) for around 4 years or so with almost all of that time being custom code (not skinning, not creating lists but rather writing custom web parts, workflows, list templates with event receivers, timer jobs, etc.) I haven't had much opportunity to work with 2010 yet but from what I've seen, it's much the same in terms of parts and pieces to customize though the actual code content can be more complex given the presence of sandbox solutions, etc.
In general, this is what I've needed to be successful:
SharePoint development is, at the best of times, frustrating. The MSDN documentation is often wrong or misleading regarding the XML structures for creating fields, content types, etc. I use a tool from CodePlex called WSP Builder which helps but is itself plagued with things that aren't right. From experience I've learned where the mines are hidden and I can quickly step around them but I watch new person after new person get blown up. SharePoint is not a very easy system to jump into and be off and running in days. The more comfortable you are with concepts like OOP reading other peoples' code the faster you will be able to pick it up but it is still an uphill battle.
On the other hand, doing SharePoint administration is a bit easier if there isn't a need for complex solutions. Creating lists, setting up alerts, using SharePoint Designer shudder to do some tweaking of the layout and look of pages, activating basic workflows - these are much easier and can be picked up from some classes. Every SharePoint environment needs these people, not all environments want developers like me. While I can write code that is more tailored to an in-house need, it means there is now more code that has to be supported by staff rather than COTS products which come with their own support.
Speaking as a person that does interview technical screenings of candidates, someone with SharePoint knowledge but no development background or experience will not pass. It is much more important to have the knowledge and experience with development concepts than SharePoint specifically. You can pick up the quirks of SharePoint while working with it - you can't pick up mature development practices the same way. In short, I wouldn't want to work with a company that would have a non-developer developing for SharePoint.
