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.


The Problem With SharePoint Recruiters

I swear to god, 1/2 of the recruiters that contact me for SharePoint gigs don’t even know what the hell they are talking about. It’s ridiculous, and seriously makes you question who pays these people actual money (or if HR people just work to acquire the blood of animals to drink it like I always assumed they do). I want to be a recruiter for SharePoint projects, then I can randomly bang my face on a keyboard and then hit send. The end result would probably be more compelling than the messages that I receive, and most likely make a lot more sense.

For example, here is a letter that I received from a recruiter at TekSystems (whom I would rather saw off and eat my own arm rather than work for) that I got today (actually, 5 minutes before which spawned this post):

I have a 3 month opportunity in Green Bay, Wisconsin for an Internet Data Architech-Sharepoint with United Health Care. The selected individual will work along with the UHG technical architect for the ADR application in migrating an existing SharePoint application in SharePoint Portal Server 2003 to the WSS 2.0 Platform. The candidate will be expected to provide technical leadership in this migration activity and also have the capability to be a hands-on active contributor in the migration process.

The Core Skills Needed are:

* Expert knowledge of Portal Server 2003 and WSS 2.0 platform
* Experience in development and deployment of custom SharePoint
applications in the above platforms.
* Deep Understanding of the database schemas used by SharePoint
platforms of the above products and knowledge of migration of schemas
between different instances of database platforms such as SQL Server
2000 and SQL Server 2005
*Experience in the infrastructure planning and deployment of
custom SharePoint applications.
* Experience in writing web parts for WSS 2.0 application

Ok, before we play the obvious spot-the-recruiter-mistake game, I would just like to point out that this Jennifer person either obligatorily doesn’t use spell check or is blind, or just attempting to piss me off in which case she hit her mark. I mean, besides the little annoyances in the letter like spelling SharePoint and then Sharepoint (the capital P way is the right way), she can’t even spell the word architect. How can you be a technical recruiter (which was in her signature) when you can’t even spell the word architect. That’s like me being a developer and consistently spelling the word “new” wrong so that my object statements instead went SPSite site = mmmeeeeeeoooowwww SPSite(); Besides the fact it wouldn’t compile, it just makes me really, really bad at my job. And people would make fun of me.

Ok, so can you spot the huge problem with this email? If you can’t and you work with SharePoint, you should immediately go acquire an appropriate length of rope.
1) SharePoint Portal Server 2003 to WSS 2.0? Eh, what? What the hell are you talking about Jennifer? Besides the fact that you would pretty much just end up doing a raw content migration in that case, why would you want to migrate an already standing up instance whom I HAVE to assume is paid for (United Health Care is a large company, and clearly would have really, really deep pockets). That makes a lot of sense. Nice!

2) Ok, ok. I’m being harsh. Jennifer obviously meant WSS 3.0. That’s cool Jenny, I won’t bag on you anymore. Hmmmmmm, so you want to migrate SharePoint Portal Server 2003 to WSS 3.0? That’s great! Oh, I mean besides the fact that is completely unsupported, per MSFT’s words “The only valid upgrade path for SharePoint Portal Server 2003 is to Office SharePoint Server 2007”. Before you send some crap like this, would you care to use the amazing piece of technology called a search engine? I know, its a scary thing.

Anyways, I am done venting about this. I guess the only reason that I get so mad is the fact that recruiters have a really, really specific job, and most of them when it comes to SharePoint are just fucking terrible at it.


15 Ways / Questions To A Smooth SharePoint Contract

We have all been burned on contracts (well most of us I suppose, I have a whole lot), predominantly prevalent with SharePoint projects because it seems like the skill set pool for an experienced SharePoint developer is particularly thin, and recruiters / human resources staff in organizations are ready to sell their mortal souls and lie their ass off to get you to join a team. I am not blaming them I guess, you sometimes have to do questionable things to fulfill your job role within empirical ethic boundaries, even though sometimes they appear to skirt them.

