Guest blogging during SharePoint Conference 2011

Dave Coleman at SharePointEduTech.com recently asked for guest bloggers to live blog throughout SharePoint Conference 2011.  I thought I'd offer my less-than-expertise for the week.  I'll be joining the ranks of far more experienced SharePoint professionals as:

Veronique Palmer
Joel Oleson
Erica Toelle
among others.

So make sure you check out Dave's blog and the guest bloggers Oct 1-Oct 8!

Tips for Recruiting Firms

Following with my hiring theme the last two days, I thought I'd address recruiters.  I've found a few over the years that I'll actually talk to when they call.  Then, there are the others.  The "others" come in a few styles, all of them annoying.  Here are the various types of recruiters:

1. Spam-cruiter:  You know these kind.  These are the ones that email you for jobs that don't make sense.  The jobs could be 3-month contracts half a country away or for some technology that's nowhere on your resume.  Thankfully, GMail has a great spam filter.

2. The Uniformed: These are the ones who just don't care enough to learn what they're trying to hire.  I've literally received a call for a "C pound" job.  No, I didn't just spell out "#," the guy actually thought that is the name of the language.  There's nothing wrong with admitting that you're not well-informed about a certain technology, but don't act like you know.  However, do some research.  No candidate expects a recruiter to be able to write the code, but he/she does expect to not be represented by a lazy idiot.

3. The Sleaze: Oh, this one is probably the worst of the bunch.  One of the tell-tale signs of this waste of oxygen is modifying your resume.  I'm not talking about branding it like everyone does, but will re-write part or all of your resume to really sell you.  Now, you may think that sounds like a deal, but odds are you'll be exposed in the interview.  This also happened to me early in my career.  Thankfully, I had a copy of my resume with me (the one I wrote).  I didn't get the job anyway, but I did find out that the company stopped using that recruiting firm. 

4. Means well, but overworked: This recruiter is not in the top three and would be a Class A recruiter, but they have a hard time returning calls.  Typically, these wind up as my Class B.  My B's are who I call after a couple of weeks without any leads from my A's.

5. Grade A's: These are good all around.  They know you, either because they've met with you (probably a free lunch) or at least talked to you on the phone long enough to get know you.  They usually have something that would interest you or will try to sell you proactively.  When you call and leave a message, odds are you get a call back within 24 hours.  Hold on to these recruiters as they'll take care of you at least once.

If you're a St. Louis technologist looking for a job and want a contact from my Grade A's, I'll share.  Just post with an email and I'll send them to you.

Recruiters, check yourself against this list.  If you fit into 1-3, fix it!  You won't be successful as one of those.  If you're a 4, you're almost there, find a little more time to call your current contacts back and you'll become a Grade A.

Interview Tips from, and to, both sides of the table

I've learned a few things over the years through all the interviews where I was the candidate. Now, I'm on the other side of the table and am quickly learning a few more "do"'s and "don't"'s. I'm going to start a list of them here. These will apply for candidates and interviewers as there are thing that the hiring manager/team should do as well.

1. Candidate: Show up dressed properly.
You would think this would be fairly straight forward, but some people still think that jeans are appropriate. This isn't even ok for an interview at McDonald's, much less a development position. For the McDonald's job, at least put khakis and a polo on when you hand in the resume. The developer position is a suit.

2. Candidate: Bring extra resumes
This was one of the things I remember being taught when prepping for interviews. Odds are, the interviewers will have copies, but don't play the odds. The house always wins. You should always have a pad of paper, pen, and resumes with you at an interiew.

3. Candidate: Bring Show and Tell
This isn't required, but talk about scoring bonus points. I recently had a candidate bring just screenshots into an interview. It definitely left an impression with the team. It doesn't take long to print off something you've done that won't compromise your current employer. Walking the interviewer through the code is far better than code puzzles. Plus, then you're in control and can gauge the knowledge of your potential employer.

4. Interviewer: Avoid definition questions
I ranted a bit about this in my last post, but I'll recap here. It barely, if at all, gives you an understanding of the candidate's technical ability. At best, you learn that they have great memorization skills.

