Interview Questions for SharePoint Architects

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.

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.

Related Jobs

Comments

You said…. “How would you a set up SharePoint farm for our 800 active users? What would the network topography look like?”

I would answer, “It’s cheaper to let Microsoft host it and worry about that. I would recommend you use Office365. SharePoint infrastructure is a commodity, and you’re not in the business of building infrastructure.”

And I would most likely not hire you. Why? Because you can’t make a definitive recommendation in an interview based on a question that states “we need a farm for 800 active users”. The answer MIGHT be Office 365… but then again, it might be an on premises implementation.

Some companies (especially financial organizations) are very hesitant to go the cloud with their data. If a company is going to setup a farm for 800 users, it’s a valid assumption that they will have quite a bit of either confidential company documentation, BI data, or a combination of both. It may be a hard sell to have them put that in the cloud (no matter how safe Microsoft says it is).

In addition, assuming that they don’t have an infrastructure to support it is problematic at this point. You don’t know that.

The best answer is almost always to lay out the most likely choices (at least 2), and then qualify that by saying that you’ll need further analysis to select the best choice of those.

@Basil, Great advice! This would definitely be an option for many companies. Of course, this all depends on the company. The functionality of Office 365 is not yet on par with SharePoint 2013. Nor will all enterprises consider moving to the cloud at this point. Regulatory, security and governance concerns are key stumbling blocks for the move to Office 365. Regardless, smart architects should consider this option for exactly the reasons @Basil spells out.

You really cleared my confusion with your insight on SharePoint Governance. User adoption cannot simply be increased by good governance, but users across the enterprise should feel comfortable to realize the value-add that sharepoint delivers.
I would even mention separate search and index servers in the farm. For companies relying heavily on content and people search , search servers would provide the scalability and uptime.

Great article you touched on some great area’s to test an architects aptitude for the job. As an architect I’ve learned to perfect may planning and provide as much detail as soon as possible to ensure business is in the loop and aware end to end what I plan to implement. As the solutions progresses you simply go back and tweak your plan accordingly as changes and requirements are defined more. High level any architect should provide, Design Plans, proposed solutions implementation plan, testing & validation plan, governance plan, communication plan.