SharePoint Recruiters Shouldn’t Suck At Their Jobs

Generally that is what I am discovering is the case, however terse that may appear. I normally don’t peruse recruiter sites, except I got this outlandishly awesome job offer housed in one. Before I knew it, I was searching for absolute randomness on the site for fun. As I was browsing for SharePoint jobs, I established what looked to be the average SharePoint job ad, and I chuckled a bit.

I will in fact copy and paste it directly from the offered advertisement text:

SharePoint Programmer / Developer / Architect: Must have at least 7 years practical work experience in C# with building solutions on top of SharePoint. 7 years Java experience to support conversions of J2EE to .NET solutions. To support this role, 5 years of Oracle and Delphi experience preferred. 5 years experience required with MFC/ATL and Crystal Reports.

Must have 5 years of deep architectural experience with building large SharePoint farms, and administrating them in the same capacity including deployed custom development. Several years architecting and developing against ISA and MIIS preferred and encouraged, however not required.

Interestingly enough, on recruiter sites you are able to spot precisely when the job was posted. The antiquated date appended to this made sense to me since this particular position has been open for over half a year, borderline 8 months. And I will wager that no sensible applicant has dared to apply to this gobbledygook.


Because not only does the ad undoubtedly convey that the posting recruiter did inadequate technical research because of the erroneousness of technical dating (which offends job seekers btw), but they must be looking for the fabled nine armed, four brained mythical programmer that they prophecies foretell of, because for all intents and purposes those requirements are outrageous.

First, let’s pick apart the ad.

7 years of C# development experience, while being feasible, is marvelously atypical since the establishment of the C# language in common commercial markets is roughly in late 2000. So, this organization is most likely looking for a C# beta tester for when Anders Hejlsberg was still calling it code name Cool. Needless to say, this would be exceptional and uncommon.

7 years of .NET development on top of SharePoint I can see being a qualification, if STS (2001) development actually used .NET. Then it would be cool. But it didn’t. So the basic arithmetic of the recruiter sucks. Even then, you would be subject to the same time considerations as described above, making it not necessarily common.

5 years experience with MFC/ATL? Huh? I mean, I did MFC / ATL programming for a long time (it paid for college), and I have to admit I really don’t use that skill set outside of the far reaching development concepts very often. It just isn’t obligatory for ordinary SharePoint business development (note the use of the word ordinary there).

I actually can understand the Crystal Reports one. I guess. I mean I don’t use it, but it seems like in some circles it could be interpreted as a pragmatic requirement. I guess.

The conversions requirement made me sort of laugh, since that is a pretty specific skill set to want out of a developer. Because of this, as well as the larger noted SharePoint development experience, I think the organization might be more successful with breaking this into two separate jobs. To me, it’s kind of like walking into a barbershop, getting a haircut, and then asking why the barber didn’t go wash your car and walk the dog. Lazy bastard. I think coupling a C# developer that has rudimentary Java skills with a Java developer with basic C# skills would produce higher quality code conversion, most likely in a more reasonable time frame since those two programming schools tend to stay siloed in their language of choice. Even though in my experience code conversions just end up being a software rewrite anyways.

When the recruiter starts to talk about wanting the SharePoint developer, architect, and administration full package, I start to get a little frustrated. While there are certainly people that can wear all these hats, very well too, generally they become too busy divvying themselves up between tasks spawned from owning those assorted roles habitually those tasks never near completion. Only little increments are accomplished, never leading to closing. People often times like to specialize in a certain aspect additionally, and pride themselves in knowing all the ins and outs of that niche. I like doing architecture, but I love doing development. Furthermore, I simply loathe administration. It doesn’t mean I can’t do it; I just don’t enjoy it as a job role. It doesn’t blow my hair back.

The ISA and MIIS requirements are asinine if it is anything but a proof of concept or a small deployment. This should be principally noted with the MIIS requirement; the recruiter should be looking for someone that continually focuses on identity management systems when standing that up. Knowing those concepts to the metal vastly increases chance of project success. Like I said in a previous point, you don’t ask your barber to cut your grass. Unless your barber is just genuinely charitable and bored.

Consequently what happens when you are the recruiter that placed this ad out into the wild? You do a dance of joy because low and behold you found a hidden genius that satisfies hopeless requirements (not just meaning that they are hard, they really are impossible)! Yeah! Diamond in the rough! You rule! And he is willing to do it for 40k a year!

But what does your organization end up with?