5. Candidate: Be prepared for definition questions.
Despite #4, odds are it's probably going to happen. Make use of those memorization skills and brush up on things like: Encapsulation, Inheritance, Polymorphism, delegates, Response.Redirect vs. Server.Transfer, etc.

6. Interviewer: Don't ask questions you can't answer yourself.
This probably doesn't happen a lot, but I've still heard of it enough to list it. If you're not experienced in the role that your hiring, that's fine, but don't try to pull some obscure question off the internet and expect a verbatim response to what you read. It's not fair to the candidate and you'll likely lose at least one good one because of the false negative response.

7. Interviewer: Provide an IDE for technical questions.
If you want them to code, spin up a virtual machine with Visual Studio, Eclipse, etc. and allow the candidate to have tools at their disposal. If all you supply is a whiteboard, you'll make the candidate look worse. Intellisense is a huge tool for many developers and can replace Google in many cases, but dot operators don't expand an option box on the whiteboard. I get that you want someone who knows what they're doing, but odds are, you probably rely on your IDE's features, too.

8. Candidate: Eye contact is good.
This is harder than it seems. When you need to think, people tend to look up, down, anywhere else except the person they're addressing. I get that and it doesn't really bother me. However, there's two catches.

First, this is only ok when you're thinking or formulating an answer. When you give the answer, make eye contact.

Second, eyes are two, little, typically horizontally-aligned round-ish orbs on the northern-most section of a person's body. I say this because, while the stereotype for software developers are pimply, overweight, socially-inept men, that's not the case. If you're looking/staring/leering at other parts of your prospective employer, they'll know. Be respectful...not a creeper.

9. Interviewer: Introduce the team and their roles
I don't know how many times I've been the candidate and all I get are the interviewers' names. Remember, this is a mutual agreement. If the candidate doesn't know enough about you, they may not accept. I find that doing this up front not only takes care of this, but also can serve as a bit of an ice breaker for the applicant, as well.

10. Candidate: Be honest, but not self-deprecating
If you're not a jQuery expert, that's fine. Be honest about it. In many languages/technologies, rating yourself any higher than 8 out of 10 is going to draw a "Yeah, right!" face from the interviewer. Some will even be sadistic enough to prove your inability as humiliatingly as possible. Typically, this will probably mean the interviewer isn't following rule #6 above, but that's not the point if you can't even get close.

That being said, saying that you're not strong on multiple things can hurt you. Especially if their absolute must-have's for the position. This doesn't have to be languages/technologies either. Even though you may be joking to relax, by saying that "Writing isn't my strong suit" or "Typing isn't my strong suit" repeatedly throughout the interview will probably hurt your chances of landing the job.

11. Candidate: Have a life but don't focus on it
If you're asked about what you do to relieve stress or do for fun, it's perfectly acceptable to say that your hobbies include blindfolded, underwater basket-weaving and writing a Swahili-to-Huttese dictionary, but don't explain them in detail if the interviewer doesn't ask.

Bad

Good

While I don't speak Swahili or Huttese, I'm a huge fan of Star Wars, as you can see from my light-saber tattoos for eyebrows. I figured that I'd be doing the Swahili speaking world a huge favor if Jabba ever comes to Earth trying to find his kidnapped relative. While he obviously understands English, it would be nice if John Q. Swahili Speaker could understand that Jabba's about to drop him into the Rancor pit.

