Strongly-typed Session Objects

Until this summer, I didn’t see anything wrong with putting something in the Session object by saying:

Session[“Something”] = MyVar;

Of course, that’s a perfectly legal way to use the Session object and it works quite well. So what’s the problem?

Well, let me give you an example of why this can be bad. On one of the big projects I’m working on this summer, we use the Session object to store GUID values which are the keys to tons of things in the system (e.g. you use this GUID to look things up in about 20 different tables). What we’re building is basically a massive ASP.NET-based wizard for doing some business tasks. So it’s quite critical that this GUID is passed between pages in a way that each of them can understand. Well, the situation has now come up that some people started putting the GUID in Session[“GUID”] (which is right) but as a string instead of a GUID object. I, on the other hand, am storing my GUIDs in the same Session location, but I’m storing the real GUID object.

Because you can’t cast a string into a Guid, we have to have two sets of code to convert Session[“GUID”] back into a Guid. Now you can solve this problem by having standards and enforcing them, but that still leaves room for people to make mistakes and still get it wrong. After having to deal with this issue for a couple of days (we’re still trying to find every place that sets these Guids so they can be standardized), I am really thinking making a wrapper for your Session objects would be a good idea. Using the wrapper idea on the project I’m currenting working on, I would have a property of type Guid that will still set and get the Session[“GUID”] object, but it will be the only way to get a Guid in or out of the session…this way, it doesn’t matter if it’s stored as a Guid or string – you’re code never knows. And you don’t have the problem of people storing the same thing in multiple places (or at least it would help with that).

I know this is all fairly obvious stuff, but wrappers (for stuff like this) and all the people wanting strongly-typed collections didn’t really make a lot of sense to me until this summer. Of course, I saw the benefit it added, but I didn’t realize why that was so important, but I certainly know now and in the future, my code is going to look quite different.

Interviewing

So today was my “intern interview” day – the day where each intern goes through three interviews, back to back, to discover if he/she is a good fit for the company, has interest in the areas of MIS, and how he/she stacks up against the requirements for the entry level position of Analyst I (for MIS). The first interview, called “General Fit”, was really pretty straight forward asking about work preferences, would you consider accepting an offer if one was made, what location interests you the most as far as an initial work location, how has the internship gone, etc. A couple of questions are thrown in at the end to make sure you’re ready for interviews 2 & 3 since they start focusing on more behavioural type stuff. Interview 2, which is officially called “Interview Guide I”, was where you are basically compared against the standard desirable traits / qualities of an Analyst I position. They even tell you, this section is examining analytical skills, tenacity, initiative, etc. This one is the one I found most difficult – not because the questions were that hard, but because this one (and the following one) are both asking you to draw on prior experiences to answer the questions and the questions vary quite a bit in this section and it’s hard to not repeat experiences. I know it’s not terrible to have to repeat things, but my goal was to use as many experiences I’ve has as appropriate based on the question – so I had a chance to explain all of the things I’ve done in the past and actually say what I really did instead of leaving some of those experiences up to resume bullets. So after 45 minutes of Interview Guide I, I started Interview Guide II, which was another 45 minutes. This interview was very similar to Guide I, but it was more focused on how you handle certain situations, how you think about a problem, and how you get the results you desire. This was your typical behavioural interview. This one is usually the most difficult to me because it’s very detailed as far as the type of information they are looking for and if my experience was a while back, sometimes it’s hard to remember those details. This interview did surprise me though in that it went into more technical questions than I was expecting – not the kind you’d see at Microsoft, but things like “what is your preferred programming language & why?”, and then getting into “tell me about a system you designed where X happened” etc. Not like programming logic questions – still about the logic used to solve the problem and the results obtained, but it was focused on actual technical experiences instead of more general experiences.

Overall, the whole thing went really well. One thing that helped me though is coming up with a list of projects & experiences ahead of time. I had some idea of the types of things I would be asked about, but not the actual questions – so I tried to think of experiences where I would have seen something the questions may ask about. I tried to have at least 4-6 projects for each interview so I don’t keep talking about the same thing over and over and that really seemed to work well. I will say you should double check spelling on your resume though…I always do that, but somehow, it didn’t work this time – I tend to spell implement like “impliment” and that made it on to my resume. I think something in Word keeps disabling my spell check because sometimes it doesn’t catch words until I actually ask it to check the document and I forget that sometimes because I’m thinking it’s already checking. Oh well, it’s not a huge deal – and I’ve used this resume several times – and had it reviewed quite a lot actually with no one catching this – but still, not exactly the impression you want to make on someone that is interviewing you. 🙂

Quotes on the Importance of Design

Joe Stagner posted some great quotes on the importance of design – not just in software, but in everything we do. I think those quotes are all very true. Of course, great design without a great product is pointless – so you have the best “designed” item, but if it doesn’t serve any useful purpose, then it doesn’t matter. Of course, I also think that if the product doesn’t serve any useful purpose, it can’t really be considered well designed.

UPDATE: Fixed the link…apparently Joe cleared out that post from his personal blog and now it’s just at his MSDN blog as Robert pointed out.