Manager: Do you have a line in funny patter that goes with your juggling?Candidate: It’s hilarious.

Manager: Well that sounds fine. I guess you’re hired.Candidate: Umm… Don’t you want to see me juggle?

Manager: Gee, I never thought of that.

“It would be ludicrous to think of hiring a juggler without first seeing him perform. That’s just common sense. Yet when you set out to hire an engineer or a designer or a programmer or a group manager, the rules of common sense are often suspended. You don’t ask to see a design or a program or anything. In fact, the interview is just talk.”

Of course, some interviewers are just looking for an excuse to talk about technical issues and will not prejudge you in any way. Speaking for myself, I would laugh if you wrote something like this out. But then again, I once worked for someone who had won the second International Obfuscated C Contest.

What I’m about to say will be blindingly obvious to the Enterprise crowd (sorry, not you over there with the Greasemonkey script that translates your web email to Klingon). The rules must be considered as carefully as the entities. Enterprise developers have known this for years: that’s why you see rules engines, table-driven designs, and visual workflow editors in many Enterprise applications.

In case you didn’t know this, about 1/3 of all technical interview questions worldwide are variants of “How do you fit 10 pounds of crap in a five-pound bag?” Examples: how do you reverse a string in place, how do you sort a billion numbers, how do you write a decent compiler backend for an architecture with only four frigging registers, how do you handle fair scheduling when someone just forked off 1000 copies of some Towers of Hanoi simulation, etc.

I’m exaggerating a lot, but the point is, when you select 1 out of 200 applicants, the other 199 don’t give up and go into plumbing (although I wish they would… plumbers are impossible to find). They apply again somewhere else, and contribute to some other employer’s self-delusions about how selective they are.

And then there is the issue of why would someone care if I knew how to write a file copy function, ahead of what the difference between an interface and an abstract class was. Or when would I use encapsulation? Or in my design, how would I choose between polymorphism or inheritance? Or what pattern would I recommend for dealing with a general or specific problem?

I know lots and lots of interviewers, at many companies, who’ve decided that they can fully evaluate you based on whether you can solve some particular convex optimization problem (or graph-search problem, or logic problem, or whatever their pet Elephant Question is), and they ask every candidate this question regardless of their background or experience. In fact, I’d estimate that some 10% of all technical interviewers ask the same questions, year after year, and they could care less about your experience.

He says: I asked him if the interview process also included an Object Oriented design test, or an algorithms test…nope, just the programming test. Riiiighhht!

I think there's a lot of common ground between these viewpoints. Namely, it is ludicrous to only administer a test. Tests are necessary but not sufficient. That's why many companies need eight or more hours of interviews to hire developers.

I don’t know about you, but before a candidate walks into my office for their first interview, I Google them.

Resumes just aren’t enough to determine depth and breadth of experience. It makes it much easier on me if a Google search produces a hit on a website or blog that contains coding samples and technical observations. I personally also like to see stuff about the candidate. It’s nice to know if they are involved in volunteer work and what their extracurricular activities are. In an interview you can’t really directly ask about personal stuff, but a blog will usually contain those little pieces of information that can provide a bigger picture.

I personally like to work with well-rounded individuals who I know have initiative. You can’t get that from a resume or even during the interview but from a blog...yes. I wrote a post a few months ago where I state my belief that if you want to be an engineering contender, you need to blog about technical stuff. Or at least find some medium to share and help others. Such as forums and articles, where your name is going to show up.

I've been through many interviews lately, and I've come to few conclusions. I've been reading this and other blogs, and now I feel I'm ready to comment.

1. Big companies don't care about any of your experience. They interview fresh graduates and experienced developers all the same. Sorry guys, I'm pretty much tired of calculating the best floor to drop the egg off (and it's the same question in many companies). I hope that some time we can really talk about the projects I did.2. Most companies ask design questions. That's ok, but the problem is that they ask questions about the problems they've encountered themselves and expect you to come up with the same answers as they did, taking into account the specific restrictions they had. I think this is wrong, because their solution might not be the best available and obviously you can't think of the restrictions they have in their project (their solution might be the best under the 100 restrictions they have but they don't tell you about it in the interview). It probably took them several weeks to come up with a good solution that accounts for all the possible problems. I'm sorry, I think I'm a good developer, but not a wizard, and I can't do it in 30minutes. Another example for such biased thinking is that in two interviews I was asked to implement a function that searches a string for one of possible characters given as other string (I don't remember its C name - I'm a more of a java programmer). At one company a simple solution that uses a 256 byte array was fine and was exactly what they expected. At another company they expected me to propose a solution that handles unicode characters as well (using a hash) and were not happy at all about the array solution.3. In some companies I've received a written Java test. In a subset of them they had errors in their test. Were they kidding!?4. Programming questions are nice and I like them. However I really hate writing programs on a piece of paper for two reasons. I'm used to write with a pen and I'm used to write code in several iterations. For example, I can start with checking for some preconditions, then in the middle of the algorithm think of a better idea and start changing the code I've already written. When using a computer (even notepad) there is no problem in doing that. Writing the code on paper makes a huge mess....

re: same question: as an interviewer, i try to ask the same questions of all candidates to get an 'apples to apples' baseline comparison;i also inevitably ask different questions, because each conversation elicits something unique, but i still want that baseline in the mix;

re: asking design questions: i've also commonly asked candiates questions about design and other isses that relate to current projects -- after all, that's what they'll be working on; however, i dont measure their answer against my 'solution'; i try to evaluate on its merits and also to evaluate both the candiate's thought process and communciation skills.