Of course not. Interview situations are very, very different than the others. Meetings and code reviews are with co-workers, whom you know and trust. Meetings with clients could be nerve-wracking for other reasons, but they're unlikely to challenge your depth of coding knowledge.

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.

I don't work that way. I sit with my editor in one screen and a browser window in the other, and I piece together the layout as I go along. I assure you, it works just fine. But the interview situation was so far divorced from any every-day working situation that it felt very unnatural.

I opted out of returning for the second round of interviews. 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.

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.

Different people differ in how strong this effect is for them in an interview. I'm unusual - I actually relax. Whereas the author of this article tenses up. And, of course, once you're tense and you notice that you just flubbed something obvious, then you tense up even more. Leading negative reinforcing cycle. And if you experience this in one interview, you'll experience it in the next.

It does not matter how reasonable your questions are. If this is what someone faces, you do not get an accurate picture of how good anyone with interview anxiety is. And a lot of people suffer from this. The author of this article to an extreme degree.

Stressful situations happen a lot more than never in the real world (and sometimes they even involve talking to people, like customers) -- I don't want to have coworkers who can't handle that.

Stress in a job situation is like building a fortress over many months and getting invaded. You know the layout of the terrain like the back of your hand and you can focus on the problem.

Stress in an interview is like being air dropped into an enemy fortress. It is hard to know where to turn and you spend as much energy trying to suss out the layout of your new environment as you do reacting to your adversary.

This completely contradicts the argument that a candidate who has difficulty handling interview stress will not have the ability to handle any stress. I can't speak for everyone who gets nervous during interviews, but in my case it's due to the combination of the uncomfortable environment, lack of access to tools I've grown to rely on, and an awareness of how fickle people's opinions are.

Then you are doing it wrong. There are different types of stress. Holding up well under "stress" is a misnomer, as someone can hold up well under one type of stress, and completely fall apart in another situation entirely.

What you are testing for is the ability to handle the stress of interviewing. If anything, you are hiring for people who can more easily leave.

While it's appropriate to test for situations where stress is a factor, it's equally important to realize that talking to a customer and doing pre-sales and an interview are about as far apart as possible on the stress meter. One hardly equates with the other.