Interviewer: Swahili-to-Huttese dictionary? Do you speak either language? Why would you want to write that? Candidate: I'm not fluent in either, but I figure if I can master Javascript (AUTHOR'S NOTE: I hate Javascript. I know it can be useful, but I just can't stand writing it.), then both of these languages should be a walk in the park. I'm doing just because I can. It has nothing to do with the time Greedo kidnapped me (AUTHOR'S NOTE: Ok, maybe avoid the part about a fictional alien abducting you.).

12. Interviewer: Sell your company
Explain to the candidate why they would want to work with/for you. Why is XYZ Co. THE place to work at? That's what the candidate should know and shouldn't need to ask.

Management Newbie: Hiring Developers

Uh oh! Two blog posts in 30 days? I'm on a roll!

I've now been in my job for a little more than two months. It's been pretty eventful as I try to absorb the custom code-base for our SharePoint environment and do some additional development work all while becoming a manager for the first time. The first manager reality I had to deal with was my lone developer resigning. There was no animosity, thankfully. He just found a position that he felt was better. While it's tough trying to do all the in-house SharePoint development as well as be PM and corporate manager, it could have gone worse (at least I didn't have to fire him. I'm not really looking forward to having to do that).

Before this "wrinkle," we had a Junior Developer role available that was open but we weren't actively looking. Now, we are actively trying to find two developers and are open to anyone (Junior, Mid, or Senior). We've had four candidates thus far as, apparently, the St. Louis area is a hotbed of SharePoint development. There's plenty of work to be done and not enough people to do it.

Somehow, I've never been on the "Interviewer" side of the table in my 6 professional years. Now, I'm not only on that side, but I'm hiring people that will report to me so I have to care even more than if they'd just be a peer. At first, I think I was more nervous than the candidates, but I'm finding a comfort zone now.

To give you an idea of how the process goes, we're now scheduling a 2-hour first interview where the candidate meets with the team (4 of us) as a group. The first hour is fairly non-technical and covers the cultural fit-type questions. The second hour is hands-on development testing. Other than FizzBuzz, I designed the other questions myself. I know there are other FizzBuzz-esque problems out there (ie Cash Register, bubble sort, recursion, etc.), but I figure remembering the modulus operator is about as academic as I need to be (I'll plan another post about my feelings of some CIS/MIS/CS degree programs and their value, or lack thereof). Well, except for a ByRef vs. ByVal snippet I ask for that I'll primarily use with the Junior candidates. I figure that should be something definitely in their heads (it should be in everyone's even if it isn't used much).

Assuming the team approves of the candidate, my boss, the CIO, will meet with him/her.

One thing I'm trying to avoid is asking for definitions. As a candidate, I loathed interviewers who would ask me to define terminology. There's so many terms that people should know as a .Net/SharePoint developer and I just don't see it as a way to gauge a candidate's ability to write code. Now, I know some of you would argue that if you can't define it, then you can't write it. I've done plenty of OO programming, but I always struggle to remember the definitions of Encapsulation and Polymorphism. Just because I can't define them, doesn't mean that I can't properly implement them.

The only thing close to a definition I look for is IDisposable. Developers as a whole should know about this interface, but SharePoint developers better worship it. I almost learned that lesson the hard way when I first started with SharePoint (looping through a Farm without disposing SPWebs and SPSites is WAY bad for performance). However, I don't phrase it as "What does the IDisposable interface do?". Rather, I ask one of two things:

If the candidate has SharePoint experience, I ask them to write a code block (not a whole method) that, given no context (SPContext), modify the title of a site at a given location.

If the candidate hasn't developed for SharePoint, I pose a similar question but using a SQLConnection.

As far as other questions, I took some ideas from some other blogs that I really liked. Here's a list of those resources:

Interviewing Developers - 20 Good Questions to Ask
How to Interview a Developer

I came up with another one that has a chance to provide some insight, but doesn't seem to be getting much traction yet. I ask the candidate to tell me the "Most recent/coolest/useful code hack/trick that you've learned." These don't have to be new ideas, just something he/she likes to use when it makes sense. I've had a few over the years that definitely weren't new to everyone, but were insanely useful to me (ie using blocks for SPWeb/SPSite, Source QueryString parameter, XML comments). I guess I've been wording it wrong, though, because the answers are more about products that people can't live without. That's not a bad thing as solutions like CodeRush, SharePoint Manager, and XML Spy are great tools, but it's not what I'm looking for.

I think that wraps up this post. I have another post that'll probably come soon that will focus on interview tips from, and to, both sides of the table.

New Job and Fun with Search Customization

I left the hospital and moved to a prominent PR firm about a month ago. I'm now heading up a team of developers and picking up the rest of the architecture rather quickly that will basically turn me into an architect/project manager. It's a pretty cool environment that is truly an enterprise implementation. It looks like we'll actually get to play around with a lot of the buzzwords surrounding SharePoint (ie. ECM, WCM, mobile, intra-/inter-/extra-net, multi-tenancy, etc.).

