f13.net

Bleh. Just got back from one. I hate those damn things with a passion which is likely why I have never been hired for a job based upon a job interview.  God damned dog and pony show.

Fake it till you make it!*

(* works for things like kicking drinking and drug habits too.   :roll: )

I've found a few shots of expresso strait up gives me a nice temporary aura of peppiness that interviewers like.  Also: bribes are good.

I like interviews. I look like shit on paper.

/agree

I always felt that I could get any job I wanted if given a chance to interview.

I also agree, that a big shot of caffiene before hand is a good pick me up to seem more perky than our regular gamer selves.  However, beware when offered coffee.  Too much caffiene will make you jittery.

I won't say that I like them, because I'm a wreck in the time leading up to an interview.
But once I'm talking I do amazingly well and have managed to land jobs against really bad odds and tough competition. The problem is landing the damn interview. I make my living as a writer, but selling myself on one page id fucking hard.

/agree on the selling yourself on one page thing...

What really sucks is that to go longer, I need more experience and enough stuff to fill up a CV.  But I to work to get teh experience.  It's a damn vicious cycle I tells ya.

I'm exactly the opposite. Unreal resume, can't interview worth a damn because I think the questions are 99% stupid. I'm literally around 0 for 40 on getting jobs if an interview is involved.

I look decent on paper. Young and have a whole mess of experience and generally don't aim higher than I know I'm worth.

I KILL in interviews.

Isn't your best job to date interning for a game company?

The more people I interview, the less concerned I am about how I might come across in some future job interview from the other side, because I know I'll probably do better.   :wink:  For one thing, I don't blatantly lie on my resume.  That's the #1 thing that'll torpedo a candidate for me, and it seems like 90% of them do it, because once you start asking question about all their supposed qualifications, they fall apart and admit that they barely even know what that is.  It blows my mind.

To answer the question of your subject, yes, there is something worse than a job interview: a blind date.

voodoolily's advice (and remember, I've never not gotten a job I interviewed for):
No matter what people say, don't "be yourself" unless 'yourself' is very articulate, witty and well-dressed (oh, wait-that IS you, right?). Wear good shoes. Have a decent fucking haircut. Nothing sucks worse than to interview someone with no skills who thinks they're gonna get in because of their winning personality.

Remember, that in many fields it's not what you did but who you worked for/with. This is probably especially true for schmoozy fields like business. Make sure you haven't burned any bridges, then name-drop your little ass off. Make sure that the names you drop actually know who the fuck you are.

Send a (sincere and concise) thank-you note for the interview. A little ass-kissing never hurt anyone, as long as it makes you come off as well-bred and classy.

Dang, this is actually just damn good advice for life. You all should be like this all the time.

It really depends on the interviewer. Some people will look at qualifications and or be impressed with things like the school someone went to. I really don't give a damn what school people went to or what GPA they had, and I dig deep into whatever they said they did.

A lot of people will lie on their resumes, and a lot of people will intentionally mislead by saying they worked on an impressive sounding project when their part of it was mundane.

I would ask you look at it from the interviewers perspective. Interviewing people is tough as well. Especially if you've already seen a lot of people. Sometimes you get a resume at the very last minute, sometimes you don't feel like interviewing someone. Sometimes you just aren't good at interviewing and are asked to do it anyway.

I've interviewed a fair number of associate applicants and just try to have a normal conversation. Today was all sorts of "where you see yourself in 5 years" and "on a continuum from 1-10 on these traits, how would you rate yourself" mumbo jumbo.  The head of the office (this is a government offfice mind you) also made some weird biblical/BoM references during the interview.  Overall the experience sucked. The only reason I am even looking at this job is I am being crushed by health insurance costs in my new role as freelancer.

You know you can write off insurance costs if you're self-employed?  Doesn't help you now, but will definitely help on Apr 15 2006 :P

And I've had interviews like that one.  Remember, you're interviewing them, too.  Sounds to me like they failed.  Keep interviewing until you find a place you flow with - you'll be happier once you work there.

The write-off is nice (got 3 months of it for last year) but coming out of pocket $1,100 a month is still a pain in the ass.

