Recently I had the opportunity to help interview some candidates in an attempt to fill a vacancy on my current project. The experience gave me some new insight into the interviewing process – I was able to see for the first time what an employer or potential client sees when they interview candidates, and I hope that I’ll be able to take advantage of this experience the next time I’m the one in the hot seat.
I have found that two people with very similar resumes can have very different levels of expertise in their field, and their performance in the interview very quickly determines their fate.
I have compiled below a list of “insights” I have taken from this experience, and included for each an example of an interview question I might ask that illustrates the insight. I hope you will find this interesting and useful.
Insight 1: The employer probably has a clear vision of the type of resource they are looking for. In my case, we specifically need someone who could enter an existing project and troubleshoot issues with code he didn’t write. He needs to be able to pick up a task that is already in progress or mostly done and run with it with a minimum of hand-holding. To be successful at this a candidate needs to be somewhat of an investigator, adept at putting clues together and knowing the right places to look and the right questions to ask.
Interview Question: You have been assigned a custom dashboard page that has a couple of list views, some ribbon buttons and some event receivers on the lists. A user has reported an error, and sent along a screen shot of the error page along with the bug report. What do you do?
Reasoning: We need problem solvers, and this question serves to get a glimpse into the candidate’s methodology for solving problems. The actual technical answer to this question doesn’t really matter, and since there is really not enough data here to go on anyway, there is no way to actually solve it.
A good answer to this question would probably involve tracking down the user to provide more information about the exact steps that led to the error, reproducing the error, and then following the evidence trail to lead to a cause and resolution. A “stock” answer to this type of question would involve looking into the ULS logs, and while that is useful to know it really doesn’t show that you are a seasoned problem solver.
Insight 2: Be prepared to defend the stuff on your resume. We have interviewed five candidates so far, and every one of them had exactly the same stuff on their resumes, the usual hodgepodge of terms, jargon and acronyms you would expect on a SharePoint Developer’s resume. Some of them, though, were clearly not being honest about their technical prowess, and it always comes out during the interview and leads to awkward moments. For example, if you have jQuery and Ajax on your resume, and you can’t answer a question about troubleshooting web service calls, you’re not going to be very convincing. The truth is, if you list twenty technologies on your resume, the interviewer probably only cares about five or six of them, and you can expect pointed questions about those specific technologies in the interview.
Reasoning: This type of question tests the depth of the interviewee’s experience with the technology in question. A competent candidate will savor this as an opportunity to display her knowledge, and perhaps her opinions, while for the incompetent candidate there will be some uncomfortable squirming.
Insight 3: Communication skills are just as important as technical chops. An interview is really a communication exercise, and the interviewee’s ability to project expertise and confidence depends largely on their ability to convey that message through the spoken word. And that’s just as well, because a successful developer needs to be able to communicate with a variety of people, from peers to architects, testers, project managers and users.
Interview Question: Tell me about a tough technical problem you encountered on a recent project, and how you overcame it.
Reasoning: This type of open-ended question serves several purposes: it gives the interviewee an opportunity to make a short impromptu technical presentation about some clever and innovative solution she has worked on. It could also test how the interviewee thinks on her feet, especially if the interviewer decides to ask questions about the topic. Finally, open-ended questions always seem a little stressful, and, well, let’s face it, sometimes a developer has to be able to deal with stress.
In reality though, every question an interviewer asks is a test of the interviewee’s communication abilities. There will be softball questions and tough questions. There will be black-and-white questions and there will be “fuzzy” questions. Each one is a piece to the puzzle in terms of the interviewee’s communication style.
Insight 4: Passion goes a long way. A candidate who is passionate about technology and problem-solving will always out-perform someone who lacks that passion, both in the interview and in the office. Smart employers know this, and will look for motivated people for their teams.
Interview Question: Tell me something you really hate about SharePoint, and what would you do to make it better?
Reasoning: SharePoint is a quirky platform, and it is full of pitfalls, dark alleys, and roads to nowhere. Every experienced SharePoint dev has been driven to tears a few times by its incomprehensible and seemingly nonsensical idiosyncrasies (for the record, my current favorites are list throttling and the list view lookup threshold). A passionate candidate will be eager to commiserate with sympathetic ears when this question arises.
There you have it, my go-to SharePoint interview questions, and the rationale behind what I think employers are looking for. Love ’em or hate ’em, or add your own in the comments below.