Monday, October 14, 2013

SharePoint Developer Resumes

As a SharePoint developer/architect, I have had to review dozens of resumes of SharePoint developers. Here are a few tips I would like to recommend.

1. Your resume is your writing sample. Typos, misspellings, and grammar errors indicate that you didn't take your time proofreading your resume, you are not attentive to detail,  and/or you have some difficulties with your written communication - and this does not show you as a worthy candidate.

2. Ditto for the cover letter. Don't neglect your correspondence with the recruiters. You never know when your messages are forwarded to those people who read your resume - and if your writing is awkward and/or full of grammar errors, you are quite likely to be disqualified.

3. Make sure your resume is not too long.  I've seen a few consultants' resumes that were 14 pages long! It takes a lot of work to proofread and it is very easy for important content to get lost in such a long resume - and a lot of us who read resumes don't get to page fourteen (or even page seven, for that matter.)

4. ... but not too short, either.  You don't want to miss any selling points. Especially the ones that make your resume stand out. For an experienced developer, I think a good resume size is two to four pages.

5. The first page is the most important. Make sure your skills and the most recent experience are all mentioned on the first page. Remember, if the first page is so-so, the next page is not likely to be read.

6. Call each technology by its proper name. I've seen a lot of resumes that talk about "MOSS 2010," "SharePoint 2012," etc., and even some resumes where SharePoint is called "Share point." This shows lack of attention to detail. Not good.

7. Don't mention any obsolete technologies and certifications. Some candidates mention Java 2 or certificates in .NET Framework 1.1 in their resumes. This just wastes valuable space. A possible exception is SharePoint; if someone worked with SharePoint 2003 and mentioned it in her SharePoint developer resume, this shows that the person has a lot of experience with different versions of SharePoint and is able to appreciate the features that came in the most recent versions.

8. Make sure no sentence in your resume indicates you don't know what you're talking about. Some resumes contain sentences on how the candidate "designed OOTB features" or "designed SharePoint site templates." If I see this in anyone's resume, I take the former first lady's advice and just say no.

9. Watch what you copy from other people's resumes.  I've seen the same awkward sentence about the candidate's supposed experience appear in three or four resumes of other people; then I searched for that sentence on Google and found a lot of other resumes containing this very sentence. If the candidate cannot describe his or her experience in his or her own words, he or she probably won't do so well on the interview - and thus it is not worth talking to him or her further.

10. Don't make your resume a laundry list. This makes the resume too long and too boring. Instead of listing every little thing you worked on, you'd be better off listing your accomplishments and what you did with SharePoint and other technologies to contribute to the projects you worked on. Keep it brief and to the point. Remember, your goal is to get whoever reads your resume to be interested in your resume enough to call you and invite you to an interview.

11. In particular, don't list the trivial stuff. I've actually seen resumes where the candidate talked about how he or she created document libraries or sub-sites. If you did it via the UI, it is really a user task, not a developer task; if you did it programmatically, it is still way too trivial to be mentioned in your resume.

12. ... but do mention the interesting things you did. If you integrated SharePoint with some other systems such as SAP, make sure you mention it. If you wrote your own service application, make sure you mention it. If you designed some nontrivial workflow, make sure you mention it. Not only does it make your resume stand out, it also leads to interesting interview questions later on (and when I interview candidates, I like the ones with who I can have an interesting discussion.)

13. If you mentioned something in your resume, be prepared to discuss it during the interview. If you're calling yourself a SharePoint workflow expert in your resume, it is a fair game for me to ask you questions about what a replicator is or how to debug a workflow. If you cannot answer these questions correctly, it makes me wonder where else you are overselling yourself in your resume.

14. If you seek a development position, make sure your resume shows off your development experience. I've seen some resumes where the candidate for a development position seemed more like an admin or a power user than a developer. This can indicate a poor fit.

15. Don't forget about the education section. It is always nice to interview educated people. If you went to a good school, make sure the education section is prominently listed on your resume (if you graduated fairly recently, you might even want to put the education section on the first page.)

16. Keep irrelevant things off your resume. Don't list things such as your birthplace, marital status, hobbies, etc. on your resume. None of these things will help you get invited to an interview.

17. Keep the less important stuff on the last page. I usually put my citizenship, security clearance, membership in professional organizations, and foreign languages on the last page.

If you are looking for a SharePoint developer position (mid-level or senior) and are in Northern Virginia, you're most welcome to send me your resume. We have a few very good opportunities here.

Thursday, September 19, 2013

Identifying Problem Publishing Image Libraries

The problem:

In one of my previous posts (http://kiwiboris.blogspot.com/2013/08/migrating-publishing-images-libraries.html) I talked about publishing images libraries and how the images from these libraries might need to be re-migrated and the specific steps needed to create such libraries and perform the migration. It is nice, however, to identify all such problem libraries in every site collection on the farm. Usually, when these libraries are not migrated correctly, one of the symptoms is that each image is checked out by the farm admin (the reason is that since the metadata for these images is faulty they cannot be checked in.)

The solution:

First of all, it is useful to remember that the base template for the publishing images library is 851 (fa propos, it is 850 for the publishing pages library.) Also, we are only interested in the libraries that have at least one item, each of them checked out. The following script will do the job:

cls

$w = Get-SPSite "https://main.coolsite.myserver.com"
$wa = $w.WebApplication

$wa.Sites | % {
   $_.AllWebs | % {
    $_.Lists | Where-Object { $_.BaseTemplate -eq 851 -and $_.Items.Count -gt 0} | % {
       $itemsCheckedOutCount = $_.Items | Where-Object { $_.File.CheckOutType -ne "None" } | Measure-Object
       if ($itemsCheckedOutCount.Count -eq $_.Items.Count)
       {
            Write-Host "All the images in the document library" $_.Title "in site" $_.ParentWeb.URL "are checked out"
       }
    }
   }
}

$w.Dispose()

Tuesday, August 27, 2013

Unknown Feature in Site Template

The problem

You are trying to create a site according to some site template, and then you're getting this error:



You have no idea what feature is mentioned, and you want to activate it ASAP.


The solution

This script will work:

$a = (Get-SPFeature | Where-Object { $_.ID -eq "e978b1a6-8de7-49d0-8600-09a250354e14" })
Enable-SPFeature -identity $a.Id -url https://main.yourserver.com/sites/yoursite

Thursday, August 15, 2013

Migrating Publishing Images Libraries

The problem:

A team site was migrated from SharePoint 2007 to SharePoint 2010 using the Metalogix Content Matrix tool. After the migration, one of the users discovered that every image in the Images library is checked out by the farm administrator and not visible.

Attempting to remigrate the problem libraries resulted in an error, "One or more field types are not installed properly. Go to the list settings page to delete these fields."

The solution:

First of all, let's clarify what the Images library is. It is NOT a picture library; rather, it is a document library that is created by the Publishing site feature when this feature is activated. Also, it is usually not a good idea to use the Images library for storing your own images - see this link, http://social.technet.microsoft.com/Forums/sharepoint/en-US/7713e6b9-bf0e-418f-a857-960890839d81/what-is-the-difference-between-a-sharepoint-publishing-images-folder-and-a-picture-library .

Second, this library (just like other libraries created by the Publishing feature, such as Pages) supports item scheduling. If the versioning settings are configured so that both major and minor versions are created, and the submitted items require content approval, you can enable scheduling for the library by going to the "Manage Item Scheduling" link of the list settings and checking the "Enable scheduling of items in this list" checkbox. This adds two new columns to the library, "Scheduling Start Date" and "Scheduling End Date," of the types "Publishing Schedule Start Date" and "Publishing Schedule End Date," respectively.

The problem is that when you migrate such a library using the Metalogix Content Matrix tool, the scheduling of the library does not seem to migrate correctly. Therefore, in the SharePoint 2010 environment we need to carry out some additional steps. Here is what worked for us:

1) If the Publishing feature is not enabled on the SharePoint 2010 environment, delete the Images library.
2) Activate the Publishing feature. This will re-create the Images library. Note that this library is much richer in SharePoint 2010 than in SharePoint 2007, as it supports content types such as Audio and Video.
3) In the new Images library, make sure that the versioning settings are configured correctly (i.e., both major and minor versions are created, and all submitted items require content approval.)
4) Enable item scheduling for the Images library.
5) Re-migrate the images from the SharePoint 2007 Images library to the SharePoint 2010 Images library. Make sure you only migrate the items, not the list itself.