There are many things worse than a job interview.  Here is one.
(http://www.lifted-lorax.com/images/036.jpg)

My god... it's so... so... beautiful!

Bah, regular interviews are a snap after you've been an actor for awhile...try all the same pressures of a regular interview...now compact it so that you have to make a good impression and convince whoever's doing the casting that you're right for the job in around two minutes...now THAT'S fucking scary...

The hair... the hair... all I see is hair...

In my experiences, this is key.  I try and ask questions whenever the opportunity arises.  It makes the atmosphere easier for them too because they don't have to just listen, but you are actively enganging in conversation (see voodoolilly re: blind dates).  Most business meetings (1on1)/job hiring can have the exact same methods applied to them that you would on a blind date.  What's funny is that on no less than 3 occasions, I've had interviews run way longer than expected (6 hours on Saturday was my record, boss called in his partner to come talk with me while he was at home).  This usually means that the place you are interviewing at isn't very structured and if need that sort of thing in your life (I do), then avoid it.

Of course, just because the interviewer is a dumbass doesn't mean everyone else is. There's plenty of people I'd not want to work under at my job, but the people I'd be working with (and do) are pretty cool. That said, the interviewer (normally) would be your boss, so if you don't mesh with him/her you'll hate going to work everyday. If you can, ask for an interview with the other people that would be on your team .. at least then you'd get a feel for morale and how well they got along with each other.

A 6 hour interview?

What.The.Fuck?

On a Saturday no less.  It just seemed to keep going, they were really nice people and I wanted to set a good impression, so I kept engaging them in conversation. 

Granted, I got home and had one of the longer drinking/swearing sessions of my illustrious drinking career.  Mainly because 1 month later they told me that the job no longer exists.

Seems I talked them out of the job being there in the first place.  Damn you middle-man sales!

It's not uncommon, at least in technical fields (where I am) to spend half a day or more interviewing for a position.  Of course, at this point it usually means the cannidate has passed a couple rounds of lesser interviews (usually phone).

I used to hate interviews.  I had/have a pretty good resume and never had trouble getting interviewed - my problem was the interview itself.  I'm a geek and hated playing the dog and pony game, as Ab put it.  I've changed my oppinion somewhat since I've had to give interviews, because I've come to learn what a huge asset the interview process is in picking out a good cannidate.  Primarilly, it helps the employer figure you out (hence not wanting to put much into the interview was giving really bad signals).  No employer is going to care so much whether you rate yourself a 6 or an 8, they just want to understand *why* you rate yourself that, and why it's important to you.

And yeah it is a show.   Keep in mind though, when you step up to an interview you're asking a company to give you a lot of its money that it could be spending on other things.  The burden is on you to demonstrate why you're worth however much per year.  Would you do any less if you were about to commit to spending thousands of dollars per year?

Interviews are rough. There is a lot at stake, so the pressure to do well can be self-defeating.

Some advice my dad gave me that has worked well:  always consider the mindset of the interviewer. You're there to sell what you can do for the company, not the other way around.

I do well in interviews, but I did have a couple disasters while going through the 3 interviews a week during on-campus b-school recruiting:

1. Investment Banking job:  Interviewer asks me how many hours of accounting I had taken. My answer was 6 hours (the minimum), but I spun that i had good practical knowledge. His next question was "What is the first line item in the Statement of Cash Flows?"  Uhhhh..Revenue?
"Thanks for your time. Good luck."

2. I botched the initial handshake with a petite interviewer. I was a little too enthusiastic, I guess, and I crushed her hand (the bones sort of ground together). There was no permanent damage, luckily.

Haha, the investment banking thing made me chuckle. The answer btw is Net Income.

Still, it's sort of pointless to ask that question seeing as no accountant actually creates these statements anymore. They are purely pulled together from accounting programs that automatically post all your entries. Oh and secondly, the statement of cash flows is probably the least important thing to an accountant, since you are basically backing out all the assets into pure liquid cash. Anybody can tell you that a pure evaluation of the cash flows doesn't give you a good picture of an investment oriented business. In fact, it'll look pretty awful.

I'm guessing the point of the question was to show an understanding of fundamentals, and (for extra credit) why it's not often used?  Sounds like it would be an excellent weed out question on that criteria alone, although maybe that's not what the interveiwer was thinking.  I can think of several examples like that in IT - knowledge that has very limited application, but it serves to basically help understand the underlying architecture.  Having that understanding normally makes for a much better cannidate.

Exactly what I was thinking. IF they don't know the basics, the rest of the app is probably bullshit.  Similarly it's customary to ask someone looking for a job in Architecture/ drafting who is fresh out of college but claims a lot of experience in the construction field what the size of a 2x4 is.  If they pass that, the next one is a 2x12.  It's amazing how many folks who claim to have worked in the field miss both and it's the simplest way of not wasting your time with the interviewee.

Rage of the Wookies??

Regarding asking obscure questions, I knew a video producer who liked to ask interviewees "what's the easiest way to have one object appear to transform into another object in video?"

Pretty much anyone with any practical experience gave the 'correct' answer (lock down your camera, shoot two separate objects and dissolve between them), while the answer he usually got from kids straight out of school involved expensive and/or complicated software and rendering.

Guh. Wednesday. I'm sorry, but it's already a moody day and I hafta be a bizatch.
It's candidate. It's primarily. It's opinion. You can't just add/subtract consonants on a whim.

Abogadro's number: you will be fine. I remembered a few things when I was driving home yesterday that I found helpful. First, don't put your GPA on your resume unless it's stellar. Most people honestly don't give a shit (I was apalled to find this out). Some of my superiors went to the same school as me and had the same profs, and were unimpressed to learn that I had done way better than them in the same classes. But DO include personality traits/life skills that make you a unique and valuable asset to a company. "Plays well with others" is an example that comes to mind. Buzzwords like "self-starter" and "attention to detail" sound like good but are actually bullshit, so if you can use different words to say the same thing you're golden.

Since I am lucky enough to spend time as the interviewer - here is all I want to know (even if I have to ask stupid questions because I want to treat every candidate equal)?


For me, it is all about finding out if the person I am interviewing will:

1  be at work when they are supposed to (always be to an interview early)
2  be trainable (always say something about catching on quickly because for most any job you are going to need to be trained at least some)
3  do what they are asked (always say you take direction well and if you don't - learn how - and after training are an independant   worker - no one wants workers we have to micromanage and hand hold).
4  work up to their abilities (bonus points for getting recognized for your work ethic elsewhere)
5  generally be able to get along with others (I don't really care if you are peppy, but I don't want to deal with everyone in the office not wanting to sit near you because you stink, you flirt, you yell..... just normal is fine)
6  act like you are interested and ask a few questions to show you are interest in working for me, my company, see it as an opportunity, and give me the reason you want the job when I ask you (even if health insurance is the main reason)
7  be respectful - a thank you when you leave and a thank you card after the interview helps


Things that turn me off from a candidate:

8  lying (forget it - I want someone that is honest)
9  seeing you be evasive (I don't have time to play mind games with staff or guess why you told me you really like something when it is obvious you don't)
10  unrealistic goals (pres of the company in 2 years if you are starting as mailclerk)
11  red flag if you slam your old supervisor or boss in the interview (explain both sides)
12  red flag if you had attendance issues at your previous jobs (I don't want to be your babysitter to make sure you are here when you are supposed to be)
13  knowing nothing about my company when we start the interview (spend at least a few minutes on the internet or asking people who do know before interviewing - again this is part of being interested in the company)
14  calling me every week after I interview you is NOT going to make me want to hire you - it is just going to piss me off


Remember, as much as you dislike interviewing, most often the person interviewing has a ton of work they are neglecting just to take the time out of their schedule to interview you, so be respectful of that person's time and thank them for giving you the opportunity.  Iit seems simple, but I can't tell you how many people don't.

OH, Ab..  As for those stupid 'formulaic' and cliche questions you see asked.  Most large companies, and particularly government agencies will protect themselves from being sued by a passed-over interviewee by having a rote list of questions to ask every cantidate.  It's somewhat easier to defend against a discrimination charge if you can provide a list of exactly what was asked to each and every cantidate who was interviewed. Along the same lines I've seen a lot of interviews where it's 2 people interviewing you. That way, if a suit is filed it's 2 vs 1 instead of a 1 vs 1 situation.

 It's best if you have a list specific to each job, but if you get large enough that becomes too big of an undertaking and you keep one list for the low-level jobs and then make the specific ones for upper management positions and folks who 'matter' more in the grand scheme of the corporate cogs. When you do this, the questions get ambiguous and, well, stupid.

I think the best way to think of an interview is (at least in the IT field) that you are interviewing the company, not the other way around.  What others have said in this thread is true, but is from the standpoint of the interviewer.  You are more valuable than you think you are, generally.  View an interview as you weeding out the bum companies to find the one you'll work for.  Do so in a kind, humble manner.  That's right, humble.  Don't think more of yourself than is necessary to think, but think more of yourself than the interviewer does.  Confidence without arrogance.

FWIW, when I go on interviews, I always wear a suit (even though on the job I'll wear a T-shirt and jeans a lot), am always early, and always come with a set of questions that I intend to ask.  Be politely aggressive with your questions.  Some telltales ....

(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).

(2) Ask why you are being hired.  Don't accept (again, politely) that they just need another warm body.  Are you replacing someone?  If so, why did that person leave?  If the interviewer is awkward about answering, move on.  It generally means there was a personal problem, and no one wants to get in the middle of that.  If the interviewer is honest about why the person left even if it was negative, put that job in the good pile.

Also, Am I being hired because the company growing?  Why?  How?  New product?  Expanding operations?  Even though I'm a contractor, I generally try to stay at one place for at least 1 year.  Knowing the recent history of a company is very important when figuring the likely length of your engagement.

(3) Take note of when the company wanted you to come in for an interview, and how flexible they were about the time.  When establishing the time for the interview, I almost always suggest a different time to see what the other person's reaction will be.  If there are other candidates and you have to come at a set time, great.  If there aren't other candidates and the interviewer insists on a specific time, that's a red flag.  It generally indicates totalitarian management, with a side order of dick-size competitions over things that don't matter (like the time of day that certain things happen).

Any company, for example, that suggests you come in on a Saturday for an interview is right out.  My job is not my life, thanks.  Remember, how the company treats you at this point is an indicator of how you'll be managed.

(4) Take note how many assinine questions you get asked.  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.  The world is overflowing with people who understand details but who produce absolute shit because they don't think beyond the details.  I bet lots of MMO developers who get hired at places like SOE aced all those stupid syntax questions, and yet their products generally suck.  If you value people who don't understand how to use Google (or the local library) to find the answers to questions, then you aren't a very good manager.  However, bonus points if the interviewer asks you abstract and theoretical questions to examine how you think.

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.

Another example:  "What are the issues around using cookies in a Web application?"  Bingo.  A much better way to get at what you want.  This is a much more open-ended question that forces you to discuss details to describe your point.  This question will almost certainly force the interviewee to answer the above question in a natural way, and in a way that lets the interviewer pay attention to how the candidate thinks.  How someone thinks is the single most important aspect to determining if a potential new hire is a good fit, and it is more important than head knowledge.  Companies that ask me this type of question in an interview definitely get a callback and my respect.

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.

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. 


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.


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?). 

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.


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.

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

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.


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.

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.

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.


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.

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.)

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.

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.

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.

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.

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.

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.

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.)

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?

Um, ok.



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

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?"


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.

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.

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

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.

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.

/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... :wink:)

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". 

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.

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?

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

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

