The Terrible Technical Interview

Look, if you want to talk about code, the easiest and best way to sidestep this issue is to have people bring code (somewhere between 200-1000 lines) to the interview. While they may not have a github presence, they've probably written something on a computer outside of business at some point.

I really don't understand why more people don't do this.

It doesn't even matter if it is their own code. The fact that they will have to talk intelligently about it means that it will accomplish its task.

I used to get this issue interviewing with VLSI chip companies all the time. "Do you know Perl?"--"Yes, I do, but I don't know YOUR particular favorite subset of that write-only language" doesn't go over well in interviews.

After getting tired of getting dinged on questions about a language that I had used for almost daily for 5 years and that I abandoned for good reason, I took an old program of mine from Python and ported it to Perl. I bring both.

Now, I have something concrete to talk about, can actually compare the points of two languages, and most interviewers realize that "Gee, you're probably better at this than I am."

This shifts the conversation from "Technical Jeopardy!" to "Ah, you know how to program, let's look.", "I did this. Here's why.", "Oh, that's interesting. What does that do?", etc.

I conducted quite a few interviews at my previous job and my solution for the whiteboard anxiety problem is to give a set of coding exercises/questions on a piece of paper to the candidate and give him/her as much time as necessary to answer these in private in a separate office.

When the candidate is ready he/she announces it and we review the solutions together.

It is not perfect, but I find it much less taxing than being asked to solve a technical problem in a white board in front of an interviewer.

I am going to have to disagree with you. The whiteboard question does not always work. In fact, while I am generally able to do whiteboard questions without a problem, I had an experience 2 years ago where I completely blanked and was absolutely unable to write any code on a whiteboard. If they had handed me a computer (or if I had not been too flabergasted to ask for one), I would have been fine. In the end, the company in question lost out on my skills and I ended up at a different company. Not really so bad for me, as I have never been scarce of job offers, but it made the problem very obvious to me.

It is easy to dismiss something that you have never experienced yourself. Some people are good at whiteboard interviews and some are not. In my experience, the ability to be good at whiteboard interviews is mostly independent of how good the person will be at their job. The questions are either too difficult to avoid the stress-blanking issue, or too easy to weed out the barely-capable-but-not-someone-you-would-ideally-like-to-hire candidates.

We currently do pair-programming interviews with ping-pong. I write a test, you write the production code, then you write a test and I write the production code. We discuss programming issues as we go. This seems to work well for people who are familiar with TDD and real pair programming (as opposed to: one guy codes and the other guy watches them). It does not work so well for people who have never tried it, though. We actually do most of our work this way, so finding people with this experience is good. Unfortunately, I think we've almost certainly missed good talent just because they don't immediately grasp how this process works. We do some hand-holding at the interview, but then you are always wondering about the person's actual ability.

@jimbobimbo, if you don't mind some unsolicited advice, I would recommend that you revisit your stance on maintaining a few non-job projects. A portfolio that shows what you can do on your own is unbelievably valuable (in terms of real dollars) when you are looking for the next job. I have gotten good jobs in the past simply because someone stumbled across my portfolio and decided to hire me. The time required is not all that bad -- say an hour or so 3 times a week for the next year or two would give you a really excellent portfolio. It also allows you to experiment with techniques and tools that would be too risky to introduce into a project without some experience. Building that experience outside of work, also makes you much more valuable even if you don't switch jobs. I think you will find that while it is difficult to find the time, the pay off is excellent. Avoiding doing low priority overtime at work and replacing it by investing in yourself is a good way to start.

Having said that, my portfolio is currently a complete mess and I really need to spend some time on it ;-)

I agree with this. I'm a reasonable example - I've spent the last year working on relatively internal applications that don't show up in github (only the most recent year is shown there for some reason). I've also contributed to Rails[1], Rubygems, and a bunch of other projects.

[1]: http://contributors.rubyonrails.org/contributors/justin-geor...

Have you thought about jumping into the world of Serious Games?My company is usually looking for experienced game developers with industry talent. The "Serious Games" side of the house is (to me) twice as rewarding as the other side. We don't live and die on the finicky sales cycle of the public and get to focus on delivering cool products that are already paid for by one customer.

If you want to chat more about it, hit me up. me (at) ericharrison.info