As the acting senior on the .Net team it’s fallen on me to conduct technical interviews for the past few weeks. Since I’ve never really conducted technical interviews before the whole concept was pretty nerve wrecking trying to figure out the best approaches. After all I have to see through what people want you to see down to what they can or can’t do. Needless to say the whole experience has been an eye opener.
The first thing I didn’t realize was how nervous I was going to be in this position. The best way to describe having to conduct interviews is like going on a blind date while trying to buy a used car all at the same time in under an hour! All you have to go by is a description of the person that they, or someone they hired created in order to impress a potential ‘buyer’. Of course I’m talking about the resume, which I’d really compare to nothing more than a professional personal ad.
A resume is the first real picture you get to see of the person, and just like a professional photo its probably touched up to look better. I’d compare resumes to looking at a photoshoped picture where it looks fantastic, but of course it is probably too good to be true. I didn’t actually start out with this mindset. Each resume set before me I would read line by line, go through each project listed, and I’d compare what they’ve done with what we need. There were some beautiful resumes that were filled with great projects, listed with tons of skills associated, and were just what we were looking for. Not only that but the person(s) had certifications that backed up these great projects to give us a sense of security on the candidate. Man, was that a dream that popped quickly.
The reality of it was besides the name on the resume everything else is exaggerated. Key take aways on resumes should probably only include the listed company names, years at the jobs, and then potentially job tittles. Assume that if the project listed out sounds very impressive the persons role probably wasn’t. I saw some roles on the project that were only related to ‘requirements’ or ‘business integration’ so it turned out that the person was merely a QA or at best a assistant analyst. Not saying that’s not helpful, but when interviewing for a senior developer position being a document creator or requirement gatherer isn’t going to earn many brownie points.
At the end of it I’ve come up with a more refined system for conducting these interviews. I like the two stage interview approach. The first being the ‘get to know you’ phase where I ask you about all the projects you’ve got listed, the skills you’ve claimed to have, and bounce back and forth on applications where their skills overlap with things we’ve worked on or needed. The second phase is the actual technical interview where I ask a series of questions starting from easiest to hardest.
The actual technical questions range from telling me the difference between ViewState and Session state. Describe to the performance benefits versus impacts of using InProc Session state or database Sessions state. I may mix this question up with other questions about OO class design, custom user controls, run-time generated controls, using generic collection objects to build a list of items, tier design, and then followed up by the real-world problems we’ve faced. The real-world problems are the trickiest because we’ve had hindsight on our side along with a good team system to help overcome the obstacles.
Really there are lists and lists of websites and blogs about what to ask,and how to ask them for interviewing. This has been my first experience at doing so and I can safely say it was far more nerve wrecking than I ever thought it would be. At the same time when you find that one person it is totally worth it. Unless of course you offer them the job, they turn it down, and then you’re stuck wondering if you need to start lowering your expectations. Ugh, sometimes you just can’t win, but the search continues.