I haven’t posted any updates for awhile… things have been a whirlwind for the past couple of weeks. I’ve switched jobs, and am now working at Merge eMed, a software company that specializes in radiology software. I left CTI for various reasons, but it was definitely the right time to move on, and I’m excited about my new position with Merge.

Instead of blogging, I’ve been spending my nights (to the frustration of my wife!) working on Cricket, a library written in C# 2.0 that leverages the .NET remoting layer to allow dynamic late-binding to COM components. It’s based on an idea by Omar al Zabir, which I’ve re-implemented and extended a bit. The concept is excellent, and I hope with some work I can turn it into a solid open-source project.

The basic reason for Cricket’s existence is that the interop facilities in .NET, while impressive, are a bit lacking. Your code can only communicate with native COM components via a runtime-callable wrapper (RCW), which lives in an interop assembly (IA). Even if the interfaces you’re using on the COM components are the same for all versions of the application, the IA is still version-specific. Anyone that’s ever tried to write managed code that interops with Microsoft Office will feel my pain; for example, if you want to write code that will work against Office 2000 and later, you have to actually install Office 2000 on your development machine and code against it. If you write against an IA generated against the COM libraries of Office 2003, it won’t work on any earlier versions, even if you sign a waiver that says you promise to only use the functionality provided by the earlier versions, or if you sacrifice a goat to the dark COM overlords.

Another problem with interop is the inability to use the Dispose Pattern to free the unmanaged COM resources without introducing some sort of managing object or shim. This can lead to really irritating problems. For example, if you interop with Microsoft Excel, but you forget to call Marshal.FinalReleaseComObject() to reset the CLR’s reference count to zero, you’ll create a “zombified” Excel process that refuses to die even if you offer to let it eat the brains of your company’s entire marketing department. The only “real” solution is to wrap the COM objects in a shim class that implements IDisposable and releases the COM references in its Dispose() method. This leads to a whole bunch of using blocks and a lot of ugly code.

Cricket fixes these problems by extending the mind-bending RealProxy class to create a customized proxy class that intercepts method calls sent to COM objects. More information will be coming once I release Cricket upon an unsuspecting public, but for now if you’d like to know more I encourage you to read Omar’s Code Project article and snag his source code to take a closer look.

Within a few days, I plan to release an alpha version of the library as open-source — probably LGPL, but maybe something more trendy. :) My next task is to replace the reliance on the remoting layer with a code-generation framework based on SRE (System.Reflection.Emit) — particularly for easier support for COM events. Right now, you have to write a custom event sink for each class which implements the COM event interface that you want to work with, and you have to muck with proxying the arguments to the events and so forth. It works, but it could be much simpler if I can get it to gen the code on-the-fly.

I just transferred the site over to DreamHost! So far I’m very impressed. If there’s anything flaky about the site for the next couple of days, it’s probably either due to the move or because I’m tinkering with something. :)

A friend and former co-worker, Jack Altiere, wrote a very good article about the process of interviewing from both sides of the table. He has some very good insight into the issue, so I figured I would add my two cents.

Jack makes an excellent point that interviewers should ask candidates to write a piece of code on the spot during the interview. He suggests asking candidates to write a string reversal, which is simple and straightforward enough to be an excellent test of a candidate’s ability. However, based on some discussion of the questions to ask, a lot of the things people think you should ask are way too complicated or just completely off base. For example, why in the world would you ask a prospective candidate to detail a possible algorithm to solve a Sudoku puzzle? A good answer to that question could be a defensible master’s thesis. Unless you’re hiring them to write artificial intelligence for games, stick to more realistic tests.

Here are some guidelines for questions to ask:

• I’ll copy Jack by saying that you should let them write the code in the language of their choosing. Unless you’re hiring someone specifically for their talents in a particular language, let them write what they’re most comfortable with. You’ll get a better indication of their real abilities if they aren’t burning cycles trying to remember syntax.
• Forgive minor syntax errors. The interpreter/compiler that comes with a piece of notebook paper is limited in its error checking ability. However, if the candidate clearly doesn’t know the difference between char and char*, ask them politely to explain why they wrote it the way they did. If they don’t know, end the interview early.
• Unless the candidate’s title will be Director in Chief of Trivial Knowledge, Don’t ask stupid questions about mundane features of a programming language. Instead, present them with realistic problems that you feel a person of their skill level will be able to solve.
• Likewise, unless they’re going to be doing FEA in Matlab or something else particularly math-heavy, don’t give them bad flashbacks to college math courses by giving them brainteaser-like problems to answer.
• Test their ability to debate (an important trait of good developers) by asking an inflammatory question about a language/technology they display an interest in. For example, if they mention that love Java, ask them why the language lacks support for pointers. If they present a successful defense, give them major points.

Above all, remember that the interview is an extremely stressful and unnatural environment. Although the ability to think and act under that pressure-cooker situation is a good sign that the candidate knows his/her stuff, the inverse is not necessarily true — even if they don’t do well during an interview, they may actually be very capable.

An alternative (or complementary) tactic to asking the candidate to write a piece of code is to ask for a code portfolio. Artists and graphic designers maintain a portfolio of their work, and I believe software engineers should do the same. Seeing examples of a person’s coding style is an instant snapshot of several things:

• Their general skill level with the language the code sample is written in. Do they take advantage of the important features of the language?
• Their understanding of data structures and algorithms and the “best practices” related to them. Watch for common use of things like bubble sorts. If you’re feeling particularly sadistic, ask them about the asymptotic complexity of a particular block of code. Give them points if they at least recognize the term, and major bonus points if they can give you the big-Oh notation.
• Their understanding of good code-writing practices in general. Make sure their program doesn’t contain any 3,000 line for loops, and watch for proper indentation, commenting, etc.
• Their reliance on “shunned” features of programming languages, for example, overuse of globals in C, any use of the goto keyword outside of GW-BASIC…
• Which way they lean on the incessant debate between imperative, functional, and object-oriented languages. (Just because they wrote 1,000 lines of C doesn’t mean they could write 1,000 of LISP.)

In addition, you can review their code and ask questions about how/why they implemented certain things certain ways. If possible, ask for the portfolio ahead of time and have some questions prepared for them. Like I said, the ability to debate is an important skill, and being able to explain and defend a creative idea is a very good indicator as to whether or not the developer will be a good asset to your company.