I'm hoping this experience will give me enough knowledge to start giving back to the SharePoint community by the way of presenting at SharePoint Saturdays or other conferences. I'd also like to get enough out of it to help me get the MCM certification. First, I need to do the other 4 MCTS certs, but that'll come over the next 12 to 18 months, I think. I'm a little wary of certifications when looking at job candidates because of test bank sites, but the MCM sounds like it's cheat-proof.

Now, for the technical part of this session.

I've only toyed with SharePoint Search (on 2007, no less) in the past and never very deeply. One of the requests we had was to add blog search functionality to our intranet. There's about a dozen blogs currently and I expect it to grow substantially in the next 6 months (NOTE: We're a PR firm so we do social and web 2.0 ALL the time...might as well do it internally, too).

Our blogs all derive from a tree of Content Types that derive from Post.

My plan was to create a search scope that pulled only on the lowest (highest?) common denominator CT, Company-Post. I figured since the 3 below it all inherited from it, the scope would pull them.

That is not the case.

Well, at least not the way I was doing it. What I ended up doing was adding rules for each CT as "include." Not that big of an issue, but I'll just have to remember to add new rules if additional post CTs are created.

Once I created the scope and kicked off a full crawl, I built a few more pieces.

First, a page in Search Center with an OotB Search Core Results web part configured to pull just from that scope. Also, I tweaked the XSL to remove the default link at the end of every result (I think it's ugly) and added Blog Name - Author - Publish Date - Comment Count.

I also customized the refinement panel to show the Blog Title instead of the URL. Michal Pisarek has a few blog posts on the refinement panel that got me moving (Post 1, Post 2, Post 3). Add his blog to your RSS reader of choice.

These are the 2 metadata property mappings I added (one for comment count and the other for Site/Blog Title). Cropped pictures show Property Name and Mapping from Search Service Metadata Property Mappings page:

After mapping those, it does require a crawl. I did a couple of full crawls while doing this, but that's in a test/dev environment. When I push to production, I'll wait until everything is in place.

The other piece I added was a simple search box to the post.aspx and default.aspx of each blog with a target results page of the Search Center page above and the scope set to the custom scope.

That's it! Very simple implementation. No custom code or even SharePoint Designer required! I did use Visual Studio to edit the XSL, but that's just because I have it and am comfortable with it's XML/XSL editing functionality. I'm sure there are several equally useful free tools out there as well.

One neat trick with the search results web parts. If you can't remember the XML structure of the results query, drop this into the XSL:

SharePoint 2010 Migration Hell - Part 2

Now that I've flogged Microsoft Tech Support for their inability to resolve my issue, let's actually fix this thing.

I was still stumped as I had exhausted Google. We called in the consultant again and gave him some of the information found during the tech support debacle.

1. Database upgrade status was "database is up to date, but some sites are not completely upgraded."
2. A feature was not properly removed from the 2007 farm before upgrade. It was a custom InfoPath template.

He plugged away at this issue with a backup of the database in his development environment. He found an answer after about a week (this was the week before Christmas so the Microsoft ticket had been open for about a month).

Here's the Plan of Action:

-Mark the Database as read-only
-backup and copy to "Fix-up" environment (a clean 2010 farm).
-Delete site that had the bad feature issue.
-Apply August CU's to farm.
-Run Upgrade Powershell command.
-Confirm database reads "No action required."
-Reattach to production
-Test

6 hour scheduled downtime and we were done in 6 hours. Plus, the site stayed up in read-only mode during the whole thing. No "real" downtime.

The root cause comes down to a feature that wasn't removed properly before the migration not allowing the primary site collection to upgrade.

SharePoint 2010 Migration Hell - Part 1

I started the upgrade from MOSS to SharePoint Server 2010 back in October. It was a database attach migration and the visual upgrade was not to be applied until 3 or 4 weeks later (time needed to train contributors). Everything seemed to go just fine after a couple of test runs on the new farm, so we proceeded with the migration. Other than typical User Profile Service stuff, everything seemed successful.

NOTE: This is all done in production as there isn't a test environment. Yes, I know, I NEED one, but there just hasn't been any time for my team of me, myself, and I to get to that project.

However, when I went to prepare for the visual upgrade, demons from Hell exploded from my farm. Seeing as I was short a Golden Child (apparently, Eddie Murphy didn't protect him after his return to Tibet), I had to actually address the issues (no, I can't make Pepsi can dancers).

The issue that first arose after trying to apply the visual upgrade was: "One or more field types are not installed properly. Go to the list settings page to delete these fields." This happened on any page I tried to edit. I followed it back to the Relationships List (http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/a30f0ffd-782f-4d4a-9c22-b92bac0fad4f). I tried the changes as stated, but that only seemed to fix a small part of the problem as the pages continued to display errors. At this point, I rolled back to v3.

After that process that would cause most people to start drinking, or at least quit, I pulled out my shovel and started digging through the log files and event viewer. Eventually, I hit a wall (at the time, I was wishing that was a literal statement) and after having baffled our consultant, I called Microsoft Tech Support.

Well, this was about as useful as asking my 3-year-old for help. After playing phone tag for a week I finally got to talk to someone. At this point it was the day before Thanksgiving. After having a look at the log files, the tech, Mukesh, wanted to perform some steps in a short downtime. Management approved a 30-minute window in the middle of the day as that's all Mukesh said would be needed. All he wanted to do was detach the content databases from the main web app and reconnect them to a test web app that was created after the migration.

*SNAP* goes the Error Demon's whip.

The attach fails (I think it was due to the fact that our master page has a custom web part built in it and we didn't tweak the web.config, but Mukesh wasn't listening). Ok, so reattach to main and we'll be back up.

*SNAP* At this point the Error Demon is laughing maniacally.

The reattach didn't bring the site back up. This is around the 45-minute mark of the 30-minute downtime. So Mukesh has me try many other things over the next few hours (AAM's, IIS host headers, host files, web.configs, etc.). Around 4:45pm (3.75 hours into the .5 hour window), he decides that it's a Network issue and sends it into the Network team's queue. His lead told me that the Network team would contact me within the hour.

5:45 - I call the operator line. It was assigned to Network and I should receive a call "soon."

6:30 - Status is still "soon." Mukesh's lead was wrong about 1 hour callback. That's only for Premier customers, not standard Enterprise Agreement customers.

7:15 - Operator can't see that there is an assigned tech. Calls Mukesh's team, but gets no answer. While on hold, I get a call from Sameer with the Network team. Operator transfers me at 7:45.

7:45 - Sameer wants to see load balancing info. After telling him that we don't use Windows Load Balancing, he says he can't help because it's not supported. He says the SharePoint team will have to work on it (you know, that same team from before that was of so much help). He leaves a message for the SharePoint team lead.

8:50 - Sameer calls back asking if I had heard from the SP team. After telling him I hadn’t, he said I would need to call the operator to get in contact with them.

9:05 - Operator Camille emails manager on duty and is notifying her supervisor of the issues and trying to expedite the call back. Said she will contact me when she gets more info.

9:24 - Camille says the manager is assigning the ticket and that I should receive a call “soon.”

10:38 - was told that the SharePoint manager put me next in line, but does not know when the next tech will be available.

10:55 - call from tech support (Bharat). Finally figured out, after reading the logs (same logs sent to Mukesh), that the Office Web Cache Creation job was failing. Did a remove via Powershell and it started functioning again.

1:30am Thursday - walk out with a site back up, but no closer to a resolution on the original issue.

There was another run-in with tech support the next Wednesday. Basically, same process and similar resolution (had to run the upgrade to get the site collection to respond).

This turned a bit longer than expected, but I wanted people to know about the whole experience including the chaos that was tech support. Up to this point the tech support stats finished at:

Planned time down: 1.5 hours
Total time down: 15 hours
Tickets opened: 2
Tickets closed: 0
Tickets refunded: 1 (but will try to get #2 refunded)
Migraines: numerous
Understanding of where THE postal worker was coming from (you know the guy who went "postal"): YES

The next entry will actually resolve the issue. I swear. No three-part blog.