What do you do to stay current?

July 30, 2010 at 7:36 PMRampidByter

Doesn’t seem like too much of a difficult question, but when asked to developers some sit with blank stares. I’ve listened to that question be asked in three interviews this past week, and I really didn’t hear any decent answers. One candidate actually asked us what we do to stay current after a long pause without answering the question.

I recall when Katie Couric asked Sarah Palin what magazines she read to stay current. I thought that was a silly question to begin with because who actually reads printed news material anymore? Still seems like a question you either know, because you do, or don’t because you’ve never tried to. Those people who don’t know often pause, mumble, and just in general seem very confused.

Just thought that was an interesting take away from this week’s interviews.

Posted in: Interviewing

Tags:

Programming Interviews and AJAX Experience

April 18, 2010 at 7:26 PMRampidByter

When I became the senior developer with my current company with it came some added unexpected responsibilities. I instantly became the main technical interviewer for the programming department. I became the bearer of the responsibility for weeding through those deserving few who would bless our department, and more importantly our code with their presence.

It wasn’t into my third or fourth interview where I’ve started to notice a very unsettling trend. Every single developer we brought in listed AJAX not once, but many times throughout their resumes. In addition to being listed within the skills section nearly every project listed AJAX among the many accomplishments of a project. The problem is that the entire experience and exposure to AJAX consisted simply of using an ASP.Net UpdatePanel.

ASP.Net UpdatePanel’s do not mean you’re accomplished at AJAX. It simply means you can drag-and-drop a control onto a Web Form. Congratulations you’ve just accomplished something any first year programmer can do. The saddest part is the people I’ve been interviewing lately have more than 10 years of development experience and nearly all listed their expertise as expert on the .Net platform. Every single one of them couldn’t answer a single question related XMLHttpRequest, jQuery AJAX calls, consuming a JSON web service, or had any idea what an PageRequestManager is.

UpdatePanel does not mean you’re an expert at AJAX. Updating a page without a full-page post back does quality as an AJAX behavior, but does not make you an expert on AJAX. None of these AJAX experts have ever worked with jQuery, and only one has ever touched the AJAXToolkit. It’s seriously starting to get to me. It’s like putting down that you’re a NASCAR driver when all you’ve done is driven a go-cart around a track at an amusement park.

Posted in: Interviewing

Tags:

Conducting Technical Interviews

October 8, 2009 at 10:34 PMRampidByter

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.

Posted in: Interviewing

Tags: