Tell Me Everything You Know…

Recently at work I got asked a couple questions at work about some hiring techniques that we might be implementing. I guess my company is defining and implementing a new hiring practice around the idioms presented in Who: The A Method for Hiring and they wanted my input on a couple of the steps they were batting around. I can’t say I’m for or against such an intensive, well defined hiring pattern yet, because it hasn’t been used yet and I haven’t really been that involved, but it did spark my interest in how I would hire a new developer today if given the chance.

What popped into my head is the “Tell Me Everything You Know…” methodology. My goal when I would interview somebody is to, in the shortest amount of time, figure out everything this person knows about technical things that indicate if the person is a standout developer or not.

Here’s the basic interview structure:

I’d tell them we were going to have a series of 5 minute conversations and in those 5 minute conversations they were supposed to tell me everything they know about whatever I asked them. Rather than taking notes, the conversation is recorded because this is going to happen way too fast for me to write anything down. Plus, I’ve found out over the years that notes I’ve written about most things are incomplete and tend to stall conversations.

What I’m going to be able to tell during this conversation is if they can communicate effectively, context switch quickly, respond to a bit of pressure, and if they have the technological chops I’m looking for. I’d say that the last one is the most important, but in my company if you can’t write a good email or switch your focus quickly, you’re kind of useless. This is the extend of how I would hire a developer. It sounds simplistic, but in my head it works.

Here’s my list of topics that I’d ask about. Everyone’s will be different, but these are ones that are important to me.

Tell Me Everything You Know About …

• Websites
  • HTTP
  • HTML
  • Standards
  • CSS
  • DIV vs. Table Layout
  • JavaScript
  • AJAX
  • JSON
  • Content Delivery Networks (CDN)
  • Verbs: POST, PUT, GET, etc.
    • SEO
  • Sessions
  • Page Design
• Network Communication
  • TCP
  • HTTP
  • Stateful vs. Stateless
• Portable Data Structures
  • XML
  • XSL/XSLT
  • JSON

• Object Oriented Programming
  • Interfaces
  • Classes
  • Polymorphism
  • Inheritance
  • Is-A vs. Has-A
  • Data Structures
• Development Patterns
  • Factory
  • Strategy
  • Observer
  • Command
  • Assembler
  • Facade / Adapter
  • Builder
• The .NET Framework
  • Major improvements between versions
  • ASP.NET
  • ASP.NET Control Lifecycle
  • ASP.NET AJAX
  • Debugging
  • Compilation
  • Runtime
  • IL
  • Garbage Collection (Disposal, Finalization)
  • WCF
  • Win Form
  • WPF
  • SilverLight
  • WF
  • Generics
  • Linq
  • Object Initializers
  • Delegation
  • Anonymous Types
  • Visual Studio

• Software Engineering Lifecycle
  • Discovery
  • Task Estimation
  • Requirements Gathering
  • Rapid Application Development
  • Iteration Development
  • Software Maintenance
  • Software Deployment
  • Short term vs. long term wins
• Databases
  • SQL
  • SQL Server Data Types
  • Indexes
  • Query Performance
  • Storage (trees)
• Storage Technologies
  • SANs
  • NAS
• Testing
  • Unit Tests
  • Black Box vs. White Box
  • Load
  • Requests / Second
• Cloud Computing

• ProgrammingTools
• Visual Studio
• Fiddler
• Firebug
• Web Developer Toolbar
• Yslow
• IE Developer Toolbar / IE8 Integrated
• Website Performance
• No. HTTP Requests
• Compression
• Images / Sprites
• Tables
• Content size
• JavaScript Execution Engines
• CDN

Maintaining ASP.NET Session State in an Ajax Application

Recently, I’ve been working with applications that require very few postbacks. While this has been great from a usability perspective, after all the application is very ajaxy and responsive, it’s caused some unexpected problems. One problem that it caused is that ASP.NET Sessions were expiring even though the user was actively using the application.

The Sessions were expiring because the user wasn’t causing a postback (full or partial) and thus executing the ASP.NET page life cycle, which takes care of maintaining Session for us by implementing the IRequireSessionState interface.

