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:
- Comfort with reflecting tools like Red Gate Reflector or ILSpy.
- Strong OOP [Event and Feature Receivers, Timer Jobs, Workflows, Reflection]
- Strong ASP.NET Web Forms Development [Web Parts, Custom ASPX Pages, etc.]
- Good Knowledge of XML [Features, Content Types, Field Definitions]
- Willingness to Seek Out and Follow Best Practices
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.