And that's coming from someone who enjoys interviews, because I'm almost always smarter than the other guy (and it's usually a guy) interviewing me. Every job interview I've had has resulted in an offer.[1]

But their unique and outlandish nature sets them so far out of anything experienced in a job situation, except possibly for sales. Trying to give them the meaning you're going for is rather pitiful given you're so earnest!

[1] For similar reasons, I generally decline to interview prospects, because I'm afraid I judge too narrowly.

No.

If you're only willing to consider people who can somewhat function under artificial pressure, then you're passing up a lot of top-notch candidates for very bad reason.

Freezing up in interviews would probably be a red flag for a job where you're doing cold calls or something like that. I wouldn't accept that kind of job, let alone interview.

Then you're like the guy who punishes interviewees because they didn't estimate the number of sewer ducts in New York correctly. Interviews can cause anxiety and stress to an extent that a typical employee may never encounter in their work.

A client meeting, code review, or dispute with a manager can be stressful, but you can answer from a position of strength. You know your code, have reasons for your decisions, and have met some standard to get the job. Interviews may be less demanding, but for some people it's a huge problem that there's no solid place to stand.

And empirically, we endlessly observe very nervous people at interviews that do not exhibit nervousness in meetings (after getting the job).

We know that people behave differently in interviews; I suggest using that behavior to predict behavior in non-interview situations is noisy at best, and probably entirely random.

[>>>This is great when you've got to climb a tree to get away from a tiger. This is horrible if you are trying to demonstrate your ability to function mentally.

Climbing a tree won't get you away from a tiger; it's a cat.]

You fail the interview for not getting the a-ha question right.

For me the former situation leads to lots of bad feelings including irritation and incredible anxiety. I have often considered the latter type of situation fun times. For a lot of programmers difficult puzzle solving stress is good stress.

From what I have witnessed from current in-the-box hiring practices is a lot of extroverts get hired who are good at spin and presentation. Quite a few managers never detect that they are actually not great programmers because they are brilliant at sucking up and putting on a show. Those skills dont always hurt, but they shouldnt be considered a deal breaker for a programmer who actually gets good work done.

Best practice I have ever encountered is when interviewers give out interview questions in advance to allow to the interviewee a while to think about the problem in quiet.

I love the idea of short term contracts for both parties to suss each other out.

(I was in charge of running the system that produced the bills and I think the CTO might have reported to Vint at one point )

How a person does on a pressure interview certainly tells you something, but it would seem to put a high priority on a particular skill at the expense of others. It probably effectively screens out anxious types. I'm not sure you can generalize what you learn too broadly, though.

Describing a closure is actually a great example of something many great software developers WON'T know based upon their prior domain experience.

A strong Java or old school C/C++ programmer (yes I know C++11 has closures) may actually be an excellent candidate, but have no idea what a closure is.

I would expect that a front end JavaScript developer, RoR dev, or anyone else "experienced" in a language with some functional support (Scala, Haskell, F#, etc...) should be able to explain a closure.

Took me a little while reading to figure out what it is. Apparently it's just using vatiables in a lambda that are from a scope higher than it. I do that all the time, I just didn't know it had a special name. To be fair, I didn't know JS could do lambdas. I've only used them in C# and possibly Python.

Well, I guess it's like a closure when you use functions as methods in objects in JS, since they can be defined with this.MyMethod = function(){...} which can then access the object's stuff.

Javascript people use closure to mean lambdas, closures and sometimes anonymous functions.

Ask two programmers the difference between lambdas, closures and anonymous functions and be prepared for a different and probably wrong explanation from most of them.

Including me.

And that's the only reason you don't know what a closure is, if you hung out around javascript programmers a bit more in RL or online you'd have heard it constantly.

If it was described to you, you'd know what it is.

Also, the language may, if it provides some sugar to allow the anonymous function to appear to return to the caller, e.g. through async/yield/co-routine type semantics, also transparently copy back the variables to the callers' locations.

As per another commentator, 'lambdas', 'closures' and 'anonymous functions' are used equivalently by different people and/or fields.

As a C programmer primarily, I was long confused why higher-level programmers went on about "closures". They're nothing special, we do this kind of stuff in C all the time. We have to do it by hand ourselves, the language doesn't give us shortcuts. It's not really mysterious and we don't have fancy names for it. Sometimes I wonder if the reason some higher-level programmers treat these things so reverentially is, perhaps, because there is an element of mysticism to it, borne of lack of understanding of what is happening "under the hood"?

Also, I think most would agree that if the "higher scope" is the global scope, then it isn't actually a closure. For example, C functions can access globals, but C has no closures (barring various extensions).

1: http://javascriptweblog.wordpress.com/2010/10/25/understandi...

Thank you for the clarification that all JavaScript functions are closures though.

No, the examples you listed are very different settings. An interview is far from a casual conversation, no matter the tone of your voice. An outsider is trying to prove themself to the group, they are under direct scrutiny at all times. One mistake can widely swing the interviewer's impression and cost them the job. No matter how many times you tell them to relax, certain people get into a feedback loop and it freezes them into inaction. Once part of the team being criticized for their code from other developers or clients is much less stressful, it's something they're ready to deal with. They are held with a certain level of respect for even being part of the group at all, and much less likely to lose the job/get fired in such a setting so the stakes are nowhere near as high.

By having an efficient technical interview process, yes, you let good candidates go. Just as you do by only having certain target universities or requiring certain experience. But they don't give a fuck. They get 1000 applications a day. Hundreds of internal referrals. If they were to reject the ~100 candidates/week that get hired based off doing well in their technical interview and take the next 100, Google Engineering would be just as well off. Maybe better. (Harvard says the same thing about its incoming classes).

No technical interview will ever be perfect. But if you have a holistic process that is 50% based on past experience, and 50% based on being a top 10% performer in well-designed technical interviews (among other factors), that's usually good enough to take a bet on the candidate.

Recruiter calls again a year or so after the fact. "You did well in your prior interview, but things didn't line up. Interested in coming back in?" Me - "The last impression left a pretty bad taste in my mouth. Not at this time."

Note - I was on internal referral as well as had apparently incredibly impressed the "phone screen" person (whatever that means). Of anywhere I have talked with, GOOG has been at the bottom of list in overall experience.

Also consider the fact that most companies are not google and don't have the same unlimited streams of top candidates coming in the door (is that even true for google any longer ?). A smaller operation (ie. the typical hn population) needs to work much harder to avoid false negatives. One way of doing that is to optimize the hiring process to allow a good candidate to shine vs the Google way of putting the candidate through endless abuse (I know what I speak of).

I doubt Google's false positives are better than anybody else's.

And if you are reliant on the false negatives coming back, and not being put off by the process, to keep your pipeline full of high-quality candidates, surely that has to be a risky approach longer-term. As Google loses its fast-growing-exciting-upstart reputation, and competition for engineers gets tougher, -- it's gradually going to get harder and harder to convince the best of the false negatives to come back into the process again.

There are plenty of students who are very bright, do outstanding jobs on their projects and homework, and otherwise get fantastic grades who then freeze up and get a C (or worse) on every test. Thankfully most real life situations don't mirror test taking, so often they're still high achievers.

Most job activity doesn't resemble a tech interview, so it's quite possible for this person to not freeze up ever after you hired him.

That said I'd still never hire this guy on the no false positives principle. I have neither the time nor inclination to contract with everyone who gets to that stage. But I rarely have projects for which a short term contractor could make much of a contribution. I suppose that's probably not the case for a lot of startups.

It's easy to look at all of the things taking a test and fixing code in an emergency have in common and make the rational assumption that someone who is bad in one situation would be bad in the other.

I am not a front-end web developer at all. I play with some front-end stuff occasionally. But if I had to work in that area I'm sure I could pick it up very quickly and become very effective. I think you need to differentiate between things people can read up on a day and catch up and things that are more fundamental to how they think and learn.

A lot of interview questions are also asked using synthetic examples that are not complete solutions. A good programmer will reach out and explore the full technical ramifications of the requirements instead of merely solving the problem. Knowing that complexity adds a whole new level of stress versus simply solving the easy problem the interviewer intended.

A lot of people have trouble sleeping the night before an interview. It's more stressful than anything they will likely encounter at your company because it determines a major, unpredictable branch point in their future. Unless informed their continued employment is at risk over the outcome of a meeting, client meetings will not have the same degree of stress.

I would never hire someone who bowed out of a tech interview. If you can't handle thinking through problems in a collaborative, relatively low-stress interview -- you're not the kind of person I want to work with, sorry.

Is there such thing? I doubt it, unless you're interviewed by someone you already know well.

Are you really saying that your developer meetings are as high-stakes as job interviews?

Most certainly aren't, but some are potentially higher stakes (especially with smaller companies), since you and coworkers losing jobs you have -- which can be the price of getting things wrong -- is a bigger stake than you not getting a job that you currently don't have.

Seriously though - if you're creating a high stress meeting like that in a company where people are at risk of getting fired then your culture is going to be terrible with people backstabbing each other so they look good at the next meeting. A company is a team - it's everyone's job to make sure the team is working by helping to fix any mistakes brought up in meetings, not firing people. You are not in competition with your employees. Your employees are not in competition with anyone either. Employees are hired by a company to work together to create things.

Wrong outcomes for meetings have business consequences, which can include people losing their jobs. That's not necessarily "people getting fired for getting things wrong in meetings" -- indeed it generally shouldn't be that except in rather extreme cases of "getting things wrong" -- but it still means that people's jobs are on the line in the meeting and that there is extreme pressure not to make mistakes. Not because your boss will fire you because they don't like your answer, but because the market will punish your company -- potentially cost you and your coworkers their jobs -- if the market doesn't like the outcome of the meeting.

So you're basically saying that a meeting could fail to create value because an employee made mistakes in the meeting as he could not handle the stress. The correct way to solve this for everyone involved is to reduce the amount of stress everyone is under in a meeting and to create an environment conducive to problem solving. This isn't really that hard, a well motivated employee whose rewards and goals align with the company will try his best to create value as it helps him the most as well. If an employee is very bad at meetings, he could also be asked to express his ideas beforehand to someone he feels comfortable with and then that person could help him express his idea in the meeting.

The solution of hiring only people who can shout the loudest and brute force their ideas through in combative meetings is not a solution that will create value over the long term. If someone is breaking down in your meeting the problem is the meeting, not the person. Fix the meeting. Even people capable of taking stress is meetings will still perform better if that stress is removed.

EDIT: You also shouldn't be making snap judgements in a meeting that will affect the future of the company in the market. If there is a lot of tension in the meeting and the outcome is unclear, postpone the issue a short while until people can work out the issues better. If someone notices that there was a mistake in a previous meeting, work through the mistake in the next meeting and change direction ASAP. And obviously, don't fire anyone for this...

Sure, you can mitigate this to some extent, but you can't reliably avoid having high-stakes situations which you need a meetings which are inevitably going to be high-stakes to address, or that senior developers won't be to a certain degree on the spot in those meetings.

> The solution of hiring only people who can shout the loudest and brute force their ideas through in combative meetings is not a solution that will create value over the long term.

I haven't been arguing anything like that; particularly, I'll note that there is a big excluded middle between people who tend to freeze up in high-stress situations and "people who can shout the loudest and brute force their ideas through in combative meetings".

> EDIT: You also shouldn't be making snap judgements in a meeting that will affect the future of the company in the market. If there is a lot of tension in the meeting and the outcome is unclear, postpone the issue a short while until people can work out the issues better.

Postponing action can be a decision that will affect the future of the company in the market. You don't always have the luxury of making decisions in the way you'd prefer without paying a cost.

Sure you can. You can send out the problem before the meeting so the developer can think through the issue and make notes before he is put on the spot. You can also help the developer during the meeting by simply making the meeting positive instead of negative.

"You don't always have the luxury of making decisions in the way you'd prefer without paying a cost."

Snap decisions are often bad decisions. If you need to make a very important decision in a hurry it means someone already made a mistake in not considering this issue earlier. That happens, but you need to realize that the resulting decision is highly unlikely to be a good decision, let alone optimal. A mark of a good team is being able to avoid these kind of situations through research and planning.

Again, I'll go back to the same point: if you have created an atmosphere in a meeting that is causing people to freeze up due to high stress, you need to fix your meetings. There is something very wrong.

I don't fault developers who come across as nervous when I interview them.

If a person is interviewing for an air traffic controller position or any position with continuous stress and confrontation, well yes.

But if the job isn't a constant stress, constant demand affair but rather an affair of creative, constructive activity, then no.

Now, I suspect one problem might be that more jobs are becoming constant, chaotic stress affairs. In a large sense, that seems like a problem society has but that's just me.

This problem doesn't happen to me when I'm delivering a product pitch, speaking at a conference, meeting with investors, or any other situation where I'm on equal footing with my audience. Frequently, though, I ask to get back to people later with answers to difficult questions. I also prepare fanatically for those situations, where it's very difficult to prepare for a random tech interview.

A huge part of this is simply finding ways to stack the deck in my favor. A great interviewer knows that it's THEIR job to figure out what I can do well. Most people are not great interviewers. This makes a technical interview a total crapshoot that has never worked out for me.

My post is definitely suggesting that companies should examine their process to see if they're filtering for the right things. More importantly, I'm explaining how I've solved this problem for myself. Will I miss opportunities with my approach? Absolutely. I just now believe that I find better ones with my new method.

One caveat... I mostly consider a question like, "Can you explain what a closure is?" to be conversational. Simple knowledge quizzes are great fodder for a phone screen just to find out if someone even belongs in the room and whether they match the needed skills in general way. Where I get into trouble is with with whiteboard coding, brainteasers, etc.

We could have a great chat about async front end dev and then I'd stare blankly at you when you asked about CSS specifics. That's productive and tells you about my experience, though not my aptitude.

I am wondering 2 things: 1. How do you phrase it to a potential employer that you would prefer a take home project? Do you say you do bad under pressure? Do you say you think your abilities would shine though on a larger thought through assignment instead? 2. Do people have other strategies for dealing with such issues? Perhaps using a head hunter who knows the hiring process of each company, and can pass you along to ones with a less rigerous tech interview component.

Maybe I should just find smaller companies that have not figured out their interview process yet and hope they wont drill me.

"Pay me to contract on probation," sounds as if it's low risk for everyone, but it has stalled the pipeline for new candidates. It's not a reasonable request. If it were, then it would be a "contract-to-hire" position, and advertised as such.

I've walked candidates out because they've refused to whiteboard code. I'm very "hey, let's work out this problem together, and don't worry, I'm not going to compile the whiteboard, ha ha," so most people don't get too stressed out. If they do, that's where I step in and help them along, which is my job once they come on board as well, so they can get a feel for my style. It also helps separate the people with 10+ years of c, java, c#, and syntactically similar languages who can't differentiate between parens and braces, understand pointers, etc. The interview is where you can say,"would you do that differently if..." and see if the person has just had an interview brain fart or if they really don't know what they're talking about.

I've had a few candidates over the past 15 years or so that would just refuse to write any code. Certainly, I made the mistake of asking if they wanted to do some problem solving at the whiteboard, but I was flummoxed when the first guy (back at Amazon when interviewing at Amazon was perceived to be like interviewing at Google today) just said,"No."

And kept insisting. I'm a big believer in not wasting people's time, so I walked him out before he talked to the more senior people on the team, who were all working 24/7 to bring out (I think) auctions at the time. Looking back, it may not have been that big a waste of time. :-)

I think you're going too far the other way. Your argument basically seems to be "if you can't pass an interview, there's something wrong with you". Which is probably true. On the other hand, there's dozens of personality quirks (some of which are worse than getting nervous in job interviews) which wouldn't show up in an interview.

I have heard of anonymous classes. I've never used one on the job. Maybe that's a function of me being more server side and I think anonymous classes are use more heavily in Swing. Ditto for reflection -- aware of it and when to use it, but just never had the need. For better or worse, the pieces of functionality I've had to build out over the years simply did not require me to use those pieces of Java. There are countless of pieces of Java that I simply do not use, even if I'm aware of them.

A Java developer (at least in my circles) rarely just codes in Java all day. Often, they're using a framework. It might be Spring. It might be Hibernate. Right there, you have two vertical streams of expertise they could pounce on. Now add SQL. Even if you're using Hibernate, you'll still need some fundamental knowledge of SQL. Likely, they'll hit you with HQL questions. Maybe some lazy loading. Maybe some optimistic locking.

Maybe add EJBs. Maybe add JPA. Throw in some jQuery/HTML/CSS (unless they live exclusively in the server tier). Inevitably, some may ask about stored procs/PL-SQL. Oh what the hell...let's add web services, SOAP, REST, Ajax, JMS, transaction isolation levels, clustering, SSL. And so on. Wait...add Linux admin.

The disconnect (anxiety?) comes from a developer having to use so many technologies, which is realistic, and the interviewer salivating at the opportunity to go deep in any one of those.

"Excuse me...you can't write a static nested inner class? And you call yourself a Java developer?"

I once had an interviewer disappointed in not being able to ask me PL/SQL questions, despite me not even having PL/SQL on my resume. He just wanted to go there.

The interviews are often based on a notion that a developer does nothing else but use the language to its fullest. All day. Every day. Reality suggests that a developer uses only as much of a language as needed to build out a piece of functionality for a given need. They don't use every data structure available, nor necessarily every major piece of the language.

There's seemingly no way around this conflict. The interview is focused on a language. The developer is often focused on putting together solutions. Depth vs. breadth.

For the record, I had an interview once for a Grails developer spot and was asked about UDP. Yes, seriously...UDP.

We're not God. We're just developers.

whoever breezes through such technical interview, has either just had 20 interviews with similar questions and it's fresh on their mind, or studied specifically to become good at technical interviewing.. The latter is what i figured out that i had to do to stop being rejected from jobs i was clearly qualified for, just because i couldn't articulate something i never really had to articulate in the past.

If you freeze up during interviews because it's "high stress" then maybe you need to practice going on more interviews until it doesn't bug you any more.

When you're a developer -- especially at a senior level -- you need to be able to work well under stress. Hell -- you need to be able to do that for nearly any job in the world.

This is like saying "all drivers need to be able to drive well under stress, so let's test them while blaring a foghorn in their ear". Context is important.

I don't want to hire someone who is good at interviewing, I want to hire someone who is good at what I need them to do. While it may behoove the individual to train themselves on being better at interviews, as an employer it is a negative to wash someone out simply because they don't interview well.

Personally I rock at interviews, I've done easily 100+ interviews in my life at this point and I actually relax when I get into the room. This doesn't make me a better coder and it doesn't make me more qualified than the next guy who comes in with sweaty palms, and an employer whose heuristic uses interview-skill as a proxy for engineering-skill would be very misguided.

The entire problem with tech recruiting comes down to stupid proxies. We went through a phase where the top tech companies replaced real questions with logic brain teasers, as if that was a suitable proxy for real engineering ability. Now some startups are doing stupid shit like requiring extensive side projects, as if that is a suitable proxy for real engineering ability.

I'm not sure how many more years it will take for tech as an industry to realize that the best way to know someone is good at X, is to get them to do X.

I hope I don't get yelled at, but damn that was funny. That stated it so perfectly.

The only "stress" in software development that I see on the job is trying to meet deadlines that either aren't realistic, or now moot due to (substantial) changes in requirements.

Bugs are normal. Prod issues are normal. Code that won't work as you envisioned or intended is normal. Problems that are hard to solve are normal. Any or all of the above sometimes require extra hours to resolve but that's not even in the same ballpark as "will I be homeless soon".

Phrased another way: being without money is not that stressful. Being without a way to make money is extremely stressful.

But wouldn't you say a driving test is to driving as a technical interview is to a development role?

- Please sketch out a diagram of a typical family sedan, be sure to mark and explain all major components.

- Do you drive stick? No? Well, please draw out the full mechanical diagram of a manual transmission.

- You are going down the street and an old lady steps suddenly off the sidewalk. Please sketch on this whiteboard what you would do.

- Please play 5 rounds of Need For Speed: Underground. You are required to come in 2nd or 1st in all rounds.

etc, etc. It definitely won't entail actual driving.

Best interview process ever, and that company had excellent programmers and the lowest employee turnover I've ever seen.

It's easier to understand if you think of it like a phobia - someone may be irrationally scared of spiders, but that doesn't mean that they are going to be scared of heights, clowns, dogs, and snakes too.

I didn't realize there was dissent on this topic. Care to elaborate? I initially picked this up from http://www.joelonsoftware.com/articles/fog0000000073.html ("An important thing to remember about interviewing is this: it is much better to reject a good candidate than to accept a bad candidate.")

Think of it like this - you have two candidates. The first is exam ready for data structures and algorithms. You want merge sort? He whips out mergesort. You want red-black trees? You got it.

A second candidate is clearly aware of what run time is, and what trade-offs happen in different sorting algorithms. He's clearly aware of what can happen when a binary tree gets out of balance, and is aware of the types of more balanced trees. However, his knowledge is not exam ready. He can clearly code, but he starts to fade on the edge cases and in the implementation details. He mentions the chapter in a well respected data structures and algorithms book he'd read should this issue come up.

My question is, do you really protect yourself against false negatives with a no-hire on candidate #2? Candidate #1 may simply be someone who has figured out how to hack the programming interview. He might not be an especially good developer, not especially good at working with clients, with teams, with pushing through and getting it done. Or he might be very good at this. I'm just saying that I doubt that being "exam ready" is much of an indicator beyond the obvious coding ability and awareness of candidate #2.

However, this process clearly creates a huge number of false negatives - by bouncing #2, there's an excellent chance that you're passing on a superb candidate, and for what? A reduction in false positives that may be close to zero?

One thing - I think part of the disagreement on this board may come from the different definition people have for intensely technical interviews. Some would consider #2 to have passed. My own experience is that interviewers often do expect an "exam ready" preparation on data structures and algorithms, in addition to a few other branches of computing, which is probably I take a more cynical view of these interviews.

Yeah, if you're really bad at interviewing, it's not going to give you good information. I'm not disputing that. Interviewing, as it's done where I work (and everywhere I've interviewed, which admittedly isn't very many places), has been very effective at reducing false positives.

> cost of time they're not producing but drawing a salary

How many false positives do you know of who didn't produce anything? What is the actual chance that someone is going to be a net drag if they don't work out? Of course it can happen, but I get the impression from the more paranoid that it is likely or expected. I don't see that.

> eating dev time for training, etc.

This, I feel, is highly dependent on company and codebase. At my previous employer, I worked on real-time radar signal processing code which was very complicated and math-heavy. Someone who did not know what they were doing in that code could have easily cratered the productivity of one or more software or systems engineers. Simpler codebases would not be as bad.

> + cost of firing

Depending on your local laws and corporate structure, I can understand this issue. It takes an act of Congress to get fired from a defense contractor, though they have enough small layoffs to prune the dead wood once in awhile without a full-blown firing. I would like to know what the issues are for a smaller company though, since I really don't know the process. I get mixed signals as well. It seems like the employers and managers here speak of the difficulty in actually getting rid of people, while most of the individual contributors I know are worried about losing their jobs at the drop of a hat.

> Maybe this is from the perspective of a company that has no shortage of applications, but rejecting an applicant that would've been good costs basically nothing (dev time + travel if they got through phone screens).

If your company is finding the people it needs more or less when it needs them, then I understand this view. However, if your company is also one of those that complains about how hard it is to find "qualified" people and how understaffed you are, then your false positives are costing your business far more than that, though the true cost is very difficult to quantify (as is the true cost of a false positive).

Well, none. We haven't had any false positives since I started (and this is my first full-time job).

Depending on how quickly you catch the mistake, I would stand by my statement or call it an exaggeration. If they're still in training when you catch it, they've probably produced nothing. If it takes longer than that, then they've probably produced something (although if they're contributing enough bugs, it is entirely possible for them to have negative net productivity). But even at best, they're producing less than their salary (why else are you firing them?), so you've lost something.