While it is nice to feel this popular and wanted, you often end up joining a team where if you are a pretty talented SharePoint developer, and you thought you would have a nice position where you would get to do higher visibility development tasks and delegation, you are instead stuck in a corner, sweat shopping out uninteresting class development that no one else wants to do.

Here are 15 ways / questions, which I have learned during the contract negotiation phase, to ask / do before taking any SharePoint contract so that you can avoid working in the broom closest with no air conditioning, next to decomposing drywall, with a rat who you end up naming because he becomes your only friend and contact for the next half a year. This kind of starts with the general business stuff, and get into the more technical stuff into the end, so if you are looking for the technical things, you can skip to the bottom.

1) If you are interviewing / negotiating for a consulting company that farms you out to a client, ASK IF THEY HAVE A SECURED / ACCEPTED BID ON THE CONTRACT!!!

This is important, very important because it effects your probable paycheck and therefore your ability to support your family. Consulting companies in my experience will try to staff personnel resources that are commendable and noted for a skill set before they actually secure a bid on a contract to increase the fluidity of the sale and increase the probability that their bid will be accepted. This is bad news bear for you though if they don’t get the contract, since you will either be benched or let go faster than a greased panther, depending on the parameters of the contract that you are going to sign (whether you go FTE, or doing a strict 10-99 deal). Just make sure they are hiring you for something running and secured, not something THEY PLAN ON doing. Contrary to popular belief, this is not an illegal thing to ask during a contract negotiation or an interview process.

2) It may look benign, stupendous even, and you should already be doing this, but actually read the damn contract thoroughly, completely, and infer as much as you can. Although skimming it makes you feel cool in front of the suits hiring you, it is a stupid move. ASK QUESTIONS!!!

And if they are offering you a sign-on bonus, read it with an even greater detail and attention to detail. Typically, they will hook you for the sign on bonus and then you are stuck in somewhere like Beirut ducking mortar shells trying to changing all your ArrayLists to List generics for a WebPart. Ye Ha!

3) Check the History of the Company on

There are a lot of unbiased opinions of companies that are available on from people that have worked through past headhunters or for those exact larger companies that you are negotiating with. Can really be a lifesaver, since the people that are posting on it have either already been staffed there, or have had some sort of relationship with the company already, and really don’t have a ton to gain by posting something either good or bad. There might be other sites for this that I don’t know about, post in the comments of this post if you know of any that would be helpful for other people.

4) Ask Whether This Is the Organizations First SharePoint Project

If it is, you are probably going to have to play the role of the management assistant as well as being subject to any development tasks. Expect to sit in meetings while a clueless PM lurks over at you for any semi-technical question. Generally, I try to pass on these contracts, unless the bill rate is enough to cure world hunger since requirements tend to be loose and scope creep is fairly constant since the PM will assume immediately that you can do everything and do an obligatory “yes sir” for anything the client asks for. At least you get to feel cool and capable.

5) Ask If The Same Team Will be Used throughout the Duration of the Project Lifecycle

This irks me a lot; you establish a bunch of relationships with people, and all of sudden three months later you have to do it again with a brand new team. It is preferable, at least to me personally, that you are with the same team during the duration of the project. Think about it, you just spent 300 bucks buying people drinks at night that you are never going to see again, how bad does that suck?

6) Ask If They Are Outsourcing

If they are, make sure that you are compensated suitably because you will be staying up generally pretty ludicrous hours in the evening, so you should be paid for your time you are working at home. That and you will be doing a whole lot of code reviews, and will be on the receiving end for a lot of code hand off that you may or may not have to end up retrofitting to a lot of organizational development standards.

7) Ask How They Arbitrarily Manage Projects, Generally (SDLC, etc.)

