A Proposed Solution to the Software Engineering Interview Problem

Recently I’ve been pondering the plunge into the tech-related job market from academia.  In the process I’ve read several interesting howto’s, gotchas, tips and tricks of the interview trade.  I found this one particularly apt because it shows that someone can just memorize these little puzzles and seemingly pass the interviews with flying colors.

I purchased Cracking the Coding Interview a while ago and have been looking at some of the stuff in there to refresh myself for any upcoming interviews.

I got into reading this interesting post last night and I think it’s kind of opened my eyes to the fact that there seems to be a lot missing in the connection between finding the right talent and interviewing properly.  I got to thinking about what I might change in the process given the problems and shortcomings a lot of folks have mentioned.  I know I’m late to the party.  I know that a lot of smart people have thought this through and we’re still not there yet in terms of finding the right fits for folks.  Anyway, below are some of my thoughts:

When I am making my own first impression of someone’s technological prowess, despite anything that I know about them a priori, I find that simply watching them interact with their machine is my step_zero label.  What do I mean by that?

• How efficiently do they pull things up when you ask about a function or a file?
• What editors are they using?
• What’s their work flow like?
  • When googling something do they fire up potentials in new tabs or just go serially down each link and back if it’s not what they were looking for…?
• What browser are they using (and why?)
  • How many toolbars, extensions, and bookmarks (and how are they organized?)
• How fluent are they with keyboard shortcuts and touch pad gestures?
• And less critically, but still something I notice:  how cluttered is their desktop?
  • I don’t care about this one too much as long as they’re not constantly searching for something amidst the chaos.

I’ll readily admit that I’m old fashioned on some interface aspects.  I haven’t quite figured out the best way to use my fingers on a touch pad to scroll on webpages or word/pdf documents, so I tend to resort to the mouse wheel (when available) or the arrow keys or pgup/pgdn to navigate.  That’s one that I’m actively trying to change because I think using the touch pad is more efficient.  But I haven’t been able to practice it all that much or I’m just being stubborn, probably the latter.

OK – so if we acknowledge that computational prowess might indicate a successful candidate, how would we go about observing that innocuously?

Which leads to another major complaint about the hiring process:  that folks get stressed in pressure situations and often aren’t given a computer to work on because the interviewer wants to see their ability to communicate and their problem solving skills on something like a whiteboard.  These are known issues.  So I don’t think you can just hand someone a laptop and watch them interact with it over their shoulder without running into the same problems.  In fact, most people I know (self included) hate it when people are staring at their screens over their shoulder.

However, imagine a scenario where you’re recording a prospective’s interactions with the mouse, keyboard, and the screen during an interview in a sandbox of sorts on the user’s computer.  So the prospective hires have all access to anything they might need:  a coding API, Google, specific language syntax cheat sheet, IDE with a debugger, whatever you might have on a company workstation.  Now you give them a task that is relevant to your position and watch how they implement.

• It’s officially un-timed, though the interface is timing it simply for logging
• It’s not monitored, saving everyone time
  • I think if I were a hiring engineer I would hate those moments where I just posed the question and the person is thinking about it.  I cannot think of a bigger time sink, and maybe that’s why software engineers hate interviewing!
• The solution is not specified, and you could build analytics and automated testing suites to check the problem you specified without ever having to look at it.

I think it could be an interesting approach, but what do I know.  What do you think?  Is this nonsense?