Not thinking about SharePoint just before a Tech Interview

Recently I had my last tech interview w/o directing the screener to my tech Blogs. In a nutshell the interview didn't go as well as it could've. The reason IMO was because I wasn't thinking about SharePoint just prior to the tech interview. In the future that's going to change. 1. I'll do some thinking/focusing on the specifics regarding the new opportunity. 2. I'll be sure to guide the screener to my Blogs.

I had been up since 5am and working all day in Visual Studio, solving IIS communication issues, looking at some class libraries that were having a problem integrating from SharePoint, helping some developers learn about the 4 key FeatureReceiver events & the reasons why you use try-catch in Activating/Deactivating and why you don't override the Installing/Uninstalling events, and solving some JQuery issues. So finally 5pm came and it was time for the phone interview.

The screener at the end said he was concerned that I didn't know much about Sharepoint. I asked why. He said because I didn't even know what the 6 pillars of SharePoint were. And he said that I didn't even know what the SharePoint web services are. He said it looked like I was just working on the types of projects that they don't do much of. I'm certainly not going to give out his name because I'm about the criticize him. IMO he obviously doesn't know how to do effective technical screens. The primary purpose of a technical screen is to validate the person's resume. Are they telling the truth? What types of skills do they have? And if you're hiring them for a position that's "perm" its especially important to find out what their aptitude is like and what things they want to do in the future.

BTW I did know what the 6 pillars of SharePoint were and what the SharePoint web services were. It was just a long day and I wasn't at my sharpest for the interview. And he never had specifically ask what the 6 pillars were.

In SP2007 the 6 pillars were: Collaboration, Portal, Enterprise Search, ECM, Business Process/Forms, Business Intelligence

In SP2010 the 6 pillars are: Communities, Sites, Search, Content Management, Composites, Insights

If I had spent the last 6 months being a SharePoint 2010 salesman then they'd probably be at the tip of my tongue. As luck would have it I've been focused on migrating some pretty complex/difficult applications from SP2007 to SP2010 so I haven't been thinking much about all the buzzwords. However I certainly have been deep in solving search/CM issues, helping site owners figure out wikis/blogs/tags/ratings/MySites/feeds, working with the Ribbon, javascript, integration, taxonomies, workflows, content types, records management, InfoPath, Excel Services, and Performance Point.

BTW see http://www.codebanking.com/articles/sharepoint/sharepoint-six-pillars.asp for a glance at the details.

The SharePoint web services are listed at http://msdn.microsoft.com/en-us/library/ee705814.aspx online.

For example, you can use the GetListCollection method in the http:///_vti_bin/Lists.asmx service to get a list of Lists\List XML nodes in an XML document whose ID/Title properties can be used to help me drill into a specific List object.

However I tend to prefer the more secure, compiled/fast alternative of accessing the Lists property of a SPWeb object I opened up directly with SPContext.Current (or indirectly with its site collection's SPSite object). I've learned with SharePoint that its vital to know how to do effective up-front analysis. That's because many tasks can be self-service, easily done by a site owner, or souped up together by an designer/analyst in SharePoint Designer. The harder stuff needs to be thrown into some sort of application. By default I'm opinionated on this. I prefer building robust ASP.Net user controls to throw into the controltemplates folder underneath the 14 hive (or 12 hive in SP2007 or SP2003). Then I wrap these using what I call the User Control Container Web Part (UCCWP). It has 2 custom properties called Control Path and Control Parameters. The Control Parameters property is a XML string which if set to "help" displays a 3-column grid in the content area listing all the parameters' names, example values, and HTML descriptions. The code for this is specified in the ascx.cs partial class method that implements the base class's HelpHtml method. Of course I've learned that I have to roll with the punches and check my ego at the door on any given engagement I'm working.

I also suppose it didn't help when I told him too much about my experience in customizing Microsoft's Application Lifecycle Management tools/components to integrate with SharePoint and other presentation layers such as traditional ASP.Net, WinForms, WCF, WPF, etc. because too many SharePoint developers think of TFS as being just Version Control like many people view SharePoint as being just a shared file system directory on the network.