One neat feature in SharePoint that I recently discovered is the ability to specify views specific to folder based content types in a list.
What's great about this is that if you're building a hierarchical store in a list with folder based content types, then you can have each level of the hierarchy display different views.
As an example, consider a school district.
They may map their classes like this:
- School A (Folder based CT)
- Grade A1 (Folder Based CT)
- Class A1.1 (Folder Based CT)
- Student A1.1.1 (Item Based CT)
- Student A1.1.2
- Class A1.2
- Grade A2
- School B
- Grade B1
- Grade B2
Now for each of the folder based content types, you can specify a view specific to that content type by using the DefaultViewForContentType="TRUE" and ContentTypeID attributes of View. For example, on the Grade level view, when a user selects a Grade, I would want to show a column called "Teacher" because in this view, I'm showing Class items. However, at the School level, "Teacher" doesn't make sense as a column.
Now none of this is all very difficult to figure out, however there are a few notes:
- To get this to work, you have to specify these values for EVERY view. If you don't, you will see that at each level of the hierarchy, you will have the view available, but the navigation will not automatically select that content type specific view.
- For the default view, you need to add it as 0x012001.
This is a great tip as it creates for a much better end-user experience by allowing them to have contextual views based on the current content type.
Yet another post on interviewing 🙂
As both an interviewer (mostly) and an interviewee on topics of SharePoint, I've been working on refining my questions and technique here to get right to the core of understanding a candidate's suitability.
As a general rule, I never start with "factoid" type questions and almost never bring them into an interview in the first place. I don't believe in quizzing on facts unless there is a very good reason since nowadays, unknown facts can be googled instantly anyways. Oddly enough, I only end up on factoids when I'm interviewing a very strong candidate. I generally run interviews with a "choose your own adventure" type of style -- no two candidates ever get the same exact questions. It works for me because I like to talk about technology and design in general.
That said, I've pretty much boiled it down to a very small set of questions that I start with to determine a candidate's level of expertise and suitability for a given role.
What do you think are some of the more interesting/significant/useful features in SharePoint 2010 compared to SharePoint 2007?
This is an open ended question and what it measures is a candidate's suitability for an architect or lead type role. The function of an architect or lead is to understand the platform and tool as a whole so thus they need to know what they can do with the tool and understand how to compose the components and capabilities into a set of solution patterns.
With this one question, you can pretty much weed out anyone who is not suitable for an architect or a lead. A good answer will run down a list of the core feature changes in 2010 compared to 2007 and a strong candidate will be able to identify 2-3 which she thinks are significant in her view.
The exact ones don't matter as it's a matter of opinion, but a strong candidate will be able to talk about it with detail. I will note that the ones that a candidate picks will help expose their strengths and leanings (enterprise content management, custom development, configuration, etc).
This question alone can carry you for 20-30 minutes of discussion.
Consider a scenario where you are developing a product that integrates with SharePoint and has a number of ASPX pages. You would like to implement a license check on every page to ensure compliance and show an error message if the license is invalid or not found. Give a high level design of how you would implement this.
Again, there are multiple ways to implement this but some ways are clearly better than others. What I'm looking for here is for the candidate to expose how she thinks about SharePoint as a platform.The first sub-question is where would she propose the license be stored? It can be stored in SharePoint itself, in the web.config, in the hive, as a persisted object, etc. -- but it is up to the candidate to justify and explain their choice. Whatever they choose, I point out a weakness and see how they respond 🙂 Strong candidates can defend their position or can see the weakness and will propose a workaround. Weak candidates get thrown off pretty easily.
The second sub-question is how the candidate would get the functionality on every page. The best and most straightforward answer is to create a base page which implements the license check and all pages inherit from the base page and automatically get the license check capability. There are other ways (perhaps an HttpModule?), but the point here is to see if they naturally think of inheritance to coalesce common functionality. It's really an inheritance question put into the context of a realistic scenario -- if you understand the goal, then you can create variations of this question that suit your use cases.
Consider a scenario where you develop a component and it requires modifications to the web.config file to work (i.e. custom HttpModule, custom HttpHandler, third party library). Can you propose a way to manage this at deployment time?
Again, a question with a lot of possible answers, but really only two optimal ones (SharePoint itself offers at least two ways of doing this and automatically propagating those changes across all servers in the farm). The key here is that most answers will be "I'd update it manually" but this is clearly a sub-optimal solution as a farm may have multiple servers in it and each will have to be updated. But I like this question because it's a "thinking" question, even if they don't know the answer from the framework perspective, you can tell if they are thinking about the question because some will realize that this is not manageable with a large farm and prone to errors (say 8 servers).
Of course, there are other more specific technical questions that I ask that are feature and role specific, but these three are really my "go to" questions. What do you think? Any other questions that you've found to be useful in interviewing for SharePoint candidates?