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?
Leave a Reply