In the scenario you described, I might try something like this: "I think I see what you're trying to measure by asking that question, but it assumes a working style that is foreign to me. So that you can get a better reading of what I can really do, would you mind if we used my laptop, with you looking over my shoulder, as I solved a problem of similar difficulty?"

An interview is a negotiation. If you want to change it, just ask. Most interviewers will be happy to agree to any changes that will help them get a better read on your true abilities.

If I'm interviewing you, it means that we already think you are worth talking to. I don't want to waste either my time or yours. If what I'm asking you to do makes you uncomfortable, TELL ME! I can think of the last two people I interviewed who gave me a series of immediate "I don't know..." answers to a bunch of questions. They're happily (I hope!) working here now because we changed the interviews to go down productive paths to find out what they do know instead of beating our heads against a wall!

In a given interview, sure, he's hoping that he can hire that person, but how many people get interviewed before the position is filled? I'm certain the average is much higher than one.

No matter how much anxiety he might have, he's doesn't have to worry about stuff like paying rent, keeping his car in working order, or feeding his family, because he already has a job.

Not really - some interviewers may not get that an interview goes both ways, but it really is very much symmetrical. For me at least an interview is the perfect chance to evaluate a company and until now I've declined about 3 job offers simply because I didn't like the conversations I've had with the people doing the interviewing.

New (inexperienced) hires are also more likely to feel the bottom side of asymmetry, which can counteract the effect for the youngest.

So yes it is, and no it isn't, depending on the candidate and on the company.

But the interview process is such a time suck (not to mention that you have to nick out on your regular job which you can only do so many times for a half a day before they get wise) that by the time you are walking into an office for an interview, you've already made a non-trivial commitment. You can only repeat it a handful of times (assuming you have another job or are otherwise professionally engaged) before it becomes a real burden.

Now, if you are unemployed and you have a substantial financial cushion or can pick up enough 'anytime/anyplace' freelance work, sure, interview with 5 companies a week, take your time and be picky. But how many job seekers are in such an ideal position?

You also believe that the power dynamics of an interview are different than the power dynamics of a company, as in an interview making a mistake can mean the difference between being hired and not. I don't disagree with you here, as ultimately making a mistake in an asymmetric negotiation at a company won't always get you fired. In this case, what I was providing a response to my parent comment, that if asymmetric negotiations are a problem for a person then a company will never work for them. These two things are not exactly the same, though I wouldn't fault someone for taking difficulty handling one to imply difficulty handling the other.

Business theater continues despite evidence it doesn't work. [1] Consider this a signal everything else is broken too. Notice their signals to show you are more than a technical automata to "fill a process void in the value chain".

The best interviews are as casual as possible, and not called interviews.

Good interview process looks like:

- 2 phone screens (recruiter||hr and then hiring manager && closest cowoker, if any)

- webcam screen

- a couple on-sites that may lead to:

- questions about what they've been working on, what's important to them, their career development goals and eventual desired package (that's basically it)

- take someone out to lunch

- play a sport with them [2]

- work on a current problem

- have an adventure

(very important for hiring manager and coworkers to have a say; placing staff under a manager is fail.)

Skip the:

- behavioral questions

Before hiring someone on a temporary project basis. Full time in a reasonable amount of time (average 6 months), or part time if that works better for them. This way, it's cool to feel each other out in the non-creepy professional way and there's no hurt feelings.

[1] http://www.techrepublic.com/blog/career/google-admits-bizarr...

[2] I hate all sports, except Scrumball and World Cup.

I also like the idea of asking the person to give a presentation. Give them an amount of time, to include questions, and they choose the topic. I don't think that works with everybody, so I'd never mandate it, but a lot of people really thrive in that situation. You get to talk about something you know, demonstrate your passion, and so on. The down side is that it can entail a big time commitment from the person.

Obviously this is predicated on the dev job market being as good as it is, but still. I can just go elsewhere.

Now, it could be that the employer is desirable because they provide a lot of perks that you don't really care about, in which case it's perfectly legit to eschew those perks and interview elsewhere. But oftentimes it's because they provide a bunch of tangible benefits that you do care about. Interesting work. Lots of money. Professional reputation that you can then use to increase your desirability to other employers.

It's usually a good career move to take a job at a place where you have a weak negotiating standpoint, work like hell to learn all the skills you can there, and then use professional reputation gained there to increase your negotiating position with other employers. That requires taking a "one-down" position sometimes and hoping that you get lucky and they like you.

Or, as some folks here are fond of saying, "If you're the smartest person in the room, it's time to find a new room."

Given two options, one out of my comfort zone and one in my comfort zone, I chose to be comfortable.

I realized that the value I add is not being able to complete tasks. The true value I add comes in looking beyond the task and figuring out how to address larger problems.

I've noticed in the past that when I continually don't know what I'm doing, I miss out on opportunities to really add value. While I'm able to figure stuff out and get the assigned task done, at best I come across as competent.

It was a great choice. There are still ample opportunities to learn. At the same time, I feel like I have time and mental capacity (freed up by not continually playing catch up with the team) to find and explore new ideas and improvement.

So when people say "Don't be the smartest person in the room" I would say it is also important to not put yourself in a situation you can barely handle. Having some breathing room will make you better at your job and make you far less stressed out.

So, if you ever find yourself in an interview about to go the wrong way, ask.

Look at it this way: Most of the people interviewing you are other programmers – the exact opposite of skilled interviewers. Predicting the day-to-day reality of working with them based on their default interviewing style is just as unreliable as them judging you based on your performance at solving silly brain teasers under stress.

Despite how screwed up this all is, most people are going to end up in many interviews throughout their lives, probably on both sides of the table. So it's best to realize up front that the situation is screwed up but changeable so that when you end up in an interview you'll know to ask for changes.

Probably good advice but most programmers I know including me are terrible negotiators which is why at least I work for the man instead of being a rich entrepreneur with that house at 3000 Ft overlooking the ocean with an unobstructed view.

That said, whiteboards are still usually better for conveying ideas. If you don't understand the problem you're trying to solve or the data structures you need, you might want to start on the board before sitting down to code.

Nevertheless the interviewer asked me to write it down on paper (using python). I've done so, but made a few mistakes. I still got the job offer, so the mistakes weren't a factor. I just wanted to point out that some interviewers are really set in their ways and don't change their minds.

[1] http://googleresearch.blogspot.com/2006/06/extra-extra-read-...

I think this is an important consideration. I do interviews quite often at my current company. And two steps of the interview process is a technical phone interview and a technical on-site interview.

I always ask coding questions, but before I start, I clearly tell the guys that they can use any language they want, and that I do not expect the program to "compile" or parse (in case of interpreted languages). What I always try to read is 1) that the person is not completely lost about programming, 2) What is his approach to solving the problem, and that he can explain it to me.

