Interviewing Tips

A friend of mine recently sent me an email (along with his resume), saying that he was going to be out of work in a couple weeks. The company he was contracting with was not going continue his contract, because apparently the project he was working with wasn't going forward. My consulting company is pretty good, and they offer a good referral bonus to consultants, so I'm usually pretty good about recommending my company, and asking my friends how happy my friends are where they're working.

Anyway, I forwarded his resume on to my resource manager, and my friend was interviewed. He went through the gauntlet pretty well, and eventually was made an offer. My manager sent me an email thanking me, and forwarded a comment from one of the people who interviewed him. One of the things that impressed him the most (and very well could have lead to his offer) was the fact that he sent a thank you note after the interview. He said it was the only thank you note he can remember receiving in dozens of interviews.

I remember that little bit of advice from our career counselors in college, when they were prepping us for interviewing when we graduated. They were right. It doesn't have to be much. Hell, it doesn't even have to be a hand written note. Send an email. Be sincere. It works.

Short Circuit Logic

I participated in a small group talk at my company last week on the topic of "Upgrading VB6 to VB.NET". The presenter had scoured the Internet looking for helpful information, and going over pros, cons, and typical problems that people encounter when converting existing code from VB6 to .NET. One of the issues he brought up was with short circuit logic. He found this article on The Scarms (which I never heard of), that said that VB.NET now did short circuit logic where VB6 did not:

New to VB.NET is short circuit logic. Short circuit logic only evaluates multiple conditions in a logical statement if necessary. Consider:

Dim b As Boolean

b = Function1() And Function2()

Under VB6 both functions are evaluated. Under VB.NET if function1 is false, function2 is not evaluated since "b" cannot be True. While this is more efficient it can cause problems. If a side effect of evaluating function2 is the setting of a global variable, that variable will no longer get set. This will produce the desired effect:

Dim b As Boolean
Dim c As Boolean
Dim d As Boolean

c = Function1()
d = Function2()
b = c And d

This is dead wrong. VB.NET by default will still evaluate all terms in a logical expression as it did in VB6. For many VB6 programmers who did a lot of C, this bothered them greatly, and so VB.NET introduced two new keywords to perform short cirucit logic (AndAlso does short circuit And, and OrElse does short circuit Or). However, the operation of And and Or have not changed. Here is an example VB.NET program which illustrates this:

Module VBPlayground

   Sub Main()

      Dim bFirstParam As Boolean = False
      Console.WriteLine("Testing And")
      If (bFirstParam And SecondParam()) Then
         ' Do Nothing
      End If

      Console.WriteLine("Testing AndAlso")
      If (bFirstParam AndAlso SecondParam()) Then
         ' Do Nothing
      End If

      bFirstParam = True
      Console.WriteLine("Testing Or")
      If (bFirstParam Or SecondParam()) Then
         ' Do Nothing
      End If

      Console.WriteLine("Testing OrElse")
      If (bFirstParam OrElse SecondParam()) Then
         ' Do Nothing
      End If

      Console.Read()

   End Sub

   Private Function SecondParam() As Boolean

      Console.WriteLine("Second Parameter Called")
      Return True

   End Function

End Module


And here is the output from that program:

Testing And
Second Parameter Called
Testing AndAlso
Testing Or
Second Parameter Called
Testing OrElse

So why did the VB.NET folks decide to continue this behavior, instead of bringing it inline with the other .NET languages like C# and J#? The answer is pretty straightforward... backwards compatibility. If they changed the behavior, and you tried to port your code from VB6 to VB.NET, you could potentially run into all sorts of weird bugs that would be difficult to find, since you might depend on the side effects of a function that might never get called. Imagine if some important database call occurred in SecondParam(). Thats why they introduced the new keywords, and I think it makes sense.

However, this is also a good reminder to use AndAlso and OrElse instead of And and Or in your regular Visual Basic programming from now on, unless you have a specific reason for all parameters to be evaluated.

Understand Your Workforce

When you run a company full of people writing software... there are certain things that an office should have in order to support its workforce. Sure things like pens, paper, computers, printers, desks and chairs are all well and good. But when your vending machines don't have any Diet Mountain Dew in them... can you really claim understand to understand those who work for you? Sheesh.

The Bench

I ended my last client engagement at the end of December... and so now I'm sitting on "the bench". It's actually nice to have a quiet piece of time to do some training, try to finish up my MCSD, and most importantly to take a breath and gain some distance from my last job in preparation for my next.

I thought I'd mention a few random things as I sit in my new cube:

• Having a cube next to a window is really cool. Literally... it's winter here and windows offer absolutely no insulation. I'm freezing!
  
• The chair I have has two levers on it. One of them adjusts the height of the chair, while the other has absolutely no function whatsoever. Seriously... I've spent the last 10 minutes trying to just get the damn thing to move in one of 6 directions, and it doesn't budge.
  
• Being able to experiment on things you've wanted to for a while is definitely an added bonus to the bench... except when you realize how poorly certain SDK's are documented. I think I need to go find some blogs for members of the VSIP team.

Readme Item of the Day

Was reading the Visual Studio 2005 SDK Readme and happened upon this rather humorous note:

Setup fails if the installation path is customized to path with more than 128 characters excluding the drive letter and the slashes. (We realize it is ironic to put this information in a file that is installed by setup, but at least you know that we know about the problem you have already worked around).

And now you know that I know that they know about the problem...