Though many job postings refer to “SharePoint Developer/Architects," the two roles require different skills and responsibilities. When you're interviewing, you have to be able to address the differences. Sam Sabel, guide of the Dice SharePoint Talent Community, previously contributed interview questions for SharePoint developers. Here, he poses questions for architects, based on SharePoint 2010. How would you a set up SharePoint farm for our 800 active users? What would the network topography look like?

• What most people say: "We can stand up a server for SharePoint itself that should handle all tasks and keep implementation simple. We can rely upon an existing SQL server to house our SharePoint databases."
• What you should say: "At a minimum, the farm should consist of a couple of load-balanced Web front-end servers to handle the network traffic and serve up pages, one application/central admin server for SharePoint services and management, and an SQL cluster for the SharePoint databases. This should handle traffic load and keep performance high for this mid-size SharePoint farm. These servers should likely all be within the company’s perimeter network (DMZ) and have access to a Domain controller. An additional SharePoint farm should be considered for development, QA, and staging purposes."
• Why you should say it: SharePoint quickly becomes a business critical platform to any companies that implement it. Uptime is critical. Setting up a farm that handles server failures and keeps going is key to assuring success.

Load balancing the front-end will provide performance gains and keep SharePoint running even if a Web server goes down. These web servers can also be tasked to take over SharePoint services and admin in the case of a failure of the application/central admin server.

The database servers should also be protected against failure, an SQL cluster or a similar configuration that assures no single point of failure. Additionally, SharePoint databases should never be housed on the same server as other databases.

The two primary reasons for this are that SharePoint databases require a lot of resources, and because the other databases can pose a risk to the environment when they cause errors or drain too many resources.

When setting up a SharePoint farm, security of the data that it will house is critical  but sometimes overlooked. Whenever possible, the SharePoint farm should be protected within a company’s DMZ. Additional risk to a SharePoint farm comes from software updates, patches, hotfixes, custom code, third party tools and applications… the list goes on. To protect against these types of risks, it's worthwhile to develop custom code in a separate environment and test all planned software and configuration-level changes in a controlled “staging” environment before they're moved to the business critical SharePoint farm.

What should SharePoint governance look like at our company?

• What most people say (Version 1): "Our biggest concern has got to be user adoption with SharePoint. Governance needs to open the door for user adoption. If we over-govern SharePoint, it will turn people away."
• What most people say (Version 2): "Governance is crucial to any and every change made to SharePoint. We need to develop out clear and concise rules on how any kind of change should be made."
• What you should say: "Governance is key to success with SharePoint, however I cannot yet say exactly what form SharePoint governance should take for your organization. We'll need to look at the environment and have discussions with its users before we can draft out what governance should look like for this company (or this SharePoint farm)."
• Why you should say it: SharePoint governance is the way in which SharePoint is managed and administered. SharePoint itself is just a platform and every company uses it in unique ways. What's good for one company could be disastrous for another. At any given company there can be different policies for different SharePoint farms. The way a portal is administered is vastly different from how a collaboration or team space should be administered.

We need to organize and tag information with a shared company vernacular, like product or department names. This information needs to be stored consistently across SharePoint. How would you implement this?

• What most people say: "We either can provide lists of acceptable values and train our administrators to enforce these naming conventions, or we can setup Managed Metadata and Content Types to enforce these conventions."
• What you should say: "We should plan out and define an information taxonomy alongside a governance plan for SharePoint. By doing that, we can assess and implement the best solution for managing the information in our SharePoint farms."
• Why you should say it: There are many ways to manage information within SharePoint. Some are federated, some are centralized. It's not enough to know that you can setup Managed Metadata or create Content Types. Without a plan on how to manage information, these forms easily can become overwhelming and difficult to manage. This quickly leads to disuse and the abandonment of whatever information architecture that was intended.

By assessing and defining how information should be organized, via a clear and understandable information taxonomy outline, you can develop an information architecture. By developing a good governance plan, you can assure that this architecture will be maintained correctly. Without both the taxonomy and the governance, you end up with a Jenga tower of competing information architectures.

SharePoint skills are in demand – ranking No. 7 on Dice’s list of hiring managers’ hardest positions to fill. Highlight your knowledge as an architect to ensure your employer’s environment will be scalable, reliable and fast. What SharePoint questions have you had to field? Let us know in the comments below.