Site News for 8/19/07 through 8/25/07Will the Real User Please Stand Up

How To Conduct a VB.NET Job Interview

August 26th, 2007

Yeah, managed code is when my boss tells me what to write

Back in 1999 when I first started a VB related web site, then on a free dotcom era host, I wrote this article, VB Interview Questions, that provided a list of interview questions for VB6 related jobs. The article hasn’t been revised in years but is still one of the most popular of my archived site’s articles. So, I thought I’d revisit the programmer interview process. I went through several interviews last year as part of a job search, some good, some bad. I’m not going to get so much into specific questions here but more into what kinds of questions to ask and the interview process as a whole.

Getting a Good Start

In my original article, I said, “The interview should be conducted by someone who knows VB well preferably someone involved with the project the person is being hired for.”  I still think this is true. While a Human Resources department can be valuable in doing some initial and background screening, it should be up to the hiring manager to do the initial technical screening of candidates. This helps insure that you don’t frustrate qualified candidates and don’t waste a lot of time on those you don’t. For example, for one job a HR rep gave me a 25 question multiple choice test on .NET over the phone. I did quite well and got a face-to-face interview lined up. However, when I came in for the interview, it quickly came out that they were looking for someone with more of a C#/C++ background than VB. So, we ended up wasting each other’s time.

Certifications or No Certifications? Tests or No Tests?

My opinion is that certifications don’t mean that much in the long run. They’re somewhat helpful in eliminating those with inferior skills but, by insisting on them, you may also miss out on excellent programmers. From what I’ve seen from the system administrator side of the IT house, certifications are not a good indicator of future success within a company nor technical competence beyond the ability to regurgitate trivia. They’re a plus but shouldn’t be a make or break criteria.

Should you give written or online tests prior to an interview? I’d have to recommend against this. This used to work somewhat back in the pre-Internet days but today, with answers just a Google away, it’s mostly a waste of time and money. If you want a pre-test for screening, I’d suggest going with an open ended, personal level, model like, “Describe how you coded some of the major features of your latest VB.NET program?” or “Which array or collection methods do you find yourself using most often?”. This increases the likelihood of getting back a meaningful response rather than a borrowed blog or forum post.

The Interview

You can do the interview over the phone or in person. As both the giver and receiver of interviews, I prefer a phone interview first. This is usually a big time saver for all involved and has the advantage of being ‘green’ since no extra gasoline will be required. It also can be conducted after hours from home as well, making it more convenient for all. Just don’t try to do an interview on a cell phone while driving please!

Trivia Time

OK, so you’ve started the interview so let’s start with some trivia questions. These questions can be as few as 3 or 4 or as many as 25. I suggest starting with some softball questions like, “In .NET, what is an Object?” and build up to more difficult ones like, “Explain how to multicast delegates.” You can probably find a number of good questions you can put together from my VB Tutorial articles as well as on other VB.NET related sites. The point of this part of the interview is to see how well they know the basics. Don’t ask pure trivia like “How many overloads does the String.Format function have?” or a set list of standard questions. Instead, ask questions that will give you a good idea of what the interviewee knows without trying to purposely trip them up and ones that track well with the apparent skill level of the candidate.

In most cases, you’ll know within about 10 questions if the person has the knowledge level you are seeking. If they don’t, it’s probably best to wind up the interview at this point quickly and politely. If they do, move on to the next phase.

What Have You Done and What Can You Do For Me?

Now that trivia time is done, you can get into the meat of the interview. In this part of the interview you want to find out what the candidate has done on projects in the past as well as getting an idea of how their skills might apply to your projects.

I’ve found it best to ask questions that allow them to describe their previous work. Most will be enthusiastic about it and give you a lot of detail about it. Ask leading questions like, “What did you use for your database layer?”, “How do you debug problems in your web service?” or “How did you document your code?” With these questions you should be able to gauge the level of participation the candidate had on these projects and where their head is at from a coding perspective and how they would fit within your department.

Also, now that you know how they stand with something they should know, their own work, give them a situation from your problem domain. For example, if you deal with importing randomly formatted ASCII data files into a database, ask them how they would approach this problem. You don’t have to make it complex but get them to describe the basics of how they would handle it. In a face-to-face interview, have them write it out on a whiteboard or paper to also test their presentation skills.

Should they show you a code portfolio? Given that it can be faked rather easily these days, I don’t think it’s of much value anymore. However, it is a good idea to ask if they have any samples of their they could send you or that you could download. Just don’t give it a lot of weight.

Should they know something about your company? Yes. The Internet works both ways. They should have researched your company prior to the interview. If they haven’t, well, you aren’t that important to them so maybe they shouldn’t rank so high in your book either.

Do You Fit?

This is really the key question once you’ve determined that you’re interviewing a good programmer. As I mentioned in my old article, I like to see if someone has a spark of creativity and a sense of humor. While they don’t have to be a musician who’s also a Monty Python and Star Wars fan it makes the days go smoother if they don’t give you a blank stare when you bring up a bit of popular geek trivia.

Essentially you’re looking for someone that you wouldn’t mind working with on a project. They’re probably looking for the same thing. Throw out some light conversation as you wrap things up to get a feel for this.

What Do You Want To Know About Us?

Another key part of the interview is to make it two way. Have them ask questions. You can get a feel for where they’re at from this as well. For example, if they ask “When do I get days off?” or “How did you get out of that recent FTC investigation?” you might want to be a bit cautious but if they ask questions like “What is a typical work day like here?” or “What do you use for source control?” this could be taken as a good sign.

Finishing Up

Let them know what the next step in the process is and when they should hear back from your company. Try not to leave them hanging. Nothing is worse as a job candidate than having an excellent interview and not hearing back from the company until after you’ve already had to accept another position. If they didn’t do well, let them know although you should make it as non-personal as possible.

That’s all for this article. It went on a little longer than I thought it would but I hope it’s helpful to you. I had some other ideas I wanted to include but I’ll just put them in a follow-up article. Let me know if you have any thoughts or questions on the interview process by leaving me a comment or using the contact me button to send me an email.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Entry Filed under: Development Teams


Rate This Article:

Not That GoodCould Be BetterOKGoodGreat (5 votes, average: 4.4 out of 5)
Loading ... Loading ...

3 Comments Add your own

  • 1. Ciz  |  August 27th, 2007 at 1:12 am

    Great article, some very useful tips. Here are some of my own thoughts about recruiting VB.NET developers:
    http://3poundmass.wordpress.com/2007/08/20/recruiting-vbnet-developers/

  • 2. jfrankcarr  |  August 27th, 2007 at 8:39 am

    Thanks for visiting. I had read your article last week and thought it was interesting. I’ll try to post a comment about it over there sometime today.

  • 3. Bryan K  |  February 21st, 2008 at 8:02 pm

    Frank,

    I totally agreed with you on the certification and on-line testing part of the interview.

    I have been doing VB since early 90 and with dotnet till now and yet to get a certification, but, when chatting up people with MCSD or MCAD, I know their knowledge is far worst than me.

    What I used to do when I interview people, I give them a 30-minute time to do a small project. From the line they code, actually, you are able to tell more or less how good they are….

    But, in reality, at least in my country, without a MCAD or MCSD would be hard to even get to the first interview as most people will dump your application aside….

    Anyway, good post.

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed


Visit Me At My New Site, Programming In C#

Most Popular Articles

Highest Rated Articles

Categories

Most Recent Articles

Feeds

 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities

Archives