Thursday, August 8, 2013

Migrating a Multiterabyte Site Collection

The problem

A certain site collection grew too large (8TB, while the Microsoft-recommended limit is 100 GB), and it needs to be migrated to a SharePoint 2010 environment and split into many smaller site collections.

The solution

In this presentation, I show the approach my company (Exostar) took to solve this problem. The main idea is to use a third-party product (we recommend Metalogix) and to write automated scripts to be run in parallel.

Wednesday, August 7, 2013

Migration and Task Forms

The problem

We migrated a SharePoint 2007 site collection to SharePoint 2010, using the database attach method. This site collection contains a custom workflow with multiple task forms. After the migration, we found that one of the fields in the completed task forms is blank, even though it was a mandatory field that was indeed completed before the migration.

The solution

First of all, we needed to make sure that the data was there. The completed task form data is stored in the task's ExtendedProperty. So, we ran this script and made sure that the correct attribute was there:



cls

$tasks = $w.Lists["Tasks"]
$iscs  = $tasks.Items | Where-Object { $_.Title -eq "Some task on Some List Item."}
$iscs | % {
Write-Host " "
$_.Title
$_["ExtendedProperties"]
}

After we found that the data was stored correctly, the next task was to make sure that the InfoPath form was displaying this field correctly. Unfortunately, the InfoPath 2010 form had some problems with this field and would not display its value, even though the task's ItemMetadata.xml was perfectly correct.

The solution involved renaming the field in the InfoPath form, and then changing the migrated data so that the field is mentioned by its new name. Here is the PowerShell script that does the trick.

cls

$site = Get-SPSite "
https://main.myveryownsite.com/sites/somesite"

$webs = $site.AllWebs | Where-Object { $_.IsRootWeb -ne $true -and $_.WebTemplate.StartsWith("STS")} 

foreach ($web in $webs)
{
    $web.AllowUnsafeUpdates = $true

    Write-Host "Processing " $web.Url ", web template:" $web.WebTemplate
   
    $web.Lists | Where-Object { $_.BaseTemplate -eq [Microsoft.SharePoint.SPListTemplateType]::Tasks -and $_.Fields.ContainsField("ExtendedProperties") }  | % {
        Write-Host "  Task list" $_.Title " in web " $_.ParentWebUrl " contains ExtendedProperties - investigating..."
  
        $listItems = $_.Items
  
        $listItems | % {
       
                try
                {
                    $itemEP = $_["ExtendedProperties"]
             
                    if ($itemEP -ne $null -and $itemEP.Contains("ows_AuthoritiesComments"))
                    {
                        if ($_.Title.StartsWith("ISC Chairperson task on"))
                        {
                            $itemEP = $itemEP.Replace("ows_OldFieldName", "ows_NewFieldName");
                                                                                      
                            $_["ExtendedProperties"] = $itemEP
                  
                            Write-Host "      Trying to update " $_.Title " extended properties"
                            $_.SystemUpdate($false)
                            Write-Host "      Finished updating " $_.Title " extended properties"
                        }
                    }
                }
                catch [Exception] {
                        Write-Error $_.Exception.ToString()
                    }
            }
        }
        $web.AllowUnsafeUpdates = $false
        $web.Dispose()
}

Worked like a charm!