The problem I have with technical interviews (I also have always hated them when I've been in the interviewee sit), is when interviewers setup an "all or nothing" style. Usually it is because they were told to interview you, but they really don't know to do an interview, so they just read a bunch of problems to you and wait for you to solve them... without trying to read anything from the process.

Agreed. I once interviewed for a job within the company I already worked for (crazy bureaucratic process aside), and I was being interviewed by my existing boss, and a colleague that used to be on the same team as me.

I was asked a question about ASP.NET ViewState which I drew a complete blank on. I just couldn't wrap my ahead around the question because of nerves. It was only when my boss reminded me that this was something I had actually taught him and my colleague only 6 months ago that my nerves cleared, I relaxed, and then I could suddenly think clearly again.

The interview process creates a dynamic relationship between interviewer and interviewee that never exists between colleagues and bosses.

Really? I disagree. There even exist situations (in the case of some positions) where you will be talking to a client of the company you're working for, effectively interviewing with the client, representing the company. And interviewing is a subset of "sales", which is important for working on many teams -- including selling management on changes that would improve the user experience, for example.

>Meetings and code reviews are with co-workers, whom you know and trust.

Actually, when you first start out, you don't know them much more than you did when they were interviewing you. And honestly, I haven't always learned to trust my coworkers; or rather, some I've learned to not trust.

Regardless, this sounds like a psychological limitation on the side of the interviewee. Which is something you can work to improve.

Disclaimer: I've always been good at interviews. At least good enough that I have a more than 50% job offer rate for interviews I've gone to.

>For my own personal example, I once interviewed at a place where the interviewer wrote up some HTML on a whiteboard, and then asked me to write out the CSS next to it that would turn it into a horizontal drop down menu.

Not my domain, but yes, that sounds like a "parrot from memory something that you could copy-and-paste or build up trivially with a real coding environment," which I agree is not a great question, nor is it a good way to interview.

>I opted out of returning for the second round of interviews.

I think this is where you failed, though. If they asked you back, then even though you didn't feel good about the interview process, you must have passed. Their process is broken, so probably NO ONE was able to do everything perfectly.

>The next place I interviewed I sat down, in front of a computer, with the interviewer, and we talked through code as I wrote it. I took the job.

That's certainly a better interview process. But you do realize that you filtered out a company for having a less-than-optimal interview process? Seems like a poor choice of filter, in both directions.

My level of stress in a technical programming interview is usually in the 6 to 8 range. Even recently negotiating with my boss for a raise (which I know he was positively predisposed to because he is the one who brought it up) was a 5, which is significantly more than any regular meeting.

You need to be more zen about this. More laid back, relaxed, confident, or something like that.

You've probably been raised with the idea that job interviews are Very Important. Let go of that idea. It's just a chat with another programmer who's equally ill at ease with the situation. Imagine you're just having a coffee, or maybe discussing something at a seminar or something. He's not the boss; you're equals. When he asks the wrong question, let him know. Suggest changes. Discuss what YOU want to discuss instead of letting him dominate the conversation.

Of course it's still possible that he's inflexible about it. That tells you something about your prospective co-worker, and possibly the corporate culture.

For one, actually becoming more relaxed in confrontations is not something that has been achievable merely by asserting that I want to be -- instead, the only thing that seems to work is being in confrontations enough more often to reduce the stress level of such an environment. While this works to some degree, it raises the anxiety or stress level of the rest of my life, and is thus completely antithetical to most of the other things I do to make my life better. If I can instead just avoid situations which raise my stress level, and in which I would perform less well, that seems more conducive to overall happiness.

For another (and this was somewhat already implied), making changes to one's personality often has other effects on one which may be undesirable. Being more assertive might make it more likely that one bullies others (unintentionally). I've noticed this in myself as my assertiveness waxes and wanes: if I'm feeling especially confident, I'm more likely to say things without qualification, and say things that I would normally stop myself from saying. Later, I wonder if what I said came across as asinine, since that's how I would take such statements.

I sympathize quite a lot with the original poster, because while I'm a pretty good developer (at least, some others praise my skill highly), I'm really, really bad at interviewing, sales, talking to clients in a situation where I actually depend on their response, etc. (A previous commenter was quite right when he compared interviewing and sales -- they raise the same confrontational anxiety). When hired for a previous job, I was told months after the hiring that the interviewer was quite astonished that I'd turned out to be an intelligent and very capable developer, since I'd interviewed terribly, and the only reason he'd hired me at all was that he was having a fight with HR, and had announced that he would hire the next person he interviewed to show them how that worked out. That worked out poorly for his argument, but well for me and the team. :)

What positions would require you to prove the technical capability of your company at this level?

I've been working for a consultancy for a few years now. I can't recall a time when a client asked me to describe a closure or what I thought of !important. If I'm on a development team, the conversation with clients is generally about the time and effort required to implement something, or the options we have for delivering the functionality. If I'm pulled into a sales meeting, it's usually high-level architectural discussions.

I'm not an employee of the consulting company, but I COULD be if I asked, and in that case I would have been in that exact situation. I just prefer my contracting status; the upshot is that, not only did I do an interview like that, but I did it for free, on behalf of this company.

That might just be contracting with the government though.

If you are using the same interview process for technical folks and for sales folks, you are doing it wrong. (I mean, unless your technical folks are also sales folks, in which case, whoo boy. people who are good at both exist? but they are in high demand, and they are rare to begin with, so... good luck with that.)

some jobs... more than others. If an employer can find a programmer or sysadmin who can't get a job elsewhere because of poor sales skills, well, it sounds like they could either pay less or get someone with better technical skills than they could otherwise.

(That and my personal feeling? the guys who are 'always selling' are hard to deal with. I can handle maybe one day a week, if that, dealing with those folks.)

Seriously. Not everyone needs to be the team lead. The kid in the corner who is really good technically, who solves technical problems has a lot of value even if his or her social skills are poor.

I mean, sure, they'd be /more/ valuable with social skills, too... My whole point is that you can't get the perfect candidate. Quite often it makes sense to take a hit on social skills if it gets you someone who is better technically. (and sometimes the converse makes sense, too.)

I'm just saying, there is a place in the workplace for the introverts who don't interview or argue well. As an employer, if you only hire technical people who can get dates, well, you are limiting yourself.

Yes and no.

If it's just about being socially awkward, that's something that can be dealt with. But at the same time that socially awkward kid can potentially cause conflicts on the team.

But what I see far more often is someone who has poor communication skills. If I tell someone to do XYZ and they come back with XAB because they didn't quite understand and were too shy to ask for clarification, then I've just wasted time and money because they couldn't talk to me.

And I think it's very rare for someone with good communication skills to not have basic sales skills.

I guess I have yet to meet the perfect introvert with poor social skills who can understand everything that I ask him (or her) to do, who gets the work done quickly.

Honestly, I think that the myth of the really awesome social introvert/recluse is far more rare than it would otherwise appear. And that the costs of working with people like that may actually be higher than the benefits in a lot of cases. I say that as someone who previously was one of those social introverts, but who decided it was valuable to learn some social skills.

The moral of the story is that it's valuable to learn how to talk to people. And how to get dates.

Well, if you are looking for perfect anything, you are bound to find much disappointment.

I suggest that your inability to communicate with introverts has as much to do with your own communication style and abilities than with theirs.

Personally, I have the opposite problem. I can handle introverts; interacting with extroverts is where I screw it up, usually. I'm not terrible at it, by the standards of my people, but I'm not good at it. (I am terrible at it by the standards of a normal person.)

Obviously, the manager needs to be able to communicate with the programmers, so yeah, if you can't deal with introverts, you probably shouldn't be managing them. But recognize that you will be paying a lot more money, usually, for a lot less programming skill, if you go for a more extroverted and confident looking programmer.

>The moral of the story is that it's valuable to learn how to talk to people. And how to get dates.

Nobody is arguing with that. my social skills massively inflates my bill rate. Even very rough social skills and very rough confidence can dramatically increase your salary. If you can level up in that arena, it will benefit you greatly.

I'm just saying, on the manager side? with effort, you can get people who are dramatically better than me, technically speaking, for dramatically less than you'd pay for me, if you are willing to work around their communications and confidence issues. The pay and skill difference is sometimes quite dramatic, so just like most programmers can do well to learn how to deal with extroverts, most managers would do well to learn how to deal with introverts.

Sure. But do I want to work somewhere that has such a broken policy? Why haven't they fixed it? What other areas of the company have a similar lack of attention?

Interviews go both ways. The candidate and the company only get a small glimpse at each other and have to extrapolate from there. What I extrapolated was not positive.

I'm not convinced that this is true. Poor hiring doesn't mean that the company does other things wrong, but hiring determines what kind of people work at the company. Running into a hiring process that you believe won't select good coworkers can be a major problem.

The first impression the company gave him was "we have a bad process" for arguably one of the most important tasks they do - hiring. If they're broken about interviewing, why should he think that the people they do hire are going to be people he wants to work with? Or that any of their other processes are going to be less broken?

My current job (site reliability engineer) gave me a take home programming assignment, and one of the engineers did a code review face to face after I turned it in but before they gave me an offer. The quality of his review was a big factor in me taking the offer - I was impressed that they cared that much about code quality from a non software engineer.

I didn't prepare for this, but it allowed me to convey my engineering thought process and brag a little :) I really enjoyed it.

I've done a fair number of interviews, and this has been one of the best tools in my kit.

In fact, I will never do an interview without first doing research on the candidate. Having the candidate talk me through some of his projects and/or bits of (usually tricky) code segments has enormous benefits.

1: It allows the candidates to tell me what they really know, why they have chosen a given approach to a real problem, and sometimes even explain how they would reimplement the solution. (Or drop something altogether!)

2: It relieves stress. The candidates are suddenly on familiar ground. Instead of being grilled by the interviewer (me), they're suddenly explaining coding practices and their interests to a fellow hacker.

3: I, as an interviewer, learn more. I learn quite a bit of the candidate as a person, and on the very best occasions, I learn plenty of new things myself.

And there's nothing like those golden moments when the candidate forgets they are being interviewed. Their entire behaviour changes. Sometimes their manner of speech changes too. From those moments I can learn what truly makes the candidate tick.

For the record: I have never, ever based any decisions on my pre-interview research. That's just for my preparation. I'm supposed to do a hiring recommendation in mere hours - I want to spend that time as efficiently as possible.

How exactly? Freezing up in a meeting can get you fired just like freezing up in an interview can get you turned down for the job. Sure, you'll get comfortable with your coworkers, and they'll get more forgiving of temporarily lapses, but I think most interviewers (for non-terrible jobs especially) purposefully give some extra leeway to interviewees, since it's understandable for them to be a bit more nervous than a coworker would be.

That's why, when you're interviewing candidates, your first job is to get them to relax. Start out with small talk and softball questions until you sense them unwind. Then move slowly into the real questions.

When you get to the coding problems, again, start with dead-simple questions so that the candidates have the time to gain some confidence before the harder problems arrive.

The first programming problem I give – and this is after some small talk – is usually something like, "Print the odd integers between 1 and 100, in increasing order." This problem is so simple that it doesn't tell me anything about the candidate's ability, but that's okay. It helps to calm the candidates so that when I get to the problems I care about, I'll get better measurements.

That's the goal: To measure how the candidates actually perform, not to see whether they'll choke under interview stress.

Not really. A job interview is your one single chance to make a good enough impression to get the job. You could freeze up in a meeting and it would be fine, if the rest of your performance is on par.

One meeting in a job is a very tiny part of your overall employment. An interview is the one and only impression you get to make.

(For further reading, please consult the lyrics to Eminem's "Lose Yourself". Mom's spaghetti.)

If the interviewer would demand exact solution for the problem on the whiteboard, then probably it's time to part your ways and go to the interview with another company.

You're not going to find out in six hours if you're willing to marry someone, but you may find out that they leave their dirty underwear on the floor, never wash dishes, have sex with goats, and don't think fart jokes are funny.

When they're standing there apparently thinking, I want them talking.

"What's going on?"

"Well, I can't remember the exact method name for this..."

"Eh, make one up that sounds close enough."

Then, if we have time, we talk about implementing MagicBeanFactory#dwim, but that's usually after my anti-pep speech of,"These are the things that may or may not piss you off about working here..."

With a client, it's about the software you're developing, with a interviewer, it's about software architecture or coding principles.

In your example about HTML -> CSS I think you missed the point. It wasn't so much to check that you have something memorized, but to check your familiarity with the subject. Everyone sits with a browser while they code - I don't think that's a unique workflow. The thing is, if you've done this HTML -> CSS conversion a hundred times before, you wouldn't need to look it up. They're trying to gauge your experience level and if you've done this stuff hundreds of times before. I bet even a highschool student could find that with Google.

EDIT: I think a more relatable example would be if the interview gave you a simple geometrical problem and you were upset you can't look up the Pythagorean theorem. You're not being tested on your ability to memorize the Pythagorean theorem per se - it's just that everyone is expected to know the Pythagorean theorem b/c it's so fundamental to the sciences. Super simple problem with no google are testing if you have domain familiarity and experience and are a metric of whether you will hit the ground running or not. They're not gauging you problem solving ability, or your ability to memorize crap.

Interviewers aren't going to ask you nonsensical questions about the STL or to use algorithms in contexts that make no sense. The "universe of potential questions" is limited to the reasonable.

Question doesn't make sense? Let them know (gently, of course). Fundamental misunderstanding? Same thing. You are speaking from a position of authority.

I suppose you could try to take that posture in an interview but you are gambling on the interviewer being receptive to that approach.

But that just goes to show it's more stressful and difficult than an interview.

It's not that I'm crap, it's that the tools I'm using are always changing. HTML -> CSS? Sure, I won't look that up. CSS -> SASS? Sure, I probably won't look that up. Ask me to use LESS, I'll be on much looser footing. And, what's coming next? Do I have to have the new ES6 specifications memorized? I don't, though I've used those 100 times already, in the past weeks.

Hell, I still look up git commands.

― Albert Einstein

So. What kind of skills are you looking for? Someone who's memorized a limited set of knowledge and can slap it on a whiteboard on demand, or someone who can get shit done? Not that they're mutually exclusive or even uncorrelated, but why test for a poor proxy of what you want instead of exactly what you want?

That really doesn't make sense, though. They were gauging my experience level by forcing me into a development process I have never used before?

I don't think the best way to test if a person can do X is to take them far, far out of the environment in which they've always done X, and would be doing X if hired by you.

A code review or client meeting involves defending decisions that you or people working at your company have made, and explaining things for a code base you ought to have at least some familiarity with. That's a far different beast than being asked with no warning to come up with a way to complete someone else's task in a way that they consider "suitable".

Meetings and code reviews happen every day (or at least a few times a month), so you're well versed in their protocol.

Make yourself well versed in the protocol of interviews and they won't be any more stressful than any other type of meeting.

I find its helpful to think of people in a similar situation: door to door salesmen (possibly they're more disadvantaged, than you will be in an interview, I mean you know you've got the skill set or you wouldn't be there, they might get turned away just for being salesmen). Now a door to door salesman doesn't get terribly nervous selling something at the door of their house. Why? Well they do it hundreds of times a day, and before that the practice their marketing spiel, and techniques for getting the customer on side.

Practice questions, practice those body language techniques, practice telling jokes, and generally getting the interviewer to open up. When you do into do the real thing it won't be a big deal at all because you've practically done hundreds of them.