Being involved as an interviewer I thought I would offer a few personal (as in from me not officially from any company) tips to potential candidates everywhere.

First a note to the recruiters... Look I went through a recruiter many years ago when I got out of the Navy. I'm aware that after I interview your first candidate you are having that candidate call you and tell you what I asked and then you are using that information to brief the next candidate however:

1. Making your second candidate show up late while you wait to brief this weaker candidate is not a good plan - I may run longer then you expect on the interview and making a candidate late so there is time to brief them is just a mark against them at the start.

2. I (and others) don't ask simple questions with a right and wrong answer. The questions tend to be much more open ended - tell me about object oriented programming or web services. So prep time with our questions from the last candidate to your next candidate is pretty much wasted - just make them aware of the advice below. Of note the second candidate I interviewed did worse in my opinion then the first candidate. (Also note - none of the candidates I interviewed last week got to the important elements in my web services question.)

Fact is I don't interview with questions that you are going to prep for... I don't care what your candidate thinks their weakest attribute is ("Oh I just overwork myself to finish extra-requirements...") or if they can name 5 collection classes from .NET or some such - I want your candidate to tell me what they know.

Next for candidates - two golden rules:

1. If you put it on your resume be prepared for a question related to it! This doesn't mean a simple question it means that if you say you are an expert I will ask you expert level questions. Your resume was your intro to us and if you say you have experience on your resume, I will see if you are representing yourself appropriately. One or more candidates last week were noted as having heavily padded resumes. (BTW - don't assume the interviewer cares what .NET language you are most familiar with - one candidate last week listed C# as his/her primary language, said he/she did 50+% of their work in it - but had to be prompted with VB keywords in at least two cases... which was really silly since I'm a VB MVP and would like nothing better then to ask my questions with VB keywords and to hire VB programmers! Only a fool limits their selection of talented .NET developers based on a language preference.)

2. If you say in the interview you know something - be prepared to be asked about it. I'll ask most every candidate if they have any experience with certain technologies that might not be on their resume. I know with as heavily as people are padding resumes this is probably pointless... but sometimes it yields surprising results. For example there is the occasional candidate who will say "I know a little but not enough to really talk to that" which I can respect and will ask a simple follow up question to judge what they do know.... then there are the people who with the first question say "Yes, I've been working a with that recently/on my own time (or whatever)" who then choke when I ask a follow up question. While they don't usually make the same mistake twice - bad news, don't tell me you've used "VS2005/SharePoint etc." and then choke when I ask you about your favorite feature - that looks REALLY BAD and you are pretty much headed for Rejectville on the first attempt to snow me. The really sad part is - I don't care if you haven't worked with it, I'm just curious. You would in most cases be best off telling us flat out that you haven't worked with it then trying to pretend you have - I read your resume it wasn't listed I wasn't expecting at this point in the interview for you to know it.

Overall as a candidate expect that you will have at least one person who is a .NET expert in the room to interview and that you will face some very technically oriented questions based on the experience you list in your resume. Your interview may involve as many as four engineers depending on our availability. Be on time and dressed neatly - you don't need a suit but show up as if you were going to a client site (I may be in shorts and t-shirts but I'm not headed for a client site if I am, and for the interview you need to make me think I can send you to a client without too much supervision on proper attire.)

In general any company will hire people with all kinds of different experience levels from Junior engineers through Senior Engineers.

Oh yeah and before I forget - classic interview tips:

1. Don't argue with the interviewer - you thought technology A worked like X - interviewer says "no it works like Y". The interview is not the time to make your case - the case you will be making is your ability to work and play well with others - and you won't be getting a passing grade. If you feel you were wronged make a note and send documentation after the interview...

2. Don't tell the interviewer(s) that you are only at the interview because "your hero" works here and that you wouldn't be interested otherwise - companies aren't looking to hire fans for someone else already at the company - they are looking for engineers.

Lets face it most of us tend to search MSDN using Google.  It's not uncommon and regardless of what we think about censorship politics etc, and although MSN Search is improving at this point old habits die hard.  So for about the past day or so I've found that some (but not all) of my Google searches into MSDN result in a page which is totally missing the formating for MSDN.  For example:

msdn2.microsoft.com/en-us/ library(d=robot)/ms173150.aspx

About the second or third time it happened I looked at the url and realized it had that (d=robot) string embedded in it.  Recognizing that search engines use 'robot' browsers to surf and index the web I removed that string from the directory hierarchy of my search result and lo and behold there was the formatted page which was human readable.

Don't know if Google isn't accounting for their robot or Microsoft has suddenly redirected robots (my suspicion) in order to better scale traffic.  But if you suddenly get an unformated MSDN page - look for the d=robot string in your url and make it go away...

