The Ideal Interviewer

I've found it helpful when interviewing and it's becoming obvious the interviewee "really needs to hit Google" that you just say, "Just write the function down with some appropriate parameters and keep going". For instance, it's easy to have year and years of very detailed experience in a language, yet still not quite remember off the top of your head how to open a file and read some lines out of it, which turns out to be something that you do far less often than you might think, because it's often totally abstracted away. If you haven't got any clue what to do with a string, on the other hand, that's probably a problem.<p>You still get what you need as an interviewer; even if you don't know the parameters, you should still see basic error checking, you can learn a lot if they don't provide the correct parameters, etc. This approach also allows you to implement the "don't know the language" interview; I don't really <i>know</i> PHP but I've interviewed people in it, because I know it well enough to see the things I am looking for. In that case I don't even <i>know</i> the precise parameters to open to "nail you" on them in the first place! But that's not what I'm looking for.

I've been firmly freelance the past few years, but occasionally look in to the 'job' world (not being derogatory there). I've gone through a few interviews, and I'm amazed at how poorly people usually do it. I'm also amazed at how <i>differently</i> some places treat interviewing for a fulltime job vs interviewing for a 6 month contract. My own experience is that the people talking to you about a fulltime gig may drill you pretty hard on rather trivial stuff, but if you're coming in for a short term contract, or in a consulting role, there's often little vetting - there's an assumption that you already know stuff. Very odd, imo.<p>Sometimes I feel a bit insulted if they don't do some background checking. I'm not a superstar well-known name, but I do have a unique name - there's only 2 of me in the world that I know of, and one is my uncle :) I've published open source code, I've run a blog (a lot of tech on it) for a number of years, run a web-development podcast, spoken at numerous web/tech conferences, as well as other stuff. Googling my name brings up loads of stuff about me and what I've done. Yet given all that, I'll talk to an interviewer (after someone's already reached out to me based on what they've allegedly found) and I'll get "so, tell me what you've done" or "what's your involvement in the community?". Good Lord, it's all there - 20 seconds before a phone screen would yield loads of info. <i>I</i> go to the trouble of learning what I can about company X, yet the courtesy is rarely returned.<p>Hint, recruiters - I have a note to recruiters on my main site. If you mention that you've read it when you reach out to me, you'll get my undivided attention simply because you bothered to read it.<p>Loads of 'old school' interviewing stuff was drilled in to me years ago - be polite, on time, courteous, do research on the other party, express interest, ask insightful questions, etc. If the other party doesn't show the same basic behaviours, goodbye.<p>I struggle with this because there's time when I feel like I'm just looking for an ego-stroke (as my wife has said). But at the same time, I've put time and effort in to my craft, skills, and presentation of same, just like Company X has put in to their org, website, team, etc. If you expect me to know your company and be excited about working with you, research me and be excited about me. Few companies bother taking this approach, then complain that they can't find workers. :/

Lets look at the "Ideal interview" examples, it doesn't look like any of those involved asking technical questions (e.g. coding on the whiteboard)?<p>The trouble is that unless someone is highly referred from a technical coworker you trust, it's going to be hard to know in advance if you have the technical chops or not.<p>Anyone can write down on their resume they've done A, B, C and are well-versed in X, Y, Z. They might even be able to talk the talk. But when it comes to writing code they might completely freeze or write something that would make college students blush.<p>Finally, the time is limited (could be 45 mins, could be 1 hour) during the interview, and the most important thing in most peoples minds is technical chops. That's why I'll usually start out with that (unless the candidate was referred or seems highly qualified, in which case I'll merely get into that later), since it could just weed out the candidate before getting very far.<p>With your regard of "Convince me why I want to work at your company," I think that only happens once a candidate has proven to be worthy. At least in my last company we would be in "sell" or "buy" mode for a candidate (sell meaning we try to convince him/her to join, buy meaning we try to convince ourselves if he/she should join) and it would start out in buy mode.<p>There's nothing worse than interviewing and hiring a candidate with a great personality than just finding out he/she couldn't code their way out of a paper bag. That being said, I do dislike interviews where they spend the entire time just asking technical questions as it should be obvious after one or two, so a particular balance needs to be sought.