> This, I feel, is highly dependent on company and codebase.

No arguments here.

> I would like to know what the issues are for a smaller company

From a US perspective, most of the cost is lawyers. It is very easy to say something wrong and end up with a wrongful termination suit, so you end up being very careful, which is expensive in both money and time.

> It seems like the employers and managers here speak of the difficulty in actually getting rid of people, while most of the individual contributors I know are worried about losing their jobs at the drop of a hat.

My experience is that people are worried about being laid off, not fired. Maybe I'm out of the loop, in which case I don't really have an answer to this one.

> if your company is also one of those that complains about how hard it is to find "qualified" people

We're not. We're pretty happy with our current growth rate (recently it's a bit high, if anything).

Maybe this reverses if you're having trouble finding as many people as you want to hire. I would understand accepting more false positives if that's your situation.

To avoid false positives you should ask, "Have you hired people who did interview well and weren't great at the work?"

Add to that the fact that most tech interviews are held in non-real world situations and it's easy to see why some people have problems. Putting a person in a room with a piece of paper with a chunk of code that has a 'hidden' flaw with no access to any other resources isn't real-world.

All of us have access to books, manuals, the code, google, any number of places we can use to help.

And usually these interviews focus on nuances of a language or a programming trick that you only know if you've seen it before or encounter it regularly.

The codebase I'm working on now targets the iPad. If I were to interview with a company and the tech reviewer asked me about an IE specific hack chances are it would take me a while to come up with it. Assuming I've encountered it before.

Personally I have no issue with stress. It actually brings out the best in me. I do realize however this whole thing is a game. When I interview others I try to be aware of these factors and get at what I really need but I'm not 100% immune to being in a bad mood etc.

One day I should blog about how to interview. That's a fun subject to write about...

You can do those in a half hour initial phone screen. Getting an idea of the applicant's general and/or domain-specific technical competence before you fly them out absolutely makes sense. I think what the author is criticizing, or at least the part of the author's criticism that I agree with, is the typical on-site interview that spends 3+ hours testing one's algorithmic knowledge and whiteboard coding skills. I do think that approach is vastly superior to doing nothing at all, but my personal experience suggests that testing the applicant's skills in a real life situation, after having vetted their technical knowledge/competence over the phone, seems more likely to identify strong engineers.

Imagine you've been applying to jobs for over half a year (180ish days is the average time it takes for someone to find a job these days), maybe you've had a couple of interviews, maybe this one is your first. You have burned through your savings, maxed out your credit cards, and you are less than a month away from missing your rent payment. When you're in such a situation, every interview becomes the single most important event in your life. If you fuck it up, you might not be able to put enough gas into your car, which you very well may be living in, in order to get to the next one. Trust me, if you've ever been in this situation, it's pretty easy to get freaked out and sound like a fucking idiot in the middle of an interview. It doesn't say anything about a person's ability to communicate in a routine business scenario.

The primary filter for me these days is the pair programming interview. Can they make something? Do they think clearly about what they're making? Do they ask good questions? Can they explain why they did something, and what other options are?

If you truly have only a day or two to get somebody up to speed, then sure, you need somebody who is already intimately familiar with every technology that you use ... but if it's a gigantic project, you're probably going to have a bigger learning curve than a couple of days anyway.

However, if you're looking for the absolute best person you can get for a job, you shouldn't write them off because they haven't had experience with a specific technology. More important is that they have a solid understanding of algorithms, data structures, and various design architectures, have exposure to a number languages, and are capable of rapidly assimilating new concepts. I'll take the lightening fast learner over somebody who knows a few specific techs _really_ well any time, because the lightening fast learner will _also_ learn the specific quirks of my project quickly, whereas somebody who has a difficult time with new concepts but happens to know the right techs might struggle for a long time just to come up to speed on a large project that somebody else created.

Any part way competent interviewer knows the difference between a bad interview and nerves getting the better someone. When it's nerves we're not thinking "they're awful", we're thinking "i don't know how good they are".

At that point I'm generally too busy to try and come up with a bunch of other things myself on the off chance the person will respond better to a different situation BUT if the person were proactive and came back and said "I know I screwed that up, would it be possible to try X instead", I think I'd be open to that.

(That said obviously giving small paid projects work to all potential interviewees doesn't scale particularly well.)

The biggest problem with testing knowledge than checking their work is, you ultimately end up hiring a lots of people who know(or atleast act that way) everything but can do nothing.

No because the interview process is designed to uncover where you're weak. It's a systematic way to figure out what you DON'T know. Other situations are not (at least not overtly).

For someone with inferiority or self esteem issues, this can be a very threatening situation, and totally artificial and unlike a normal working relationship where your intellect and skills get the benefit of the doubt most of the time.

Interviews strip away that easement and raise even the slightest possibility that you might be full of shit. For most people that's easily managed by their ego but for others, not so much.

   The author says "Other times I just froze on topics that I
   know very well." Maybe somebody can explain this better to me

It's only when I see peoples flaws that I can operate around them. Only when I know they are not perfect. (By the way I realize this is illogical behavior, I really can't help it, I'm ascared T.T)

I don't think this is anything new, I'm timid around new people. That doesn't impair my productivity, it just impairs how attractive I look as a hire.

Developer meetings are about the issues at hand. Code reviews are about the code. Client meetings are about their problems and ways to solve them. Presentations are about the topic you're presenting. Selling your teammates on an idea is about the idea and its merits. Interviews are about you.

(Incidentally, getting a person to go out with you, as some other poster mentioned, is about you. It is also a well known source of major brain freeze.)

Confidence gives you the strength to get up and go to the interview. It tells you you're competent enough to get the job even if you freeze a couple of times.

Overconfidence tells you you can't make mistakes. It tells you you have "superior technical skills", and that freezing up is only something that happens to lesser mortals.

Freezing up is a problem, not the opposite of overconfidence, or just the lack of confidence. Some not so confident behaviors are irrelevant, that's why I'd like to know what you mean.

Are you in a hiring position?

Edit: If you are in a hiring position and manage a team I understand your point of view and that you want a team that works well together.

First, I'll ignore the fact that contributions can be made to any stack far sooner than "months". It's uncommon for companies to be so incredibly short-sighted. In tech, the hiring goal is for talented people who will contribute for a long time (1 year+).

The company he mentioned was able to get 10 hours worth of work info on him this way.

Personal anecdote/case study:

I interned on the frontend team at Mixpanel in 2011. I had written about 200 lines of Javascript prior to starting work, not a ton of HTML, and literally no CSS. I had however done quite a bit with Python/Django (which they used). My first month consisted of me "getting up to speed" where I was working at a lower rate than others on the team. By the end of summer, I was a fairly productive member of the (3 person) team, building products with tools I had previously had very little experience in.

Fast forward 2+ years:

I've now done 2 years of college. I spent one summer writing distributed machine learning tools for fraud detection, and another summer during deep learning research. The majority of my computer science classes are just theory (no programming), but I've done a bit of programming in C/Python/Rust (for a choose your own language thing) for school and also a bit of programming in Python on the side. Now I apply for your frontend job.

>I'm going to ask them to explain how a closure works

Closes over internal state, talk about read-only (Python)/ read/write (JS) closures and how read/write closures allow you to make basic objects out of functions.

>How they deal with AJAX

Use a callback? Not sure what this question is really asking. Potentially do some kind of client side queuing for some special cases. How to implement server-side push is more interesting.

> What they think about "!important".

Overrides all other CSS rules iirc. Not a best practice thing to use, but still a useful hack to keep in the toolbox.

> Things to be careful about with floats.

I don't remember specifics, but I remember floats can be a bitch. Just Google any problems I'm having. I believe the type of container that floats are in matters.

> How CSS precedence/specificity works.

Could probably work out an example. In general, element inherits all rules that apply to it, and more specific rules overwrite less specific rules. I don't remember the non-trivial ordering for more specific -> less specific (ie id is more specific than class), but would be very easy to look up.

> How to architect a webapp

Would be more comfortable talking about the server-side component, but could talk about client-side code design.

Summary: I'd probably do alright but not exceptionally on your interview. You might give someone else the job. They would probably be more productive on day 1, but I don't know about by the end of week 1.

The twist: If I was interviewing for a frontend job, I'd take a few days to study all of this stuff and significantly increase my interview performance. Would that make me any better at actually doing the job? Probably marginally.