Monday, January 21, 2013

Definitions #1: SharePoint Developer

Today, I would like to define for you what a SharePoint Developer does. Simply stated, a SharePoint developer performs actions that involve writing code to meet custom needs of the enterprise. These actions extend the capabilities of SharePoint above and beyond what can be done out-of-the-box, with InfoPath, or with SharePoint Designer. Within the realm of browser-based applications, there are two ways to present interactivity between the user and the web in which he or she is interacting: Client-Side and Server-Side.

Some developers specialize in one or the other, but can do both. This is dependent upon several variables, such as business requirements, developer skillset, and access levels.

Client-Side development is handled at the browser level, meaning that most of this kind of work is done with HTML or javascript, and can involve technologies like JQuery, JCarousel, etc. For the most part, this can be done with only Site Owner or Site Collection Administrator permissions, or in some limited cases, contributor. Some of the tools required for this include SharePoint Designer, though some of the work can be done in a simple Content Editor Web Part and a library to store any resource files, such as JQuery. A client-side developer may also opt to take advantage of tools present in Microsoft InfoPath.

Server-Side development is handled, as the name suggests, at the server level. For these scenarios, the developer will need a solid foundation of .Net experience, as well as a solid understanding of SharePoint architecture, queries, workflows, and the SharePoint Object Model. Tools that the Server-Side developer requires include a development SharePoint environment (read farm, even if only a single server instance) for which he or she has administrative access to, as well as Microsoft Visual Studio, to develop, package, and deploy what are known as features. These individuals can have some experience (or at least some know-how) as a SharePoint administrator, but it isn't necessarily required.

Other duties that are typically required by developers include knowledge of version management, configuration management, and most importantly, the ability to compile quality documentation of their work.

The Important Recruiting Take-away: Many developers are knowledgable on both, but you, as the recruiter, need to know what you're hiring for and what that person will have access to at their job place. You do NOT want to place a candidate that only has client side experience for a job requiring Server-Side skills, or, on the other side of the coin, a person who has and wants to utilize server-side skills but will only have access to implement client-side methods when they arrive at their new job site. 

1. Make sure that the hiring manager has given you, the recruiter, an accurate job description for any development positions.

2. Take a close look at the resumes of your candidates. Do they possess use of Visual Studio in the context of a SharePoint environment? In my case, I did a brief stint as a .net developer long before I gained any experience with SharePoint. If a recruiter examines my resume, they will see that I have no .net experience during the jobs that I have used SharePoint. I also have in bold letters towards the top of my resume that I am only interested in SharePoint Administrator positions only... but somehow I still get reqs for SharePoint developer positions... to which I immediately delete, knowing that my current resume wasn't even opened by the recruiter.

3. An extra five minutes of looking at your resumes will yield you 5-10 times better candidate proposals to your hiring managers. The hiring managers employ you to present qualified candidates and to separate out the wheat from the chaffe so they don't have to. Read the resumes!


No comments:

Post a Comment