Is there anything worse than a job interview?

[Roac]

Are you replacing someone?  If so, why did that person leave?

Er, that's a lousy thing to expect an answer to as a potential employee.  Bluntly, it's none of their damn business.  More professionally, this is getting into an area of information which an employer sometimes cannot disclose. 

If there aren't other candidates and the interviewer insists on a specific time, that's a red flag.

No, it's not.  There could be a meeting with vendors/clients scheduled after the interviews.  They could have set aside time to review the cannidate responses.  Either way, it's a seriously trivial point that doesn't require an explanation and doesn't tell you much at all about the company.  Instead of being totalitarian, they could just be busy.

Others have said such trivialities are important because they imply a level of knowledge.  That's simply not true.  If a person spends all his time learning the nuances of C++ and Java syntax but has no idea how to apply good design to code, he's useless.

Don't straw man.  Given a cannidate who knows trivia and one who is a good designer, the choice is obvious.  Given two cannidates who appear to have a decent design background, the one who knows more about under-the-hood operations is superior.  Knowing how the OS deals with threading is vitally important when writing applications that scale up to an enterprise level, even though that's hardly discussed in any programming books I've seen, and entirely transparent to the developer. 
Even though adding web service references is almost trivially easy and using them not much more difficult, none of the classes I've been to have gone into detail about what you need to do if it doesn't work.  Guess what, they didn't teach how to build a web service object based only on a WSDL file in class, because they assumed the drag-and-drop method always works.  Getting errors on the network traffic that aren't registering in your application?  Know how to drop netmon onto the line, then read the TCP/HTTP/SOAP stacks well enough to figure out what went wrong?  That wasn't taught in class either.

I don't expect people to know what the syntax of a command is, but I do expect them to know how to get around in DOS and build programs to execute there (do you know how many techie graduates don't know DOS?). 

[MaceVanHoffen]

Er, that's a lousy thing to expect an answer to as a potential employee.  Bluntly, it's none of their damn business.  More professionally, this is getting into an area of information which an employer sometimes cannot disclose. 

It's not lousy, but that's fine.  That also has nothing to do with my point.  I said it's a red flag, not a deal breaker.  The goal is to gauge the interviewer's response, not to get a factual answer.  Responding with, "He left for private reasons" or some such is fine.  Fidgeting in your chair, becoming subtly hostile, and other physical responses are what I would take notice of.

Don't straw man.  Given a cannidate who knows trivia and one who is a good designer, the choice is obvious.  Given two cannidates who appear to have a decent design background, the one who knows more about under-the-hood operations is superior.  Knowing how the OS deals with threading is vitally important when writing applications that scale up to an enterprise level, even though that's hardly discussed in any programming books I've seen, and entirely transparent to the developer. 
Even though adding web service references is almost trivially easy and using them not much more difficult, none of the classes I've been to have gone into detail about what you need to do if it doesn't work.  Guess what, they didn't teach how to build a web service object based only on a WSDL file in class, because they assumed the drag-and-drop method always works.  Getting errors on the network traffic that aren't registering in your application?  Know how to drop netmon onto the line, then read the TCP/HTTP/SOAP stacks well enough to figure out what went wrong?  That wasn't taught in class either.

I don't expect people to know what the syntax of a command is, but I do expect them to know how to get around in DOS and build programs to execute there (do you know how many techie graduates don't know DOS?). 

All of the things you mention, including DOS, can be learned quickly and will be already known by someone who can "straw man" as you put it.  If that person doesn't know them, it will come out quickly when they explain answers to more appropriately abstract questions.

Also, netmon is one way out of dozens to debug a web service.  Asking someone if they know netmon is really a way of asking if they can do it your way.  That isn't useful information.  What is more useful is how the interviewee would do it, and why they would do it that way.  You seem constrained by the facts you already know.

What you value on an interview is what you'll hire.  Legions of replaceable robots who understand DOS and a litany of three-letter acronyms but who cannot produce something of substance for a customer are not what I value.

[Paelos]