Just a quick note as I prepare for tonight's presentation to the .NET Beginners User group.  http://www.sandiegodotnet.com/SDNETUG/DesktopDefault.aspx?tabid=24

Things have been a little hecktic, since I've become an instructor for the University of California San Diego (UCSD) Extension program in addition to my day job.  Between all my recent presentations, articles and Version 5.0 I have been neglecting my posts here.  Time to get back at it in preparation for next week's MSDN WebCasts.  The ASP.NET team is doing a series showing that ASP.NET isn't a IE only technology.  I have two presentations one on Tuesday the 14th and the other on the 16th.  The program is also offering free copies of Visual Studio Standard Edition if you participate in a few of the web casts.  For more information and to sign up go here: http://ad.doubleclick.net/clk;26540614;12550611;s?http://www.learn2asp.net/campaign.aspx

Now it's time to present the .NET Framework A to Z...

Just a couple quick hits from this weekend's code camp.

Firstly, I'll have the materials from all three of my sessions posted on either Wed. or Thursday of this week.  I've got another presentation Tuesday night at the San Diego .NET User Group which I'm currently focusing on, but you are welcome to attend that meeting it's down in San Diego here's their website for more information: http://www.sandiegodotnet.com

Secondly after my session on Visual Studio 2005 and SQL Server 2005 I was asked a pair of questions.  The first question was "We are seeing tools put the T-SQL text of database statements into our source code.  Is this as good as using stored procedures?".  The answer to this question was easy.  Never use text based queries in your code as that leaves the possibility that you will be susceptible to SQL Injection.  There are several tools that will try to help ensure that this isn't possible by blocking special characters etc.  but the fact is the easiest solution which is also one of the most performance enhancing is to ALWAYS USE STORED PROCEDURES.

The second question they asked however caught me off-guard.  It was "We've seen that Microsoft tends to separate the Create, Update and Delete statements into separate stored procedures.  However, other tools have combined these with a simple flag to indicate which action should be taken.  Is there a specific reccomendation?".  Here my answer was that I couldn't think of anything specific and that although I always separated the items I couldn't think of a reason that mattered beyond style.  In this case the person asking was saying they liked to have a smaller number of stored procedures.... which has it's own disadvantage with multiple developers.   But anyway after the day was over and I was driving home the correct answer came to mind, which is that you should NOT COMBINE the CREATE, UPDATE, and DELETE statements in a SINGLE STORED PROCEDURE.

The reason is quite simple, security (again).  In this case it has to do with the fact that you of course are not using your 'SA' account for your website.  You should be using an account with limited permission (for a whole host of reasons).  So what's the big deal, well in most cases we design systems that don't allow a user to Delete an entry from one of our tables.  So if I have a stored procedure that creates my entries and I of course give anonymous or external customers access to that stored procedure then that's in the scope of what I expect a hacker might at somepoint compromise and I accept that risk.  However, if that stored procedure also contains the entry delete logic, then I have no way of limiting a user's permissions at the database level to prevent a hacker who might violate a small portion of my application's logic from doing significant damage to my application.  By separating out the Create, Update and Delete logic, I can create a security model which will prevent an anonymous hacker who get's unfettered access to my create logic from also being able to delete valid data from my database.

That's the short of what I consider to be a very good reason to not combine your Create, Update and Delete logic in a single stored procedure.

The slopes at Snow Summit and Bear Mountain have opened.  It's early season so it's only a couple runs are open and the services are a little limited, but crowds are also down.  We started skiing around 8:30/9 this morning went till a little after 11.  Took a lunch break till about 12 (this is the type of service that was a little limited...) Then went back out on the slopes till after 2:15 and took a break for about 30 minutes when I went back out for a couple more runs till almost 3:30.

For more infor on which runs are actually open up in Big Bear, I recommend this page which has two color coded maps (one for each resort) showing which runs are operating: http://www.snowsummit.com/photos.php

OK, I was prepping for next week's VS2005 launch event in Anaheim when an odd thought struck me.  I was looking at this slide where Microsoft was defining what a 'Smart Client' application is (as opposed to a Thin Client or Fat Client application) and I realized that the term "Dumb Client" really had dropped from the technical vocabulary.

Now I'm sure that there are some high school age kids that will classify 'dumb client terminal' right up there with punch cards.  I did a search for "dumb client terminal" and got a grand total of like 13 hits on google and like 3 hits of MSN Search.  The fact is the days when people would buy a terminal with a modem and connect to a server that ran programs on the server and provided a text only interface are long gone and with them this term.  By the way the definition of 'dumb client' meant that the client litterally had zero application processing locally. Only the UI bits are sent across the connection and keystrokes are sent down to the server for processing (every keystroke roundtrips on a dumb client and isn't even echoed to the screen until processed by the server.)