I'm trying to become a better interviewer, and it can be very hard. Here's a story of a badly wasted phone screen I did this week. I screened a guy with a graduate degree in math who worked in a network analysis group for a telco. We talked about the current project he was working on, and his previous project, and while it was really cool statistical modeling of network failure and recovery, he didn't actually do any of the modeling or mathematical work. As best as I could tell, he just wrote scripts to munge data into convenient formats for his teammates to import into the modeling software. He knew next to nothing about statistical software. I described what we did and asked him what kind of work he thought he could do for us, and he basically said he'd do network modeling and analysis for us -- exactly what he <i>wasn't</i> doing at his current job, it seemed.<p>Afterwards I told my boss, "This guy is a total miss. He just writes Perl scripts to munge log files. Why did we even talk to him?"<p>"Oh, he's a really sophisticated low-level network performance guy. He has a lot of hands-on knowledge of networking hardware and protocols."<p>Well... shit. I guess munging log files can be more than just munging log files. I couldn't tell that from his resume, though, and he didn't give me any clue while he was talking to me. Was that my fault?

One of the most annoying forms of interview has to be the immediately technical phone screen. I remember talking with startups, and during the initial phone call they'd leap into a canned set of technical screening questions, which themselves are some set of factoids which are supposed to translate to how good of a programmer you are.<p>I understand the need for startups to screen out absolute idiots before they spend time talking with a candidate; it's easy enough, though, to look the guy up beforehand or send the guy a coding question he could work on in isolation. Just make it a policy to only talk to candidates that have something technical you can verify beforehand.<p>In our current tech job market, it makes sense for the company to convince you it makes sense to talk to them further; chances are, if you're any good and someone they want, you can and will get multiple offers anyway. Even if the company wastes "talk time" to candidates that wouldn't make the cut, it's worth not driving away the guys who got annoyed by its strong-hand "we need a strong code monkey" interviewing tactics.

"Don't ask me where I want to be in 5 years...If you want to know if I want to pursue tech vs management, just ask that."<p>I agree. Not that I don't have any long-term goals at the moment, but I expect life to change and I usually flex with those changes so who knows where I'll be in five years?

Probably a little offtopic but if I don't make the cut ... call and tell me or email, don't have me wondering what's going on.<p>Its so simple but an amazing number of companies just will not take this simple step. So rude, and people remember things like that.

Here is a relevant article about how when interviewing programmers you should actually test if they can program: <a href="http://www.richard-banks.org/2009/08/some-developers-just-cant-develop.html" rel="nofollow">http://www.richard-banks.org/2009/08/some-developers-just-ca...</a>

&#62; <i>I understand that C is the "lingua franca" of interviews, but if you read my resume (or even talked to me) you'd know I'm not looking for a C job (and really haven't used C since college). While, I'm open to coding in C, it's cooler if you don't force me to use C.</i><p>The article assumes that the reason someone would ask them to use C on an interview is because it's lingua franca, and they're only interested in the interviewee's algorithm knowledge.<p>Algorithms are great and should be a part of an interview, but I am interviewing software engineers, not algorists: I'll ask about general algorithms (the ones you might find in first half of "Algorithm Design Manual" and in "Programming Pearls"), data structures (where I'll expect the interviewee to understand pointers: whether in a language like Python or Java, where every value (with exception of Java's primitives) is a pointer or in a language like C where pointers are explicit).<p>I'll also ask about algorithms specific to their job, or (if I am interviewing a candidate for another project, as a part of a panel) I'll leave that to other interviewers. If, for example, somebody lists ten years of distributed systems development they should be familiar with the various consensus algorithms, pros and cons of them (I will not expect them to implement Paxos, but it would be nice if they know how multi-Paxos and ZAB solve some of the issues Lamport's original algorithm had). Again, this is for experienced candidates being interviewed for a role in which they claim existing experience.<p>There are also simple algorithms (related to string or array manipulation) that are just easier implemented in C. If ask someone to reverse a string in place [NB: I don't actually ask this], they'd have an easier time doing it in C than in Java.<p>However, there's more to C than a language in which to implement algorithms: it's also a systems language. I want candidates I hire to understand how their computers work. I'll challenge them to understand how various system calls work, how parts of libc are implemented, how memory allocation works (and, if I am interviewing a candidate for a Java, Python et all collection how garbage collection works, and in what cases might it fail to work). In this case, knowing C (and having it used it, at least in your own free time after college) is invaluable, not because of the language itself-- but because it's a great portable assembler.<p>I understand people are frustrated when they're expected to know C, even though they won't be programming in it: however, it's not about the language, it's about knowing about an area of computer science that isn't often as glamorous, but is just as crucial as algorithms and data structures.