The more I think about it, the less I want this job. It would be basically rewritting the Utah tax code at the behest of a bunch of legislators I have no respect for.  Decent money and government bennies, but would have to sacrifice a good chunk of my progress on my Ph.D.  Since I don't want it they will obviously offer it to me.

Ugh, tax codes are awful. And yeah they will offer it to you now that you don't care.

[Pococurante]

(1)  Find out how much importance is placed on mundane matters, such as daily work schedule and dresscode.  If it's more important to the interviewer that you be on time than that you do a good job, move on.  Those places always produce substandard products because they are full of politically-motivated, upwardly-mobile people who are unable to tell if you're doing a good job (that's why they focus on something even a baboon can measure, such as schedule).

Agreed.  And thank you.  I understand why Mi Tes emphasized the opposite but I have to say unless someone is trying to land a first big job, has a crap skillset/self-esteem, and doesn't care that they may well be pigeonholed into one deathmarch after another it is better to find companies that define flexibility as a two-way street.  (I made that mistake but mainly because I hit the streets after graduating in a deep recession and my first child-support check cam due six months before - yuck those times sucked)

For a first big job I strongly recommend a small scrappy company or a middle-tier consultancy (not body-shop contractors).  One is less likely to learn bad habits or burn out, and you'll wear so many hats you'll quickly discover your inner over-achiever.  Any family you're likely to pick up on the way will love you more too.

And yeah they will offer it to you now that you don't care.

Actually taking that stance does wonders for one's confidence.  I don't mean act cocky and arrogant.  Just get one's head on straight that this is a process and not a one-time shot at the brass ring.

[voodoolily]

Poco gives good advice- I graduated during the 9/11 recession, and was able to find work at a crappy 3-dude firm within a few months. Turns out the company has a terrible reputation, and I was hired by the firm I work for now half out of pity, and half out of wanting to get the dirt on my old boss.

[Roac]

All of the things you mention, including DOS, can be learned quickly

Unless the job is entry level, most companies don't want to train new hires in anything outside business rules.  Again, I'm sure that the cannidate can learn all the things they don't know in the interview.  They can go learn them then come back and re-apply, because there are cannidates who already know them, and I can hire them instead.

Asking someone if they know netmon is really a way of asking if they can do it your way.  That isn't useful information.  What is more useful is how the interviewee would do it, and why they would do it that way.

Except I didn't say they had to know how to use that one tool.  Some flavors of Win don't come with it, and whatever their favorite tool is may not be available (no, we're not paying for it) or can't be used (can't run on that OS, etc).  The point was to note that picking apart network traffic is normally outside programming cirriculum because it's often assumed it's handled elsewhere or handled correctly.  Fantastic, you're using winsock.dll, or importing sock.h.  And it doesn't work.  Now what?

It's the kind of problem that someone who has had to deal with network interfaces will understand, yet it's obscure enough that someone who has been reading books won't know exactly how to fix.  You're right, I expect someone to be able to cope with this, because we deal with dozens of vendors (literally - I can count over twenty vendors with socket interfaces to just one of our systems) who unfortunately aren't always up to snuff.  I won't hire someone green, because I don't have to.  Sorry if it strikes a cord with you, but when comparing someone with design experience, and someone with design experience and who has delt with problems we face, guess who I'm going to hire?

And with respect to DOS - if you don't know how to use it you sure as hell don't have experience in Java or C, and can't do some of the more interesting things in .NET.  I can pretty much rule out them having done console debugging, knowing anything about strong names, linking different .NET language resources, etc.  I'm sure they can learn all about it, but I'm not paid to be an instructor, and I'm not paying them to start from grade school.

[Margalis]

Example:  "What is the difference between the Set-Cookie header and the Cookie header in the HTTP protocol?"  I happen to know that cold, but it doesn't matter.  Skip that job.  You can use Google to find that, and if you value your employees' minds being filled with such rote facts then you obviously don't care how well they perform at higher levels of thought.

This sort of thing really depends on the level of the position. At my job I know a lot of stuff (including your question above) that could take years for someone to accumulate. If they are being hired as a mid-level working that's fine, if they are being hired as a tech lead it isn't. If they say they've done a lot of low level HTTP stuff they better know what the headers mean.

There *are* things people can look up, and I give allowances for someone who says they haven't worked on that thing in a while. But there are also things you might think you can simply look up that turn out to be more complicated, and it's possible to just have too much damn stuff to look up.

I care how people perform at ALL levels of thought. They had better know details and be smart if they are applying for a high-level position. Knowing facts is important! It can't always be "hold on, let me go look that up" in response to everything. There is a difference between having an eye for details and being good at memorizing things. If you've done a lot of HTTP work and don't know the answer to your question above I would question how serious that work really was.

Of course, nobody should ask questions of only those types. I try to ask people what they say they know. If they are fresh out of college and have some math on their resume, I ask them what a proof by induction is. If they took data structures I ask them what a red-black tree is. If they spent 5 years on HTTP stuff I'll ask what the difference is between 1.1 and 1.0. (Because, as you can see, I know everything about everything.)

[Margalis]

All of the things you mention, including DOS, can be learned quickly and will be already known by someone who can "straw man" as you put it.

Problem is, if you take 100 things that can be learned quickly and add them all together, that can take a while. If I'm hiring a high-level employee I expect them to hit the ground running. It doesn't have to be either/or, either knowing things or being smart. And if people have worked on something for a while and don't know any of the details I would question whether they ever will. Some people are not detail oriented and will never learn the "trivialities" that are required for work - I don't want those people.

[MaceVanHoffen]

Sorry if it strikes a cord with you, but when comparing someone with design experience, and someone with design experience and who has delt with problems we face, guess who I'm going to hire?

Again, you're studiously missing my point.  I am not talking about the experience of someone you would hire.  I am discussing how you go about figuring out if the person sitting in front of you has that experience.  The route you take to discover that is a filter, and will select the type of person you let in the door.

One way of looking at it:  It's the difference between a multiple choice question and an essay question.  The former tells you only that the new hire knows a certain fact.  The latter indicates not only whether he knows that fact but also how and why he knows it and how he would apply it.  If you want walking contestants for Jeopardy! that can't think much beyond the details, stick to those wonderful black/white knowledge questions.  Most corporations (possibly yours) value only that, since they value replaceable employees who'll work bazillions of hours every week if told to do so (hi there, EA).  That's not a place I'll work.

I think the real problem is that essay questions take time and attention, multiple choice ones do not.  An interviewer's mental laziness is not my concern, and doesn't mean that asking deeper, more thought-provoking questions on an interview is a bad idea.

[MaceVanHoffen]

(Because, as you can see, I know everything about everything.)

To be blunt, that's one of the real reason interviewer's ask those questions:  they like to show off the knowledge they have.

I don't agree that it's such a big deal to look things up.  It happens all the time, more than we all are willing to admit.  Head knowledge is important, but what is more important is how it's used.  Given that if a person can demonstrate a grasp of more abstract concepts, he will invariably talk to you about details.

To run with your example of data structures:  You can ask a deeper question such as, "Given X problem, which type of data structure would you choose?  Why?"  If you have selected X such that a red-black tree is a good solution, voila!  You have a way of discovering what facts the candidate knows without becoming an arrogant, geeky version of Alex Trebeck.  You also get two pieces of information that you couldn't have gotten by asking for dry facts:  what else the candidate knows, and how he approaches problem-solving.

If you want code monkeys, stick to Jeopardy! style interviews.  If you want an employee who'll give you more bang for the bucks of his salary, dig a little deeper.

[voodoolily]

I generally find that if I say anything with enough confidence and conviction, people believe it. But that only works when you know what you're talking about, if not just a little bit.

[Roac]

If you want walking contestants for Jeopardy! that can't think much beyond the details, stick to those wonderful black/white knowledge questions.

Feel free to reference where I said it was a good idea to require employees to know specific, atomic facts.  Go ahead, look it up.

...

Can't find it?  Good.  Die.  There are plenty of things they have to know about; for our business, understanding TCP layers is as important as understanding OOP.  If they've delt with that, they've worked with packet sniffing and reading stacks.  If they haven't, then they aren't in a place to deal with design whatsoever and would be like hiring a Java programmer to do .NET, or vice versa.  The devil is in the details, and if they've never had to deal with details, I know they're full of shit.

Otherwise, anyone with a Visio clone can whip out some diagrams and propose that as a solution.  Until they've actually gone through the headaches of having to put some of them into practice, they're likely not good at understanding why they look nice on paper, and fall flat on implimentation.  Since we're involved in public safety, and people's lives do depend on our software running reliably, implimentation is somewhat important.  Since we have people with 20+y experience doing this - and they haven't been fired or put in the news for screwing up - you can bet that I'm confident that we've got a good system of hiring the right staff.

[Samwise]

I generally find that if I say anything with enough confidence and conviction, people believe it. But that only works when you know what you're talking about, if not just a little bit.

It's true, confidence goes a long way.  Just make sure not to get caught telling a lie confidently or you're probably fucked.

[Roac]

I generally find that if I say anything with enough confidence and conviction, people believe it. But that only works when you know what you're talking about, if not just a little bit.

It's true, confidence goes a long way.  Just make sure not to get caught telling a lie confidently or you're probably fucked.

Instead of a lie, I've seen it come back to exaggeration.  Applicant says they worked on a nationwide system that did x, y, and z.  Great.  What part did they work on?  Oh, just x.  Ok.  What technologies did you use?  How was it designed?  Using what tools?  How did it fit into the other components?  What problems happened when you brought it up?  How did you handle such-and-such situation?  Never saw it, huh?  Strange.  Any idea what you might do if you did? 

Maybe it's different in other industries, but it's hard to bullshit into an IT job just because it's so easy to nail down what someone qualified should know.  Great, you know skill X?  Well we're not looking for that, so we'll just talk about where the crossovers might be into skill Y, which we do use.  Now talk about experience with Y, which I am familiar with, because it's what we use (and will continue to use for a while - business requirements and all). 

Now, confidence *is* good, because it suggests experience and familiarity and certainly expresses good communication skills (important).  Don't want to go into a meeting with the execs only to have someone be (consistantly) uncertain about what we should do, or to know what we should do but make the execs uneasy because they don't seem to understand it or want to get behind the proposal.

[Samwise]

Great, you know skill X?  Well we're not looking for that, so we'll just talk about where the crossovers might be into skill Y, which we do use.  Now talk about experience with Y, which I am familiar with, because it's what we use (and will continue to use for a while - business requirements and all). 

Hell, I'll quiz them on skill X if I'm competant enough with X to do so.  Even if X itself doesn't pertain directly to the job, I'm curious about two things:

1) Are you a lying douchebag?  If so, I want to catch you right now and waste no further time.
2) If not, can you effectively communicate what you know about X to me as if I didn't know it?  (I usually interview for tech support positions, so communication skills are a must.)

[Margalis]

To run with your example of data structures:  You can ask a deeper question such as, "Given X problem, which type of data structure would you choose?  Why?"  If you have selected X such that a red-black tree is a good solution, voila!  You have a way of discovering what facts the candidate knows without becoming an arrogant, geeky version of Alex Trebeck. 

What prevents me from asking both? I will agree that an interview which is simply yes/no or "what is this" over and over again is not a good interview, but those things are important to ask.

I ask about red/black trees if someone took data structures at MIT because I know they cover that and I want to know if they learned something in the class or not. If they say "red black trees are roughly balanced but I forget how exactly but it has to do with alternating colors of nodes" that's pretty much good enough. And if they have no idea that doesn't mean they are out the door unless it is a pattern of behavior.

If you are ONLY being asked dry facts that *is* a reasonable red flag, although often it means the particular interviewer just isn't good. But as an interviewee if I say I am an expert Java programmer and someone asks "what does the static keyword mean" I will happily answer because I know I've talked to 'experts' that didn't know that. And I would never ever hire anyone that didn't know that, because in my mind it means they haven't done any significant programming. I'll also ask people if they knew CVS and Eclipse because we use those things, but if they don't that's ok. That's more for my informational purposes. Not every question I ask is a litmus test, some of it is simply if we do hire this guy what are we going to have to be prepared for?

[MaceVanHoffen]

If you want walking contestants for Jeopardy! that can't think much beyond the details, stick to those wonderful black/white knowledge questions.

Feel free to reference where I said it was a good idea to require employees to know specific, atomic facts.  Go ahead, look it up.

Um, ok.

Given a cannidate who knows trivia and one who is a good designer, the choice is obvious.  Given two cannidates who appear to have a decent design background, the one who knows more about under-the-hood operations is superior.  Knowing how the OS deals with threading is vitally important when writing applications that scale up to an enterprise level

Know how to drop netmon onto the line, then read the TCP/HTTP/SOAP stacks well enough to figure out what went wrong?

Those sure sound like specific, atomic facts.  But whatever, we can agree to disagree.

[MaceVanHoffen]

What prevents me from asking both?

Nothing.  If you start with the more general, abstract questions, you'll get my desired result.  I would personally ask more specific questions if I felt the candidate hadn't expressed quite what I was after.  But those questions should always allow room to expose deeper thinking, e.g. "So you say you'd use a b-tree for that, that's a neat idea.  How you would feel about a red-black tree?"

I will agree that an interview which is simply yes/no or "what is this" over and over again is not a good interview, but those things are important to ask.

And that's exactly where I disagree.  "What's this?" questions are never needed in an interview, and abstract conceptual questions are always preferable precisely because in the course of explaining an answer to such a question, the candidate must explain relevant details that expose his knowledge (or lack thereof) in a way that selects for people with a greater command of the subject than a "What's this?" questions will expose.

I don't want to work with programmers who understand what "static" means but who can't code a patch program that works, can list out the layers of the OSI network model but are unable to write network code that is extensible and maintainable, and who can spout acronyms and their meanings but who cannot determine which technologies are good and which are bad for a particular application.  I bet those WoW programmers aced all those trivia questions.  How's that patch program working these days?

Asking dry, factual questions, even once or twice, sets a precedent that that is what you believe to be important.  First impressions are a bitch.

[Margalis]

Asking dry, factual questions, even once or twice, sets a precedent that that is what you believe to be important.  First impressions are a bitch.

Well I have to say I think that's just silly. I'll ask you what static means, because if you don't know I know all I need to right there. Your chances of being hired are zero percent.

I think you are doing yourself and others a disservice with your advice if you consider it a red flag if someone asks ONE OR TWO factual questions. The only precedent it sets is that you should know some basic facts. If you aren't after a job like that ok. And I DO think that knowing what static means is very important for a Java dev. That's a minimal bar.

If I asked someone what static meant and they acted like the question was beneath them that would be a red flag to me as the interviewer. If you know the answer state it concisely and we can move on to more interesting topics.

I believe knowing stuff about your job is imporant. That's a precedent I am willing to set, and more than that, wanting to set. Again, there is a difference between trivia questions and actual important knowledge. If you claim you know a lot about HTTP, you damn well better EXPECT me to ask you about it. In that case the difference between Cookie and Set-Cookie isn't trivia - it's something you should know if you did what you say you did.

I agree that asking about silly acronyms and such is mostly a waste of time. But there are people who, when you ask them about synchronization, say "well I don't remember the exact Java implementation but it has to do with monitors and such." Yeah, it does, welcome to CS101. Unfortunately being able to talk a great game about synchronization isn't enough.

Those things you call trivia are what I call evidence you got your hands dirty and did something. Being able to talk a good game is evidence that you understand what it is you are supposed to do. Knowing details means you've tried rather than understood, which is quite difference.

The stereotype of the guy who knows all the trivia and sucks is somewhat valid, but no more valid than the CS PhD who is a master of all theory and can't actually accomplish anything in any real computer language. I'm sure they could explain in great detail how to write great network code, and it looks fine and dandy until you set them in front of a keyboard and it turns out pseudocode doesn't run on real machines.

The idea that you would mentally write off an entire company because an interviewer asked you what static meant is pretty weak. I think that says more about the interviewee than the interviewer.

[Triforcer]

Everyone on page 2 of this thread sounds like a mean boss 

[Pococurante]

Nope, I'm an awesome boss.  I give a lot of lattitude as long as I get results, and I'm quick to trim the deadwood because they're not fair to the real players.  I've also learned people with strong capacity for memorizing trivial shit are usually not creative thinkers.  But that's cool too since sometimes I need an unimaginative specialist who doesn't constantly climb up my ass.  But usually I want people who think well & creatively under pressure - people like that don't memorize trivial shit and know where to go to quickly flesh out their hunches.

[Margalis]

I guess it depends on what you call trivia, but the notion in this thread that knowing actual information is trivial is silly. I think it's pretty reasonable to assume that people who have spent years doing something should know a lot of what outsiders might consider trivia.

Anyway I'm an ok boss. I pretty much let people do what they want as long as they aren't really screwing up. I think I'm a great technical lead, as a manager-type I'm probably mediocre. I don't annoy people or demotivate them but I'm probably not a great motivator either. That's probably because my own personality is that I don't take praise kindly, for the most part I'd like to just do my job without a lot of fanfare. There is quite a large difference between a technical lead and a manager; right now I wear both hats but technical lead is clearly my forte.

I can be very patient (in college I was everyone's favorite TA because I would have tons of office hours and help people) but I don't like it when people are in a position where they should be really good at something and just getting by. I think it's fine for an organization to have some up-and-comers who don't know that much but can learn, as long as those guys aren't getting paid or placed like they are experts.

[Pococurante]

/shrug

It may well be a matter of perspective.  I don't hire heads-down types so much anymore and usually when I need that flavor of talent I bring in contractors.  We vet them not so much by asking pointed questions and focusing solely on the content of their response.  But rather by sitting them down and having them puzzle through real-world issues.  I learn a lot watching how someone approaches a problem.  Few things make my heart hum more than watching someone noodle the shape of the problem correctly and have the balls to say they'd need to go look some things up to test their assumption.

People who can't admit they don't hold every card in the deck are more destructive than "swivel necks", my slang for someone who needs incredible hand-holding and starts every task by asking someone else what they'd do.  Swivel necks are a nuisance and a moderate drain on other people's productivity, but someone who clams up and plays gatekeeper with their tasks can destroy a project and even the careers of others.

And most managers will never know until it's too late. (Because most managers are too fucking lazy to get out of their chair and walk the floor, but that's a rant/peeve of mine for another day... )

[Roac]

Everyone on page 2 of this thread sounds like a mean boss 

Mmm.  I don't think I am.  I talk tough, especially with my bosses and others on the 'outside'.  Long as my people do their jobs, I sing their praises and get them anything they want that I'm able to get them (and don't stop nagging for the rest).  I do get mean whenever I feel people underperform, because then they're making me look bad.  Last thing I want is a subordinate to screw my career.  Thankfully I haven't had to deal with that in a long while - the few people who I would have to come down hard on have been well warned that they do not want to be in my group, even though at the moment we're the "favorites" (we get all the new tech, whereas the other dev groups are legacy systems). 

*shrug* Someone will probably disagree, but I think you have to have that.  Here's the standard; make it and you're a king, fail to meet it and you will be ridden until you improve, quit, or get fired.  I want people to do well, and will do whatever is reasonable to help them succeed, but I'm not their parent, babysitter, or college professor.  Having a job isn't a handout; you have to earn it, and continue to earn it.  Anyone who can't meet the specs is hurting me, our group, and our department.  No boss would be doing any of them, or the employee, any favors if they said "well, that's ok, just do better next time". 

[Roac]

Know how to drop netmon onto the line, then read the TCP/HTTP/SOAP stacks well enough to figure out what went wrong?

Those sure sound like specific, atomic facts.  But whatever, we can agree to disagree.

Knowing communication technology is a requirement to developing anything besides standalone applications (SOA / enterprise level).  It's more than atomic; you could fill hundreds of pages with discussion on the subject, but isn't something you're likely exposed to if you're a junior programmer.  It would be like applying for a trick driving job without ever having driven a stick. 

Or lets put it another way; next time you play your favorite MMOG and there is net lag, just remember - communications isn't important to know when applying for a job.

[MaceVanHoffen]

The idea that you would mentally write off an entire company because an interviewer asked you what static meant is pretty weak. I think that says more about the interviewee than the interviewer.

No, it says that this ain't my first rodeo and I have nothing to prove.  And you're right, it does say something about the interviewee:  he's in demand and doesn't have to put up with people who insist on doing something silly, like strutting their knowledge like a peacock.  Being a good programmer and a good employee doesn't have anything to do with head knowledge, which anyone can obtain.  Not everyone can obtain talent, intuition, and wisdom.  Those are the qualities a company should be looking for.  They are qualities that cannot exist without the head knowledge, so testing for them is the same as testing for head knowledge.

The interviewer represents the company at that moment in time.  The implication of his selection as an interviewer is that he's the one with abiility to judge the candidate's work, that he's one of the best at the company.  So, yeah, it's emminently reasonable to write a company off because of an interviewer's technique.  If all the company can come up with is someone who can play Trivial Pursuit, then why should I work there?

[Roac]

Not everyone can obtain talent, intuition, and wisdom.  Those are the qualities a company should be looking for.

Gandhi doesn't meet the qualifications to work as a dev.  Sorry.

[Strazos]

Gandhi would also believe that dev's are just one of a billion things which cause the downfall of civilization.

[Margalis]

No, it says that this ain't my first rodeo and I have nothing to prove.

Including a mastery of your domain, apparently.

Being a good programmer and a good employee doesn't have anything to do with head knowledge, which anyone can obtain.  Not everyone can obtain talent, intuition, and wisdom.  Those are the qualities a company should be looking for.  They are qualities that cannot exist without the head knowledge, so testing for them is the same as testing for head knowledge.

That's simply not true. Why are you so willing to buy into the memorization drone stereotype and not the nutty professor stereotype?

If all the company can come up with is someone who can play Trivial Pursuit, then why should I work there?

Does it occur to you that it might be first round interview and the top people aren't going to waste their time if you can't answer basic questions? Or that knowing things like keywords in the language you claim to know is not "Trivial Pursuit"?

Whatever, it's your loss, but it sounds like a silly hangup. I can just imagine you bristling with rage when someone asks what the difference between int and Integer are. Just answer the weed-out questions and move on.

I think your advice is to prospective job seekers is pretty terrible, and you are trivializing the entire world of ACTUAL KNOWLEDGE as useless memorization. There is a name for people who have to constantly look up everything - junior programmers. (Or interns) Ability to learn is great - and if you have that, you should have picked up some things along the way. If you claim to be a great thinker and learner and have to look up everything what exactly is it you are great at learning?

[MaceVanHoffen]

I can just imagine you bristling with rage when someone asks what the difference between int and Integer are. Just answer the weed-out questions and move on.

I don't, and I do answer those questions.  I consider it a red flag, not a deal breaker.

... you are trivializing the entire world of ACTUAL KNOWLEDGE as useless memorization. There is a name for people who have to constantly look up everything - junior programmers. (Or interns) Ability to learn is great - and if you have that, you should have picked up some things along the way. If you claim to be a great thinker and learner and have to look up everything what exactly is it you are great at learning?

Ok, I'll give this one more shot:  I'm not characterizing the entire world of actual knowledge as useless memorization.  I'm saying that there are more important things than knowledge, and that the capacity for abstract thought is one of them.  I'm also saying that it is impossible to be a capable of good problem-solving without knowing the details you mention.  It's problem-solving that is more valuable to any enterprise, commercial or otherwise.  Testing such a capacity is the same as testing head knowledge.  So, my assertion is:  why not focus on problem-solving since that is more valuable, and you kill two birds with one stone?  A corollary would be:  testing for head knowledge alone casts a net that catches those fish with the capacity for useless memorization but without the capacity to use that knowlege effectively.

Or, to paraphrase someone much more eloquent than I:  "Don't confuse school with education."

All you have to do is look at the world of software right now.  We drone on here endlessly about buggy games, but where do buggy games come from?  From people.  What kind of people?  From people who are hired using the most common interview technique.  What's the most common interview technique?  A game show in a conference room.

[Paelos]

This whole tread is getting stupid fast. Interviews are easy. Do your research, don't be late, don't lie, don't crack questionable jokes, do ask questions. That's it. That's as much as you can really control. The rest is up to whatever whim/style your interviewer has. You don't have to kiss ass to get hired, and you won't always get hired even if you are the best at that job.

Life sucks, get a helmet, and beat the street.

[Margalis]

All you have to do is look at the world of software right now.  We drone on here endlessly about buggy games, but where do buggy games come from?  From people.  What kind of people?  From people who are hired using the most common interview technique.  What's the most common interview technique?  A game show in a conference room.

How many game companies have you interviewed for?

That's a pretty self-serving explanation for buggy games. It must the interview process! Is this an example of awesome abstract thinking ability? People makes games, and people are interviewed, so interviews are the problem! Brilliant. Here's another example of great logic: People make games, and people spring out of vaginas, so vaginas are the problem. It's simple A->B->C. Let's not get all crazy and consider things like pool of available applicants, scheduling pressures or anything clearly tangential like that.

I've interviewed with a number of game companies large and small, and none of them used what you claim is the most common interview technique. Inlcuding suck-ass companies like 3DO.

[jpark]

Sometimes your career can flash before your eyes in an interview.

Would you invest in our company based on our current product positioning?

My answer:  No.  Listed why.  An answer to this kind of question has no middle ground.  The interviewer was impressed - but after many more meetings I did not get the position.

If you're going to fuck up, go big, and go with style:

After spending the day with a firm for interviewing, and departing to get my flight, I "accidently" took the limousine to the airport that the board of directors were waiting for who arrived only a few minutes after I departed with their ride.  This was quite a big company.  I got the job - but to this day - guys laugh at that story that is now 5 years ago.

Pealos I don't quite agree on the simplicity there are several key variables here:  company large or small?  Your position senior or not?
  These two variables alone have a lot of impact on the whole interview process.

[Paelos]

Pealos I don't quite agree on the simplicity there are several key variables here:  company large or small?  Your position senior or not?
  These two variables alone have a lot of impact on the whole interview process.

File that under: Do your research. If you know the elements of a company going in you'll have the leg up automatically.

[MahrinSkel]

My favorite job interviews are the ones where where it's a bunch of rookies that can talk a good game to investors, but are in way over their heads.  About halfway through, after I've gotten through nailing their "hard" questions, I start interviewing *them*, asking things like "So, what is our strategic planning for our market placement of this title?"  Generally, the marketing guy in the room will start riffing off demographics, I let him go on for a bit, then throw in: So, what's our primary gameplay targets to reach this market?  Here, the producer or lead designer who's supposed to be my new boss starts mumbling some things.  After he's dug humself a deep enough hole, I close it with: "So, what are our fallback positions if we run into implementation barriers or bottlenecks?"

"Like what?"  So I name off the top five that have entered my head in the course of the conversation.  Responses usually alternates between dismissive, they think they already have that handled and it can't possibly cause a setback, and stunned, they never imagined that could be a problem.

Sometime about there, the brighter guys in the room realize that I should be interviewing to be their boss, and not their flunky.  Usually this is when they wrap things up and get me off the phone or out of the room, then go have scrreaming fights for the next day or so.  Maybe I never hear back from them, maybe a PA calls me in a few days and says "Ummm, we don't think you'd be a good fit."  If the PA was nice to me, I give him the Cassandra act: Tell him exactly how the whole thing is going to fly into pieces, and how to plan his exit strategy. I understand that typically sets off more fights.

If I was the proper kind of weasel, I could soft-pedal the interviews, get inside, and tear the joint up.  Unfortunately, I have certain ethcal standards that keep me from going that route, mostly not wanting to have to wake up in the morning and see a flaming douchebag in the mirror.  I really don't like the person I have to become to play that kind of politics, and I can never bring myself to be ruthless enough.

--Dave