Microsoft SharePoint's value isn't about ease of development, but empowering users to manage their content effectively. And because it's so widely used, the skills needed to implement and maintain the platform come at a premium. (SharePoint skills rank No. 7 on Dice’s list of the most difficult tech positions to fill.) One complicating factor is that many job postings seek a “SharePoint Developer/Architect,” even though those are roles with different functions and responsibilities. It's a common situation that SharePoint professionals face and one you need to prepared for when you walk into an interview. Sam Sabel, guide of the Dice SharePoint Talent Community, contributed these SharePoint 2010 questions for developers. How you answer them will provide managers with a good indication of your knowledge and experience.

If you were asked to create a custom workflow for SharePoint 2010, what development tool would you use?

• What most people say: “I would use SharePoint Designer to develop out the workflow.”
• What you should say: “This depends on the workflow. Factors such as whether it needs to be installed in multiple locations, how it steps through stages and the complexity all determine the tool to use. The most likely tool will either be SharePoint Designer or Visual Studio.”
• Why you should say it: SharePoint Designer would be preferable because it can be simpler and faster to develop with. However, there are many things it can't do. If the workflow needs the ability to go back and forth between statuses, called a State Workflow, then developers must use Visual Studio since State Workflows aren't supported by SharePoint Designer 2010. If the workflow needs to be installed to multiple locations, then again SharePoint Designer won't do. SharePoint Designer hard-codes GUIDs, which are specific to the particular lists and sites. If the workflow is complex because it requires custom code or has more than 20 steps, then Visual Studio is the tool. Only small and simple workflows are for SharePoint Designer.

How would you integrate a non-Microsoft SQL database with SharePoint 2010?

• What most people say: “I would develop an ADO.NET or Linq solution to call the data from code. I would either use the data directly in the application, or place it in a SharePoint list.”
• What you should say: “I would use SharePoint Business Connectivity Services (BCS) and a custom Web service. I would develop a custom Web service on the Microsoft model that was connected to the data sources. Then I would connect this Web service to SharePoint via BCS.”
• Why you should say it: While an ADO.Net or Linq solution in SharePoint may work, the solution wouldn't be able to leverage the functionality of SharePoint or SharePoint Search. There would also be a negative performance impact. Also when SharePoint needs to be upgraded or migrated, there would be no guarantee that this solution would continue to function.On the other hand, a Web service would allow SharePoint (and other systems) to leverage the data, and if the Web service is built on the Microsoft model, it will continue to be supported by SharePoint for a few more versions at least. BCS allows data to be accessed as if it were in a SharePoint list, and also allows search to crawl and index the data, effectively expanding SharePoint's reach to non-Microsoft products. Finally, this model is cloud-friendly.

If you have a bulk upload would you add the data directly to the SharePoint databases?

• What most people say: “Generally uploading data directly to the target system is the fastest and most efficient approach. If possible, I would upload directly to the SharePoint databases”
• What you should say: “I would never, ever, ever, ever, ever, ever, ever directly edit a SharePoint database.”
• Why you should say it: There are many SharePoint databases. They are all complex and have lots of dependencies between tables, many of which aren't enforced via relationships or other mechanisms. SharePoint works off of these databases and disparate file systems. Some relationships are from these files systems to the database. Overall, it's a mess. When you edit the database directly, you're taking your farm in your hands. Beyond that, Microsoft won't provide support for any SharePoint instance with a database that was directly modified.

You're developing a custom SharePoint 2010 solution. The solution writes data to a SharePoint list that users may or may not have access to. How would you assure that the application would always work and not throw an error?

• What most people say: “Set up the list or create a new one that allows everyone to have access to it.”
• What you should say: “Depending on the situation, I would either access the list having invoked RunWithElevatedPrivileges, or by establishing a SPUserToken to give my code the access it needs, while keeping SharePoint security unaffected.”
• Why you should say it: Giving users more privileges as a work-around can have effects that are unexpected and unwanted. The more this approach is taken, the greater the danger. A SharePoint developer should rely on SharePoint functionality. The SharePoint Object Model provides two powerful ways to give the code additional rights, without granting users those rights.

Sabel maintains that there are essentially three different roles for SharePoint talent: administrator, developer and architect. He'll submit similar questions for SharePoint architects in a future article. And he urges companies to treat their SharePoint talent well — because plenty of competitors are ready to lure them away. Image: Microsoft