Now we talk about the 'thin client' - a browser or Remote Client Window (think Citrix) as the distributed solution, but even with a thin client the client has some level of processing - for example browsers have Java Script which requires a client processor.  We don't think about solutions that relied on true 'dumb client' hardware.  For example in a dumb client scenario even a solution based on Java Script would need to execute the Java Script on the mainframe server round-tripping the IO to the client. 

Citrix is the closest thing to a dumb client, but of course to run it you need a PC or other fat client capable machine, because Citrix itself is a fat client application, you need a client with processing power to run it.  Thus even the remaining dumb client emulator is a fat client.  Apparently the old 90's argument that there would be a balance between the fat - smart - thin - dumb client applications has been safely decided...  dumb clients are gone clients applications will always be at least thin clients moving forward - and with scripting even the thin clients are getting thicker so you can even see the trend line - heck most phones have more processing power then the old dumb client terminals, and even those mainframes that still run dumb client applications do so using a fat client based emulator...

One of my least favorite errors when I first ran Static Code Analsysis was this security warning:

CA2209 : Microsoft.Usage : No valid permission requests were found for assembly 'IKRulz'. You should always specify the minimum security permissions using SecurityAction.RequestMinimum.

So what is the solution to this warning, and where in the heck do I set these permissions.  Well under .NET 2.0 you need an application manifiest (app.manifiest) file as part of your project settings.  The application manifest basically tells the CLR what type of security your application expects to need, so for example if your application requires full trust your app.manifest will look something like:

<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<applicationRequestMinimum>
<defaultAssemblyRequest permissionSetReference="Custom" />
<PermissionSet class="System.Security.PermissionSet" version="1" Unrestricted="true" ID="Custom" SameSite="site" />
</applicationRequestMinimum>
</security>
</trustInfo>
</asmv1:assembly>

Which is of course a totally simple thing to figure out right?  OK, so does this mean you need to start going to all your app files and adding what are best described as some somewhat obscure XML properties to define your apps security settings.  Well no not under Visual Studio 2005.  With VIsual Studio 2005 you can simply go to your project properties and there on the edit pane is a right hand panel for Security, as you can see below:

Now that you are on the security pane you can choose to enable your ClickOnce security settings.  This will generate your App.Manifest automatically.

But wait there's more.  As you'll probably see in every demo with Visual Studio 2005 it is possible to mark your assembly as having less then full rights.  The key to this is the "Calculate Permissions" button you see above.  This button compiles your code and using reflection determines what permission level your code actually needs.  In my case the code references local files system files, and therefore requires full trust.  However, the ClickOnce options allow you to determine that on the fly and have Visual Studio 2005 automatically determine whether your application will meet your deployment model.

So one of the new features I've found with Static Code Analysis in Visual Studio 2005 is that it allows you to suppress messages.  As I blogged earlier, the typical behavior is for the tool to add a line to your source file to suppress a warning that you find to be unnecessary.  So I was playing with the Namespace related rules which allow you to try and keep variables named appropriately and it flagged the namespace name I used.  I have an acronym as my Namespace and that meant it’s all capitals which of course the rule didn’t like.  So I decided to ignore the warning, only this time since the warning occurs across several files instead of adding a line to each file which referenced the namespace the Static Analysis tool created a new source file called GlobalSuppressions.cs and added the suppression line to that file.  Here are the contents of this new source file in my project:

[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Naming", "CA1705:LongAcronymsShouldBePascalCased", Scope = "namespace", Target = "IKRulz")]

As you can see the only thing in the file is the declaration to create an exception for that rule, but in theory I could add other rules to this file if I found the same message in several locations in my code allowing me to limit the number of times I needed to exclude a particular message.  Of course I could also just avoid running certain rules, but that’s a different discussion.

With the loss of easy access to Flight Line we've resorted to our older route through Calavera.  So this morning at 6:30 we did about an hour on the basic loop through the trails of Calavera.  Eventually we'll look at tracking a time, but the thing with our Calavera route is that we tend to stop at the route's high point.  The view is spectacular, the picture below doesn't nearly do it justice... to put it in perspective about 10 degrees to the right of the power plant was a large white container ship that was visible from the point we call the office - but which just can't be seen in the low quality camera phone picture.... 

One of those things which you need to do every so often and it takes longer then it should to remember how... and even Google does a poor job on a quick search of returning the simple step you need.

After you type in the FTP://site/dir to your browser (and probably gotten a credentials required message) you need to go to the file menu.  On the File menu select "Login As..." and then enter the credentials for the FTP site you are trying to access.  It's simple just not something most of us need more then about once or twice a year.