Including a mastery of your domain, apparently.


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


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?

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


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.

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.

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.

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.

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

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

I love these threads.

Ditto on the confidence thing.  I have found that answering a question firmly and quickly (there's a fine line between quickly-smart and quickly-robot), you can generally fake your way into anything.  Just make sure that when you give the answer, you are already thinking of ways to support it.  Even if it's half assed.

Smile alot.  Make sure you ask them questions too.

I'm writing this down because I'm in the unique position that I'm moving to Balitmore and have waastaa at a few of the bigger engineering firms/contractors.  I'm going to play the whole "got out of EE, did sales, found it wasn't for me, want to get back into EE design" with certain parts being shifted for the jobs/companies.  Any specific advice for that?  I didn't get exceptionally good grades (2.8gpa) in college, and am not confident in my base knowledge of EE.  But I learn fast.  And I'm sexah in my pirate suit.

I suppose it depends a lot on the interview, but if you were interviewing for me this is exactly what *not* to do.

Usually when I give interviews one of the first things I say is that I don't expect someone to know everything, and if they are going to make a reasonable guess at something be *sure* to say so first. The last thing I want to see is a guy who is quick and confident with wrong answers, because it tells me he A) doesn't know what he's talking about and B) doesn't realize that. If a guy knows he doesn't know tha answer that's fine, but a guy who is quick with a bad answer is trouble. If I'm hiring I want someone who knows their shit cold, but barring that knows that they need to look it up or ask.


My advice in your specific situation is to be up front and say you need some memory refreshment but are a quick learner. And expect to be asked why you wanted to get into sales, then why you wanted to get back out. One of the things I'm wary of is hiring people who don't really want the job they are interviewing for. I hire engineers and it seems like everyone with more than 2 years of experience wants to be a team lead or project lead or techinical lead or architect or CTO or "get more involved in the customer facing side" or "more involved in the business aspect"- hey guys, no, not everyone can be the boss! I don't want 5 engineers who are all aiming to be the director of engineering in a couple of years. It means a couple years down the road people are going to be unhappy and either bail or start complaiing or lobbying for different positions or whatever.

Sure it's nice to have people who know their limits.

But a company heavy in drones is a disaster.  I have a hard time tolerating a team lead let alone a manager who doesn't grasp the people-side of management.  Mentorship is extremely important to me and it's usually with a bit of sadness I find someone who just wants to sit in one position for all of their career - rarely does that kind of personality perform well, just consistently mediocre, and even more rarely do they keep their skills current or keep me apprised of problems that need fixing.

But such folks are often very good at softserving management.  Huge negative...

Weasel your way in and then write a book about it. You can call all the douchebaggery 'research' then.

You should be. The young hip managerial suit deserves absolute devestation. Professional douchebags are the worst.