This is so important. Although it doesn’t have to be a deal breaker, it can really make your life miserable if you practice Agile SDLC concepts and the organization enforces a CMMI software development model. Outside of the SDLC query, you should ask the architecture of how they typically manage a project from inception, to requirements, to delivery. If there is no PM assigned, be ready to interface with clients all day. If there is no program manager, be prepared to handle a lot of budget things. If there is none of the above, you’re a one man show, and I don’t envy you that much.

8) Ask About The CLIENT DRESS CODE. Not The Dress Code At Corporate.

Corporate may let you come in your birthday suit swinging in the wind; however the client may want you to come on with a three-piece pin strip suit everyday looking like John Gotti. I wear flip-flops to work everyday, and it is something I ask right away, since I really hate wearing shoes. I also push the limits and always ask if I can wear a hat. Just ask about the clothes your feel comfortable in, no one likes developing in a something fit to attend a funeral in.

9) Ask How They Will Review Your Code

If they just kind brow you after asking this question, you might have some trouble, because your efforts are not going to incredibly visible to the people signing your check. Sometimes complex business problems doesn’t have an insane amount of visibility (like if you are doing a Workflow project that automates a lot of legacy business processes that just automate redundant tasks), so it is important that at least someone knows that you aren’t just sitting around and playing FreeCell all day. Just make sure you have SOMEONE that you can show, and who understands, your deliverables.

10) Ask If There Is an Hour Cap

This is important, try to cap off your hours, you aren’t a slave. People always try to squeeze the most that they can out of developers, and they will really exploit you if you don’t get an hour cap. Write this into your contract, so that if the cap expires, you get paid overtime, or there is some sort of bonus structure setup. What it breaks down to is, GET PAID FOR YOUR WORK.

11) Ask If They Have a Standardized SharePoint Development Image

If you are a tools person, not asking this will kill you. They might have enterprise templates for Visual Studio that they are using, or some other development control mechanism, and you will be stuck with what you have. If they don’t, ask if you can use your own image for development since you already have all your tools, etc. on it and it generally makes you more productive. And if they say no, ask about the length of time that you are afforded to put together your SharePoint VPC. We all know that this can take a freakin eon even if everything does go smoothly, and if you have to report your work accomplishments at the end of the week they are aware why you didn’t write a line of code.

12) Ask About the Method of Source Control That Contractors Use

This is important because if you are keeping it on your laptop, you are in jeopardy of losing a lot of money. Your laptop could get stolen, and then you have nothing to deliver to the client, and they will argue with you, or your sponsor, that they shouldn’t have to pay for anything that they never received. If they have an internal one, make sure you use it as diligently as you would for a corporate position. It also lets the client track your progress without having to come talk to you, which is nice.

13) Ask About Code Documentation

If they say they don’t require any, that is great, and get ready for maintenance extension on your contract (personal opinion). If they say you have to document it in all in Word, I meant re-think the contract unless it is a fairly thin amount that is expected, because you will be a whole lot of maintenance on the documentation itself. If they have no clue what you are talking about, use Ndoc and the will be impressed with your deliverables, and you will probably get an extension as well because it looks all nice and complicated. Just ask so you know what to expect.

14) Ask Where You Will Be Located, In the Building Wise and Where The Building Is Located

This is important. Since you will be a temporary employee, you might end up next to the water heater with a milk crate to sit on if you don’t agree on something beforehand. But, on the good end you will become friends with the janitor. Check out around the building too, if you are like me, you want to be able to walk to a place to decompress during the day (need the Bucks baby!), and make sure there is a Smokers Output if you smoke (I do, this is clutch).

15) Ask About Any Third Party Software They Are Using For SharePoint Development

Because it really may not tickle your fancy. If you were recently burned by a particular set of software, and they are relying on it for like interface components on WebParts, you are probably going to have to use it. If they have spent a lot of money on a control set, they are probably going to want you to use them, even though you might not very productive with them. Its better to find out about these possible issues before they become a problem.

Hopefully this is a good start that other people have some input on. It was at least kind of fun to write.