When conducting phone interviews, I like to ask a few technical questions just to make sure that a candidate isn’t trying to blow smoke up my… well we don’t need to be overly illustrative do we?

I absolutely do not intend the questions to be nitpicky. Nor do I feel they are totally representative of an interviewee’s depth of knowledge. I save the probing questions for an in-person interview.

However, if a candidate claims to have one or two years experience working with ASP.NET, there are some basic facts and principles that a mid-level developer should know.

For example, please compare and contrast the result when calling Response.Redirect and Server.Transfer from within a Page class. It boggles my mind that most candidates I talked to couldn’t answer this question. These methods are used quite commonly and the differences are important.

Sure they both present the user with the contents of a new page. But how they do it has ramifications for you web app. With a call to Response.Redirect, the server basically sends an HTTP header back to the client browser with an HTTP status code stating that the object has moved along with the new location to find it.

See the snippet of an example HTTP header below when Response.Redirect("somewhere/newlocation.aspx") is called.

HTTP/1.1 302 Object movedServer: Microsoft-IIS/5.0Location: somewhere/newlocation.aspx

This tells the browser that the requested resource (page) can be found at a new location, namely somewhere/newlocation.aspx. The browser then initiates another request (assuming it supports redirects) to somewhere/newlocation.aspx loading its contents in the browser. This results in two requests by the browser.

One ramification of this is that if the initial request was a form POST, the posted form fields are not available in the second request. Likewise query string parameters are unavailable unless the page that issues the redirect explicitly tacks them on. Also, since the browser initiates the second request, it is possible to redirect to a page on an external site.

In contrast, Server.Transfer transfers execution from the first page to the second page on the server. As far as the browser client is concerned, it made one request and the initial page is the one responding with content (this point often confuses new ASP.NET developers as the browser still shows the URL of the initial page even though the content is generated by the second page. It all makes sense when you understand what is happening.).

The benefit of this approach is one less round trip to the server from the client browser. Also, any posted form variables and query string parameters are available to the second page as well (however these can be cleared by passing in false for the second parameter).

One thing to be aware of is that if the first page wrote something to the Response buffer and you don’t clear it, then any output from the second page will be appended to the output of the first. This is often the cause of a weird behavior where it seems that a page is returning two different pages. Also, since the transfer happens on the server, you cannot transfer a request to an external site.

You’ve been warned. Make sure you wow that next interviewer with your knowledge of ASP.NET.

For extra points, explain how ASP.NET sometimes returns a “View State Is Invalid” error message when you call Server.Transfer(“URL”, true). The explanation is here.

Also, note that the “Response” and “Server” objects I refer to are properties of the System.Web.UI.Page class. The types for these objects are System.Web.HttpRequest and System.Web.HttpServerUtility respectively.

If you like understanding how things work under the hood, I highly recommend Fritz Onion’s book, Essential ASP.NET 2.0. It is personally my favorite book on ASP.NET as it covers only what is essential, but at a deep enough level to really get something out of it.

His 2.0 book is actually a continuation on his 1.0 book, Essential ASP.NET With Examples in C#.