I often maintain a list of skills and topics which I think are relevant to me and the kind of projects I’m involved in. I do this partly for my development and that of my team around me at Content and Code, but for other reasons too. As someone involved heavily in recruitment of technical people, some of this powers my list of current interview questions and what I look for in candidates. As such, I always thought publishing it would probably be a bad idea, because:
- The list is ever-changing – at the very least, it evolves every few months
- Recruiters (and candidates) would take advantage of this info
Call me cynical, but I know that in the UK market at least, recruiters do seek to boost the chances of their guy getting an interview by ensuring CVs are targeted to what is being looked for. Nothing wrong with that if everything stays honest - but I’ve seen quite a lot of cases where the truth is stretched too far. Fortunately not all recruiters use such tactics of course, but it can make the job of identifying good developers somewhat harder. Still, I found myself writing my skills/topics list on a whiteboard in a meeting the other day, and the idea of jotting it down somewhere public came to mind again. I now figure “Ah, what the hell – if a candidate actually *does* know all this stuff, then however they gained the knowledge I probably want to work with him/her anyway!” After all, seeing the list isn’t the same as having genuinely deep knowledge in each area. I’m not sure what other technical hirers do but, like the Microsoft exams, I personally take the ‘adaptive’ questioning approach – if the candidate appears to know a certain topic, I’ll do my best to keep asking questions to see just how deep the knowledge goes. I certainly don’t claim to be the world’s best developer, interviewer or anything else for that matter (and not even on my “strongest” topics!), but I often find I *can* establish where the limits of the candidate are for a given area.
Key skills/topics
So, anyway here’s my list – it’s just a dump from my OneNote notes rather than anything particularly structured. And there’s no special sequence or anything:
- Remote SharePoint/SharePoint Online development techniques
- .NET CSOM and JSOM
- Using CSOM in PowerShell
- The REST API
- The App Model
- Apps for SharePoint/Apps for Office
- Provider-hosted vs. SharePoint-hosted
- App authentication – context tokens/access tokens, app-only policy etc.
- Infrastructure requirements
- Office 365 apps
- App registration – and the App Launcher/My Apps page
- App authentication – ADAL and adal.js, the Common Consent framework, options for app-only tokens via a certificate
- Office 365 APIs and client libraries
- Deciding between Office 365 apps and Apps for SharePoint
- Deploying apps to Azure (both provider-hosted Apps for SharePoint/Office and Office 365 apps
- Protecting the app with Azure AD authentication
- Apps for SharePoint/Apps for Office
- OfficeDev
- The Patterns and Practices core libraries
- The Patterns and Practices samples
- Office 365
- Identity management options
- AAD Sync
- Hybrid
- Office 365 and Azure
- Azure AD
- How the "special" restricted Azure subscription behind an Office 365 tenancy works (i.e. just AAD)
- General SharePoint/SharePoint Online development
- Key building blocks for out-of-the-box solutions
- Search-based solutions - Content Search web part, search APIs etc.
- Managed Properties/Crawled Properties - provisioning (including differences in SharePoint Online), auto-created properties, using in search refiners etc.
- Display templates - provisioning templates, the end-to-end process of having values from a custom column displayed in a display template (via a custom Managed Property)
- JSLink
- Considerations around use of custom master pages, web templates etc.
- Branding options – Office 365 theming, alternate CSS, custom master pages etc.
- Azure
- Azure Web Apps (was Azure Websites) – development considerations, scaling models, deployment slots etc.
- Azure Web Jobs
- Azure SQL Database
- General web development
- Responsive design - level
- JavaScript
- jQuery (DOM manipulation, AJAX methods etc.)
- Patterns for OO JavaScript
- Promises
- Cross-domain issues and options
- Knockout.js
- Angular.js
- ASP.NET
- MVC
- WebAPI - especially:
- Calling from JavaScript
- Dealing with incoming/outgoing JSON
- Implementing a REST service
- Implementing CORS etc.
- Token-based authentication models
- Developing for performance - bundling and minification, page weight issues, useful tools etc.
- Yammer
- Yammer concepts - networks, groups, topics etc.
- Using Yammer Embed
- User sync (i.e. Yammer DSync)
No doubt this isn’t comprehensive and there are lots of items that could be added to this. Feel free to leave a comment if you think I’m missing something big :)
Summary – reflecting on this list
What’s interesting about this to me, is that if I’d written a similar list a couple of years ago it would be full of things like “web parts, timer jobs, event receivers, Feature XML” and lots of other SharePoint-only constructs. Some of these things can still be very relevant depending on the type of work you’re doing of course - but in general there are so many new concepts for most SharePoint developers in the last couple of years. Key themes here include general web development (i.e. non-SharePoint specific), new platform aspects such as Office 365 and Yammer, and Azure and Azure Active Directory (AAD) deserve a special mention since they become extremely important in the new world. For example, for Office 365 I highly recommend that even developers get their hands dirty with some infrastructure/platform aspects such as implementing domain integration and perhaps AAD Sync. After all, the production environment you’ll be targeting will probably use this configuration! Doing this in my dev environment certainly helped solidify my understanding of a few things – for example, what controls the attributes which are sync’d between the on-premises AD and Azure AD:
One thing is for sure – things have changed irreversably for SharePoint developers, and moving forward I think these types of changes will apply more and more to “on-premises only” SharePoint developers too. More details on SharePoint 2016 will be announced at Ignite very soon, and whilst we already know the full-trust/farm solutions model will live on, I think various aspects of cloud app development are likely to come into that world too. Exciting times my friends!
