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.

Why?

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.

Share

6 thoughts on “SharePoint Recruiters Shouldn’t Suck At Their Jobs”

  1. Everything else about your article aside, I’ll point out that I’m in the admin/dev/architect role right now and it’s difficult to maintain minimal competency in any of the areas.

    The amount of written/published information grows daily, and the amount that still NEEDS to be published is larger yet.

    For example, your tidbit on logging–up to that point, I hadn’t read anywhere about logging seriously, outside of throwing SPExceptions to be caught in the ULS logs. And logging is pretty fundamental.

    So when I’m looking for information, even basic stuff like logging, a lot of it isn’t there. Now multiply this for each job role, especially so for the “architect” portion as it’s more of an art anyway–you’ll understand my frustration with all the ‘holes’ in what’s been published.

    And then something breaks on your farm, and you spend 4 days troubleshooting it, and most of the problems MS support handles are not published, so you end up wondering if you’re incompetent or if SharePoint really is broken and there was nothing you could do to prevent it from breaking (thankfully up to this point, it’s been unpreventable :). And searching the Internet is such a pain that I actually went out and built a search page
    http://www.pseale.com/SharePoint/search/
    to search EVERYWHERE. Because I do this more than any other time in my life, by far.

    And as I work for [unnamed for their protection], I get to see others in similar lower-dollar contracting roles, who aren’t as good at searching the collective, and end up doing something horrific. Just a few days ago I had to convince someone (over email) to NOT process a binary .xls spreadsheet via an item event receiver. We’re not talking Excel Services, we’re talking Excel COM on the server. I guess that’s an extreme example, but the point is: I think it’s a lot easier to be incompetent with SharePoint than it is to be competent, EVEN IF YOU ARE TRYING. SharePoint is huge, so you need to not only learn what is possible in SharePoint, but what should not be attempted. And if you’re not too interested in trying…

    Anyway, wow, this “little comment” diverted heavily. Needless to say I’ve felt some pain on this.

    Don’t quote me on the whole ‘minimal competence’ by the way :) I’m the greatest ever, all-time.

  2. ^^
    for post above .. the problem isnt sharepoint or developers it is technology, which has been changing for ever. I am not blaming on technology and i have seen my share of low wage contractors do that, but I have seen experienced guys stick to old basics all the time, not only 1.1 to 3.0 migration but technology in general, even beliefs like Javascript still does not hold key role in web technology

  3. So right…I have seen so many of those. And more annoying are the ones that contact me through linked in, or facebook or my blog or over the phone – because “they want to learn about sharepoint and I seem to be someone who knows what it is”. You want me to teach? pay me! don’t ask me to write you the sharepoint for dummies as a reply, or go out for “coffee” with you so I can do your research for you.

  4. Adam,

    I am actually a speciliast SharePoint recruiter in the UK, however, the problem is that most of the jobs are dealt with larger agencies that are not.

    My running joke is that most of these guys do not know the difference between the BDC and BBC!

    Sounds like I need to branch out the the US!!

  5. “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.”

    Adam – I very seldom laugh out loud when reading SharePoint posts, but you got me on that one. I hope you don’t mind me quoting you… the picture is just too perfect.

    Regards,
    Mark

Leave a Reply

Your email address will not be published. Required fields are marked *