The quintessential, yesss-sssir guy, whom only has the qualification of being a professional impostor and habitual liar. Fundamentally you have someone with an archetypal psychological complex tailored around satisfying people even though that satisfaction is bogus. Meaning, they are full of shit. I am not saying that to satisfy all the requirements is impossible (assuming that technology timeframes were right). It’s not, however it is decidedly unlikely. More than likely, they might *know* these buzzwords, read about it a bit, but don’t have deep experience. I have minimal Delphi experience, and very, very brief Oracle experience. Although I have used these, I don’t list them as skill sets of mine. I am not proficient enough. If they were mentioned at a job interview as required, I would throw sand in the interviewer’s eyes and flee on foot.

So I propose the following to SharePoint recruiters…

Firstly, be sensible with your project needs. I know it would be nice to have a methamphetamine IV feed developer that consistently practiced other technology facets locked in the closet that only required fish heads for substance doing your project work. I wouldn’t mind one of those myself. But it isn’t rational. When defining roles for a SharePoint implementation during the project planning process, it is healthier to have more jobs divvied up based on specialization rather than constrained numbers trying to overexert themselves out of their specialty. The former has proven, at least in my personal experience, while taking a large toll on budget tends to lead to enhanced quality of deliverables and probability of aggregate project success.

Secondly, tailor their SharePoint job ads to be more specific. Don’t be so vague. You clearly have a project, with a defined project scope (hopefully), project WBS’s (even though you are mocking people), and other project documentation. I don’t understand why this isn’t kept in mind when you are making your staffing decisions. I appreciate keeping it ambiguous because who doesn’t like the brain-surgeon-that-worked-charities-while-saving-puppies-from-burning-houses-but-now-does-awesome-SharePoint-development-guy, but your advertisement requirements are not practical. One of the most important portions of project planning is to define the roles filled by project team members and the responsibility of each role. I really doubt that there is just one role defined as everything besides the project manager.

Lastly, for Christ’s sake, research the technology that you are advertising for. You don’t have to know it very well, you just have to know it enough to *find* someone that knows it a whole lot more than you do. If I wanted to find a good dairy farmer to get some milk, I don’t have to know how to milk a cow or manage a farm, I just have to know the basics of the milk I want. The same goes when you are building technology requirements. Kinda.


I Might Be Writing A Book On ILM

I *might* be writing a book on Identity Lifecycle Manger 2007 and its inherent components (its brought over functionality from MIIS, and Certificate Lifecycle Manager) for a new publishing company. I am not sure, I am still putting together the abstract for the Acquisitions Editor.

I hate, HATE that there was not a single good book out there for MIIS. It drove me up the wall. I hope to kinda close that gap if I get this deal closed, and maybe save some people a whole lot of time.

We will have to see what happens!


What is ISA server, and what does it have to do with SharePoint?


* This article was written in the context of Internet Security and Acceleration (ISA) 2006, a technology now considered deprecated with the introduction of Forefront Threat Management Gateway (TMG). Variations may exist. *

The Several Hat of the SharePoint Administrator


Often times, one person is tasked within an organization to be responsible for several platforms. If you have MOSS 2007, you also might have a range of other sister server platforms such as EPM, DPM, LCS, MIIS, or a variety of supplementary Microsoft platforms. The one server that is characteristically common within an external, as well as internal, facing SharePoint deployment is ISA server 2006 for its inherent security routines and web caching solutions, along with several other security options that can be typically of interest to SharePoint administrators such as honey pots and intrusion detection systems.
What is ISA server 2006?
ISA Server 2006 plays a very vital role with your enterprise, particularly when leveraging its security framework with your communications and collaborations platform since business critical data and enterprise processes will eventually be housed there. In relation to SharePoint, the main feature that we are looking to implement will be secure application publishing, in the current circumstance, MOSS 2007 (or SharePoint 2003 if currently not planning on an upgrade). It is important to realize that ISA has several other purposes and applications within an enterprise, however since the context of this site is SharePoint security, the main focus will be on leveraging ISA to securely use a SharePoint framework.
Mitigating Risks Leveraging ISA Server 2006 in Regards To MOSS (SharePoint 2007)
As part of any integrated security planning and implementation, it is necessary to take certain precautions to mitigate several risks to protect your corporate network. Implementing SharePoint within your environment can have several implications, depending on the context of what features an organization seeks to gain out of a SharePoint rollout. However, it is clear that several legacy business processes when it becomes a de facto standard within an organization will be placed moved from paper to electronic, streamlining them, but also placing them in a container with more points of access for an attacker to take advantage of. Bring processes out of the physical realm a majority of the times will cause more visibility into them, therefore bringing other points of access for an attacker to expose. This becomes increasingly important if you have any type of compliance or regulatory issues that will effect your business operations, SOX and HIPPA being the most common in relation to SharePoint and because SharePoint is so common within the healthcare field. This by no means implies that there aren’t other regulations to consider when implementing SharePoint, specifically within governmental and financial fields (such as consideration of the US Patriot Act), all of which should be examined prior to the rollout to ensure complete compliance upon initialization of the implementation.
Protecting Against Exposure in Regards to MOSS Mobility Controls
Because of the built in mobility controls with SharePoint, this risk becomes even greater since it will allow you to expose your portal at a more granular and prevalent level (those directories that exist within /m), carrying its own application richness nevertheless its own implications. Combining this valuable mobile functionality with the probability with a new external (or internal portal that may face attacks) facing functionality leveraging the numerous new SharePoint authentication controls (authentication in MOSS has more internet style controls), there is a higher possibility that an attacker will try to take over your portal.
Why Even Attack SharePoint? 
So why is SharePoint a lucrative attack point for a person with malicious intent to gain access into, and possible corrupt. There are two main points of interest from an attacker standpoint in relation to SharePoint. Since SharePoint plays the role of an information repository, an attacker could potentially desire to gain business information for a multitude of arbitrary reasons. This could range from a lot of different points of interest, from blackmailing a company to gain this information back to a secondary company getting a competitive advantage onto another company. The second main reason is corporate espionage, taking down SharePoint, on a large scale could cause business interruptions, massive loss of data, or a platform to attack other sister server systems that might house the same type of sensitive information. For example, with the archiving agent with Live Communication Server it is feasible that once an attack gains a point of entry within the SharePoint environment that they may also have access to these archived records, which could expose a business further, or have an employee possibly covering their tracks from past malicious intent.
What Are the Benefits of Implementing ISA server with SharePoint?
  1. Enabling and monitoring access to SharePoint
  2. Implementing cryptographic solutions
  3. Leveraging Web Farms and Load Balancing
  4. Providing Secure and Fluid External Access to your SharePoint Portal
  5. Implementing Several Types of Access Such As Smart Cards and Biometrics
  6. Track User Traffic
  7. Implement Plug-ins such as Intrusion Detection, Honey pots, and Other Functionality
