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

Building SharePoint WebParts in Chrome and Delphi

Before you read this post, my code highlighter, GeSHi, doesn’t support Pascal highlighting. So, it is highlighted in generic syntax. I am 100% interested in getting community contributions on this subject. If you want to contribute to this subject, regarding SharePoint development outside of C# or VB.NET, please contact me at my personal email through the feedback page on the main site. I am most likely going to start a new article thread on the main sharepointsecurity.com site, or create a step-by-step downloadable guide for, that I will give interested people complete access to for posting hints, tips, and tricks with full credit, because this subject is sorely missing for people bridging into SharePoint development.

Anyways, here is my first attempt…

You might be a Delphi developer, or maybe a Chrome developer, sitting in your organization, sneaking in a game of WarCraft or something else, and just got charged by management with doing an obscene amount of SharePoint WebPart development for your organization.

No problem you think, I can handle this, it all comes out to the same MSIL doesn’t it? When starting to get your project going through, you may find that researching how to build a simple example SharePoint WebPart done in Delphi, or any other language outside of VB.NET or C#, is only mildly more frustrating than trying to figure out the cure for world hunger.

I was in the same situation. Before switching to C#, I primarily did VC++ development (I still program a majority of my web service code in VC++ too, as well as my entire shared class library for SAML is in VC++). If you are doing your SharePoint programming in your native language of choice, you are going to be up a creek sans paddle when trying to start out coding a simple WebPart.

This is, to me, is one of the primary reasons that developers get turned off to SharePoint development. So, being one that likes to use other programming languages (ok, maybe it is just VC++ but whatever), I decided to write up how to code a simple WebPart in a variety of other languages. There are so many tools to use languages like Pascal and Delphi within .NET applications, such as Hydra, and entirely too much to cover in just one post. I will expand this concept further with a more complex sample WebPart for other .NET compatible languages when I think of a suitable example. Probably something that interacts with the SharePoint Object Model heavily like SharePoint list displays or the likes.

Anyways, out of the two pieces in this article, I only know Delphi a little bit, have dabbled in Chrome, and found the example WebPart upon compilation worked fine for rendering out text that is manageable directly from a WebPart persistent property. I won’t reveal how long it took me to figure out the proper compilation sequences, because frankly it’s embrassing. This also doesn’t mean it is the right or the best practice code, so please contact me if I can correct or expand this content, as it would be a fun subject to contribute to.

If you are completely new to SharePoint development, I would encourage you to read this article on the main sharepointsecurity.com site in order to gain an understanding of the standard class inheritance, method overrides, and other things that go on with the WebPart. If you use some other .NET compliant language in your organization that I haven’t covered, shoot me an email and I will add to these examples. I would like to improve the amount of documentation that is available for all types of developers, and I think this is a good start.

In these examples, I am going to show you how to render out a string that is entered via a WebPart property, demonstrated through two different methods. Here is a screenshot of the final product (yeah, its not very impressive, but hey, its a start on this subject):

Both of these WebParts regardless of methods will be inheriting from the ASP.NET 2.0 WebPart base class (System.Web.UI.WebControls.WebPart) as opposed to the SharePoint WebPart (Microsoft.SharePoint.WebPartPages.WebPart) base class as a better practice.

The first method that will be demonstrated directly writes to the control stream using the property defined text in the overridden Render Method. The second method that will be shown will use a literal control declared in the CreateChildControls method and then the RenderChildern method to output the stream within the Render method.

Building a Simple SharePoint WebPart in Chrome

Method 1: Directly Output in Render Method

[code]
namespace  Example_WebPart;
interface
type
Example_WebPart = public class(WebPart)

{ WebPart Fields }
private _exampleText: String;

{ WebPart Methods }
method Example_WebPart.Render(writer: HtmlTextWriter);
begin
writer.&Write(self._exampleText)
end;

{ WebPart Properties }
[Category(‘Example Properties’), Personalizable(PersonalizationScope.Shared), WebBrowsable(true), WebDescription(‘Adam”s Example Text’), WebDisplayName(‘Adam”s Example Text For Output’)]
property exampleText: String read get_exampleText write set_exampleText;
end;
[/code]

Method 2: Render Out Literal Control in CreateChildControls and Call RenderChildern

[code]
namespace  Example_WebPart;
interface
type
Example_WebPart = public class(WebPart)

{ WebPart Fields }
private _exampleText: String;

{ WebPart Methods }
method Example_WebPart.CreateChildControls;
begin
inherited CreateChildControls;
self.Controls.&Add(new LiteralControl(self._exampleText))
end;

method Example_WebPart.Render(writer: HtmlTextWriter);
begin
self.RenderChildren(writer)
end;

{ WebPart Properties }
[Category(‘Example Properties’), Personalizable(PersonalizationScope.Shared), WebBrowsable(true), WebDescription(‘Adam”s Example Text’), WebDisplayName(‘Adam”s Example Text For Output’)]
property exampleText: String read get_exampleText write set_exampleText;
end;
[/code]

Building a Simple SharePoint WebPart in Delphi

Method 1: Directly Output in Render Method

[Delphi]
unit  Example_WebPart;
interface
type
public Example_WebPart = class(WebPart)

// WebPart Fields
strict private _exampleText: string;

// WebPart Properties
[Category(‘Example Properties’), Personalizable(PersonalizationScope.Shared), WebBrowsable(true), WebDescription(‘Adam”s Example Text’), WebDisplayName(‘Adam”s Example Text For Output’)]
public property exampleText: string read get_exampleText write set_exampleText;

// WebPart Methods
procedure Example_WebPart.Render(writer: HtmlTextWriter);
begin
writer.Write(self._exampleText)
end;

end;
[/Delphi]

Method 2: Render Out Literal Control in CreateChildControls and Call RenderChildern

[Delphi]
unit  Example_WebPart;
interface
type
public Example_WebPart = class(WebPart)

// WebPart Fields
strict private _exampleText: string;

// WebPart Properties
[Category(‘Example Properties’), Personalizable(PersonalizationScope.Shared), WebBrowsable(true), WebDescription(‘Adam”s Example Text’), WebDisplayName(‘Adam”s Example Text For Output’)]
public property exampleText: string read get_exampleText write set_exampleText;

// WebPart Methods
procedure Example_WebPart.CreateChildControls;
begin
inherited CreateChildControls;
self.Controls.Add(LiteralControl.Create(self._exampleText))
end;

procedure Example_WebPart.Render(writer: HtmlTextWriter);
begin
self.RenderChildren(writer)
end;

end;
[/Delphi]

Once you have your WebPart compiled into an executable binary, you can exploit 4 other files to deploy and manage your new WebPart: a .WebPart file, a solution manifest, a Feature file, and an elementManifest file.

The first XML file that you will use to deploy your WebPart is the WebPart file which provides all the descriptive elements relating to your WebPart:

[XML]




Cannot import Example_WebPart Web Part.

Example_WebPart


[/xml]

The next two files are the Feature.xml file and the elementManifest.xml file. This will be used to deploy the WebPart as a SharePoint feature. You will see that in the Feature.XML file, the elementManfiest.xml file as well as the .webpart file are both referenced within the ElementManifest element.

Feature.XML

[xml]

elementManifest.XML

[xml]





[/xml]

The last file to consider is the solution manifest, which allows you to wrap your SharePoint WebPart within a deployable SharePoint solution file. The SharePoint solution file will reference objects such as your SharePoint feature and the executing assemblies that should be included with your WebPart deployment.

[xml]












[/xml]

Share