One way I could have solved this problem is to rehydrate Session whenever an Ajax request was received (such as by marking the web method as requiring Session), but this is a bad programming practice for a few reasons. First, having Session attached to a request and response isn’t very RESTful and breaks at least a couple of design rules. Second, it’s a relatively expensive operation to pull Session from the session store, deserialize it into the Session object, use it, maybe modify it, and then serialize it back out to the Session store when the request is complete. As Session gets bigger, this operation gets more expensive and I really want the Ajax features of the application to fly. Finally, I might not own the REST endpoints that I’m using for my application’s functionality. In that case, I’m talking to a third party service (i.e. Amazon’s S3 service), and not communicating at all with my application, but I still need to keep Session alive. The user doesn’t know or care that I’m talking to Amazon. They just think they’re using my application.

What I really wanted to do was sometimes revalidate Session while the user interacted with the Ajaxy parts of the application without the user paying any perceivable performance penalty and not breaking too many rules of application design.

Fixing Sys.Application.initialize … Again

Download the text version of the changes

In a past post, I highlighted a problem with the method ASP.NET AJAX uses to determine if the DOM is ready to be modified. (Other developers have since commented that they’ve seen this problem in the wild.) I followed that post with another one where I provided code changes to fix the problem. Through comments on that post, talking with other developers, and reading other people’s blogs, I determined that it was a little bit unelegant and didn’t take into account all situations.

Encosia.com Control Contest

Dave Ward of Encosia.com has setup a control writing contest where you can win one of three free copies of Adam and my book Advanced ASP.NET AJAX Server Controls for .NET Framework 3.5. (Next time, I’m definitely coming up with a shorter title!) Adam and I are going to be judging along with Dave and there are many ways to win so hop over to his site, read the post, and write some code (or documentation)!

Good luck and thanks for putting it together Dave!

Adding Google Chrome to ASP.NET AJAX

12/15/2008 – Two things to update:

First, sources at Microsoft confirmed this bug for me and said that a fix was already completed for v-next. I’m not sure when the next release will take place; if it will be with VS 2010 or sometime earlier, but they have it fixed.

Second, Jason Kealey has a fix that is less intrusive than the one I suggested here. You can find it here

Since the rest of the tech-world is talking about and trying Google Chrome, I thought that I’d give it a whirl and see how it interacted with ASP.NET AJAX. I’ve worked on a couple of ASP.NET AJAX applications for work (including a public website: http://showcase.costar.com) and have a bunch of small test application that I’ve written for other purposes and was curious to see how those held up when accessed with Chrome. For the most part, with the smaller applications the browser worked as expected. I had almost no layout issues (as we program for IE6, IE7, FF2, and FF3) and almost no JS problems. But, when I ran ShowCase, which uses UpdatePanels to load large swathes of a page and in doing so loads external scripts dynamically, the application broke when accessing the mapping portion of the application. Since I was responsible for this part of the application, I needed to investigate further.

Book Review: Encosia.com

Dave Ward, of the site Encosia.com, has put together a great, well-written review of our book, Advanced ASP.NET AJAX Server Controls.

Check out the review here: http://encosia.com/2008/09/03/review-advanced-aspnet-ajax-server-controls/ and while you’re there check out some of Dave’s extremely useful blog entries on ASP.NET, JavaScript, and other topics.

Thx again Dave for the nice review.

.NET 3.5 SP1 Doesn’t Provide Composite Script Registration from an IScriptControl (out-of-the-box)

Note: Below the following little story, there’s a work around that I came up with so if you’re looking for help, jump down a bit.

The Story

A story of despair. Here’s how my evening went.

Act I Scene I: I just downloaded and installed the Visual Studio 2008 SP1 / 3.5 SP1 and I’m excited to take a look at how to use the Script Combining mechanism. I’ve been using the ToolScriptManager’s script combining ability for a while now, and while it is okay, it has its quirks and I was hoping the one in .NET 3.5 SP1 would be better.

Act I Scene II: I notice that the ScriptManager has a new templated section called CompositeScript. This is the spot I need to investigate closer.