What are the benefits of leveraging ISA server 2006 with SharePoint 2003 or MOSS (SharePoint 2007)? There are several, in regards to SharePoint there are clear hooks that exist between SharePoint and ISA that allow you to face your portal in a variety of fashions depending on your corporate need. One of the largest problems when leveraging ISA server 2004 was that although the process of setting up listeners and routing was straightforward, SharePoint implementations were never very generic and varied to heavily for a standardized process, however with ISA server 2006, publishing your communications and collaborations network including exchange and ISA server are extremely simple.  The second largest problem was setting up a secure implementation that leveraged a certain level of cryptographic methods, most notably SSL. However, as attacks become more sophisticated, it becomes possibly to implement cryptographic cloaking which can overcome packet inspection at the firewall level, compromising communications. However, ISA server with advanced SSL bridging allows an administrator to further protect a network while maintaining stateful packet inspection. Thirdly, SharePoint implementations often take advantage of sophisticated farming solutions that can exist in the amount of n servers, Web Publishing Load Balancing can make this easier to execute with a SharePoint environment. Fourthly, facing a SharePoint portal externally for 24×7 employee access is fairly common since it becomes a platform to build virtual teams with throughout the enterprise. This poses a multitude of problems, including but not limited to several windows of access (multiple logins) and pass-through link translation from multiple levels. ISA provides mechanisms to solve all of this, to ensure constant and fluid access to your SharePoint Portal at all times. Fifthly, providing mechanisms for several types of access, such as those with Smart Cards, is necessary within several organizations, particularly those within the governmental sector. ISA helps to translate these authentication types into your portal so that the facilities exist so that there are adaptable ways to authenticate to the portal. Sixthly, maintaining inspection and providing mechanisms to properly troubleshoot ISA, and authentication to your portal related problems, usually requiring using tools such as the SSL diagnostic tools or other third party products. ISA provides interfaces to your requested and responded packets so that you can properly implement and repair any issues that may arise within your network related to your security and web caching solution so that you can ensure that your portal is always secure, yet available. Seventhly, and lastly, ISA provides mechanisms to monitor and report on traffic within your SharePoint portal so that as a SharePoint administrator at all times you can watch traffic footprints and report on any problems as they may arise. These ISA interfaces are not technically difficult to invoke and massage to gain insight to certain activities, ensuring security of your portal at all times and providing faculties by which a SharePoint administrator can report on portal activities.
Maintaining Stateful Packet Inspection
One of the largest security mechanisms used with corporate network security in regards to publishing SharePoint servers is packet inspection through HTTP protocols, it is pretty default or is hopefully part of the current network configuration. This is related to the firewall level, and therefore is not typically aware of malicious activity at the application level, so therefore is indifferent to any type of attacks that would happen against your SharePoint environment at that particular level. The main feature that we need is stateful packet inspection that will promote application layer filtering mechanisms since this will make our security configuration more aware of our communications and collaborations platforms.