Hacker News Reader

Comment by crazygringo | Hacker News Reader

Granted, there are a lot of bad tech interviews out there (asking about algorithms that nobody ever uses) ... but I do not understand this.

Imagine someone's being hired for a front-end position, and we don't have months to get them up to speed.

I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/specificity works. Give them an example webapp idea, and ask how they might architect it.

None of these are gotchas. All of them are directly applicable to the work they'll be doing. If you can't explain how closures work, then either you don't understand them (so you shouldn't be hired except for a very junior position), or you're bad at communicating/explaining (which, on teams, can be equally bad).

The author says "Other times I just froze on topics that I know very well." Maybe somebody can explain this better to me -- but if you freeze up in interviews, are you also going to freeze up in developer meetings? During code reviews? When you're in the room with clients?

If you freeze up in interviews, then it doesn't seem like the problem is with interviews -- the problem is with you freezing up, isn't it? I mean, if you can't answer basic questions about your knowledge in a one-on-one conversation, then that's a real problem, and not just in interviewing. (Obviously, some overly aggressive or unfriendly interviewers can be off-putting, but I'm just talking about "normal" friendly interviewers.)

View on HN

Maybe somebody can explain this better to me -- but if you freeze up in interviews, are you also going to freeze up in developer meetings? During code reviews? When you're in the room with clients?

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.

Can I offer you some advice? An interview is a negotiation. The rules aren't fixed. If you're asked to do something that won't give a reliable measurement of your ability, say so and offer the interviewer a better option. You'll probably get what you want.

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.

It may be a negotiation but it is a very asymmetrical one. That by itself might be the root cause of a lot of the anxiety.

True. But it's not nearly so asymmetrical as most people seem to believe. Most interviewers aren't great at interviewing and know it. They're usually open – surprisingly open – to changes that will help them conduct a more reliable interview.

Upvoted for this remark.

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!

So true! Employers are investing so much time in the preliminary recruiting, filtering, and scheduling- by the time a face-to-face interview comes around you can guarantee they are interested in you. Candidates can make their job much easier (and perhaps land the gig) simply by anticipating their questions and concerns. Come prepared, ready to prove your qualifications and all their questions just might go out the window anyway.

Also in most cases the person interviewing you wants to be able to say yes. They need someone for their team and probably have other things they'd rather be doing than recruitment.

It is asymmetrical in a way that disadvantages both parties. For every candidate thinking "I hope they give me a job" there as an interviewer thinking "I hope we can hire this guy." For every candidate hoping they don't have to dig too deep into why they left their last job, there's a company hoping nobody asks too many questions about why the last guy quit.

I get that interviewers often have anxiety about the process, but your statement isn't really true.

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.

> It may be a negotiation but it is a very asymmetrical one

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.

The view of (a)symmetry in an interview is very generational. Those who turned 20 in the 90s or earlier are more likely to feel the bottom side of asymmetry, while "Gen Y" or "Millennials" (for lack of better terms) are more likely to simultaneously be interviewing the company for fit with their ideals.

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.

And the field. My programming interviews felt surprisingly symmetrical. Every one of my friends who is in another field has far more asymmetry, just due to supply and demand.

I feel like focusing on the asymmetry of it is a large part of the problem. If you're not walking into the interview prepared to disqualify these people as potential employers, that is doing a disservice to yourself.

I wish I could agree with you.

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?

Companies are chock full of asymmetric negotiations. Aside from obvious things like discussions with your manager, companies have all sorts of structured and unstructured power asymmetries.

If employees are continuously forced to justify their employment through impractical challenges with failure resulting in summary dismissal, that would be a toxic work environment. The power dynamics are not the same, and it's disingenuous to equate them.

So getting to the first principles of your response, you believe that any interview where someone attempts to ascertain your technical abilities is a series of impractical challenges, regardless of the contents of that interview. That in itself seems a bit absurd, as it implies that a company looking to hire an engineer is being impractical if it any way attempts to learn the knowledge that engineer has by speaking to him or her.

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.

What s funnier is, senior people may exchange roles in interviews asymmetrically where sometime A interviews B and sometimes B, A.

I've tried that. The response is always, "This is how we do our interviews. If we changed it for you, it would be hard to compare you to our other applicants".

That's likely to be someone you do not want to work for...

2 months later: "Gary can do his mockups just fine in MS Paint. We're gonna have to deny that request for a Balsamiq license... mmmkay?"

"Then don't. Toss out this experience if I'm not clearly better."

it appears that the maxim is, Always Be Cocky

No, if you're going to fail at the stupid test some random person dug up, you have nothing to lose by renegotiating.

Yup.

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.

Surely you don't mean do all those steps? That's an incredibly long process that I definitely wouldn't put up with. If I want to check out 10 companies, I simply can't scale with this unless I'm unemployed.

Wow, it sounds like you're interviewing for a best friend there not a work colleague. I seriously doubt you've ever recruited more than a handful of people using this criteria.

That certainly begs the question about which aspects of the process are even quantifiable.

Things have been a little weird at work with how interviews are going so I haven't done this in the last few interviews, but usually I tell the interviewee that I am just trying to figure out their skills, that I want to hire somebody, and if you don't like a question, or have a different way to present your skills to me, please change the course of the interview. Unfortunately it is somewhat rare for people to do so - usually senior people are far more likely to turn it into a conversation and demonstration than a junior person.

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.

If an interview is a negotiation, then why interview somewhere that I'm going to have to start off at a weak negotiating standpoint?

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

If your desirability as an employee is roughly constant, then if you start at a weak negotiating standpoint it's usually because the company's desirability as an employer is high.

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

I recently went through that process.

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.

You're missing the point. Regardless of the circumstances in which an interview takes place, you can ask for changes. And usually get them. The only way to be guaranteed not to get the changes you want is not to ask.

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

Sure, but it's still an indicator. If I have to negotiate to get an interview on terms I think are acceptable, how much am I going to have to negotiate every day if I work there?

It's a weakly predictive indicator. Yes, it tells you something, but not much. Extrapolate at your peril.

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.

It would be another indicator for you to suggest change and them either accept it or deny it. You could see how they deal when a curve ball is thrown their way and it gives you some great insight into if you would like to work in the type of environment put forward.

Yes, it's still an indicator. But so is your performance in the interview, correct? But your argument is that your performance in that style of interview is a weak indicator of your actual performance. Then I think it's also fair to grant that a company starting out with the standard interview style is a weak indicator of what it's like to worth there.

>> Can I offer you some advice? An interview is a negotiation.

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.

This is what I do/have done and it has worked well for me. I always bring my laptop and if they ask me to write code (as they invariably do) I pull it out and use it.

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.

I've tried something similar once. I got asked about the binary search algorithm. After some high level discussion on the idea behind it, I told the interviewer I hope I won't have to implement it. The algorithm is known for being easy to get wrong [1].

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

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

Interview situations are very, very different than the others.

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.

Ha, that's definitely a unique situation. The joker inside me couldn't have resisted tossing the most obscure brain-teasers and .NET minutia at you for fun. Hopefully you wouldn't have hated me too much after that.

>Of course not. Interview situations are very, very different than the others.

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.

Nope! If we rank stress from 0 = sleeping to 10 = getting diagnosed with cancer, the amount of stress I feel in a meeting (including important ones I lead or that include bigwigs) is in the 1 to 3 range, with maybe the occasional 4.

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.

I think the real problem is in your head: your anxiety about job interviews is sabotaging something you're otherwise perfectly good at.

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.

Telling a person they need to just be different is easy; being different is hard, and maybe objectionable for other reasons.

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

Agreed. Thanks for defending civility.

I would never interview you this way. It's counter-productive. Besides, good people can be shy and talented intelligent people maybe anxious by nature. Hazing people might be good for "team dynamics," but there's other more fun ways that don't just brutalize people by not giving them a fair shot at performing.

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

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.

Funny you should ask. I was JUST interviewed by a client of a local consulting company I work for periodically, and he asked all kinds of technical domain questions. Different domain than JavaScript, so different questions. I'm not even sure what's meant by "!important", honestly, though I do know what a closure is.

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.

My GF had to go through a round of technical interviews with clients after opting to accept a job with a contracting firm. The firm fills the various contracts they receive with employees, but the clients want to greenlight the employee before they start work.

That might just be contracting with the government though.

Pre-sales support engineers.

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

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

I meant "sales" in the sense that "all jobs are sales jobs." Selling your team on a particular technical approach. Selling your boss on a raise. Heck, even selling a member of the appropriate gender on hooking up is "sales"; you're just the product you're selling in that case.

>"all jobs are sales jobs."

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.

>Quite often it makes sense to take a hit on social skills if it gets you someone who is better technically.

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.

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

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.

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.

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.

>Seems like a poor choice of filter

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.

Sure, it sucks for the company that talented people take a look at their process and fire them as employers, but how is that a bad filter for him?

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.

My favorite technical interview was when one of their engineers got me on Skype, and told me to explain (line by line) the code for one of my open-source projects (which he picked out).

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

> My favorite technical interview was when one of their engineers got me on Skype, and told me to explain (line by line) the code for one of my open-source projects (which he picked out).

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.

That's the issue, it's much less important to ask someone to produce the code then it is to ask them how would they produce it. Being a Sr. Developer is less about what you know and more about how you work and think.

> Interview situations are very, very different than the others.

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.

The primary way in which interviews are different from after-the-hire social interactions is that interviews are high-stakes events, and the candidates know it. For some people, that knowledge is enough to put them into a self-reinforcing mental death spiral. Their fight-or-flight response takes over and they literally stop thinking as their bodies switch into survival mode.

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.

I highly agree. In an interview, it's 3-4 times harder to focus. Stuff that takes 1 min long to get takes 5 mins long in an interview.

I'm embarrassed to admit that in one of my first interviews I was asked to code bubble sort and choked for the first 30 seconds (it felt like a lot longer) until I reminded myself "I can do this" and sort of got back into things. I'd be tempted to disagree that this is such a big factor but it happened to me on bubble sort.

Don't be embarrassed, it's more of the same point. Exactly zero percent of my 15 years of development experience include writing a bubble sort. Your post represents perfectly what the author is saying about the disconnected, displacing, time wasting effects caused by conventional wisdom about performing tech interviews. If the developer is not themselves you're not hiring who you think you're hiring. I know you don't choke when you're doing good work. There must be a better way.

Freezing up in a meeting can get you fired just like freezing up in an interview can get you turned down for the job.

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

Why would you get fired for freezing up in a meeting?

You wouldn't. Certainly not in any company or organisation that I'd work for.

I can't speak for the particular interviewer at hand, but when I was interviewing people with whiteboard questions, I was interested not in the result, but in the way they think and approach the solution. So, if I were you in that particular situation, I'd start with simply laying out how do I think CSS rules will work out for the problem at hand, maybe used a marker to draw a simple style inheritance diagram for the particular DOM tree, etc., and would just turn the whole thing into a conversation.

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.

Thisity this.

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

I guess it depends on the industry/clientèle, but meetings are fundamentally very similar. You are worried about what "they" will ask and if you will be able to answer the questions.

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.

My experience has been that with a client, the universe of potential questions is much smaller than the universe of potential questions in an interview. An interviewer can go almost anywhere. . .that's not usually the case with the client. As you said, the client is asking about the software you are developing, not - typically - details about how you would handle their business need in a different language or on a different platform. Or about textbook information you may have covered in a class a few years back and haven't used once since.

I've had the polar opposite experience. I guess we have very different clients. Clients generally ask questions that don't make a lot of sense or that show a fundamental misunderstanding of how the system works. They may introduce new constraints and requirements on the fly that you've never heard of before. It's generally a lot more difficult. The "universe of potential questions" is basically limitless.

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.

But with clients (at least the ones I've dealt with) it is part of your job to educate them.

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.

I completely agree. Ostensibly the client should know more because he's the one ordering the product, but the reality is you often need to educate them.

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

I admit I've never experienced what you describe with a client - at least not to that degree. On the other hand, as another poster stated, with a client you've already established some level of authority and can bring them back down to earth or tap a teammate for help/clarification (unless you are working solo) or give a general response and say you will need to get back to them with more specifics. (Of course, with a prospective client, you are, in fact, interviewing and may not want to do that.)

When I'm working, I'm looking stuff up all the time. And, everyone I've ever paired with has been looking stuff up on a constant basis.

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.

I never ever hold it against someone if they say they need to look something up. No one should nor can memorize all the things we developers need to remember.

“Never memorize something that you can look up.”

― Albert Einstein

Which, today, almost means never memorize anything.

It'd be interesting why Einstein said this. I'm guessing because it takes time and effort to memorize something, not because he thought the brain had finite memory capacity.

I guess it depends what you want to test. I've not once done the task untog described, but if you sat me in front of an Internet-connected PC with an editor and browser, I'm pretty sure I could do it in ~30 minutes or so. I sure as hell could not do it on a whiteboard.

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?

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

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.

I think the computer there would be so you could see your progress, not so you could look things up. Write the display rule, then sanity-check; fix the margins and remove the bullets, then make sure it's right; etc.

This is very true, and I think it's worth noting that there are few circumstances where you have less basis for confidence than an interview. You're inherently conforming to someone else's workflow and being asked to respond to significantly unexpected, low-context questions.

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

It's only different in that, unless you're contracting, they're fairly uncommon.

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.

The problem is that interviews are high stress affairs. Stress produces adrenaline. One of adrenaline's known effects is to prepare us for "fight or flight", meaning that higher order logic is shut off, digestion is shut off, our senses sharpen, reactions improve. 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.

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.

Sorry, but a negative reinforcement cycle of tensing up in a medium stress situation is exactly the kind of characteristic that I'm trying to screen out in an interview.

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.

But it is different stress.

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.

Right, you can't assume a friendly environment. You may be interviewed by a friend of another employee who the company is looking to replace, perhaps by you. It's a war zone out there sometimes.

I wish I could highlight your comment, and tell everyone in the thread to read it.

This is the fundamental point that gets made and debated, again and again. I just don't agree that the stress is the same. Speaking as a person who is very prone to interview nerves, nothing evokes quite the same reaction in me, so it's not a valid predictor. Despite my terrible nerves in interviews, I'm able to handle real-world stress just fine. In fact, the craziest example of this I have is live-coding demands from a client in response to a final deliverable. I had our codebase up in an editor on my laptop, and in response to client complaints, was making changes live and deploying to our UAT environment to prompt them to give the final sign-off. Literally, the difference between "ok, we will call this project complete and pay you for the last 6 months of your work" and "this is unacceptable, we aren't paying for this" was in my hands, over the span of an hour, with the client sitting right across from me.

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.

> Sorry, but a negative reinforcement cycle of tensing up in a medium stress situation is exactly the kind of characteristic that I'm trying to screen out in an interview.

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.

For me, the interview has always been way more stressful than anything I've had to do on the job. I think lots of people feel the same way (partially based on what I've seen performing interviews myself).

Same here. I'd rather do a full week of work at work than spend an hour in an interview.

I'm sorry to hear about how stressed you get during interviews, but unfortunately the stress you demonstrate during technical interviews is a useful heuristic when determining whether or not a candidate would be a good fit for a company. Is a good signal all of the time? No. Is it a good signal most of the time? Probably.

You're so wrong it's laughable.

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.

Sorry, you're so completely wrong it's painful, unless one of your company's core competencies needs to be semi-confrontational meetings - if you're a consultancy, for example, or you're a wildly dysfunctional company. Social anxiety correlates pretty well with being in a STEM profession.

Probably not a good signal because company interviews tend to slip naturally into the human tradition of group initiation rites, unconsciously testing things like social hierarchy, fitness, dominance, loyalty, in addition to the stuff that really matters like problem solving. Technical jobs today simply don't require the strong social interaction and group selection that hunting for food and fending off wild animals did.

I really can't imagine what would lead you or anyone else to think that's a good signal. I guess maybe it could possibly be good if you're hiring someone to do cold calls or something.

>Is it a good signal most of the time?

No.

Neither of us have statistics on that, so a yes/no battle here is pointless. I and many others find it to be a useful signal when someone demonstrates intense anxiety under pressure, you and many others do not. Agree to disagree.

If your programmers are having to work under pressure then you're doing it wrong. It is the job of the manager to create an environment where people are as effective as they can be, and creating artificial space for developers is part of that. (Read Peopleware for more on this.)

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.

I have trouble with interviews, but I've had a much easier time interacting with clients. With a client, I don't feel like I'm defending myself, I feel like I'm helping somebody solve a problem of mutual interest. It's a totally different mindset.

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.

Once I started thinking about interviews in terms of 1) do we want to work together (not do they want me to work for them) and 2) how can I help them solve a problem, I found they went a lot better. In my cover letters, I'll often even say, "I think I can help" rather than "I think I'd be a good fit for this position". It makes me feel better about it anyway :-)

>Sorry, but a negative reinforcement cycle of tensing up in a medium stress situation is exactly the kind of characteristic that I'm trying to screen out in an 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.

I think your estimate of interviews as a "medium stress situation" is somewhat simplified and personal. Interviews push you into completely unfamiliar territory, in which you're simultaneously trying to solve context-free problems, defend your answers, and gauge the personality and preferences of your interviewer (an answer that works for one won't always work for another).

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.

Interview skill really has nothing to do with job performance (and I'm pretty good at interviews). It's a lot like standardized testing: "this metric is completely irrelevant but at least it's testable!"

Do not ignore empirical evidence - reality will always crush theory (in the collequial sense).

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.

Frankly, talking to customers isn't nearly as stressful as interviews.

I think that there are other problems here though; if you are going to be a part of an environment where you may experience adrenaline surges, you need to work through them. Skipping that part of an interview means that you won't be able to evaluate that response. One solution may be to include a high-stress part of the interview, but to weight it in the overall evaluation appropriately.

[>>>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.]

Adult tigers rarely climb trees even when chasing prey and need a significant running start to do so at all. Though they are cats their mass is importantly very different than domestic cats.

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

Remember: the tiger doesn't need to climb a tree well. It only needs to be better at it than I am. I am confident that a hungry tiger in hot pursuit will be better at it than I am, no matter how terrified I am (which will be quite a lot). And no, we're not going to settle it by experiment.

Remember, you don't need to be better than it is. Just better than whatever other prey item it could be considering.

Does the adult tiger realize that sooner or later you have to come down, and rather than risking injury, can just wait for you to come down?

Even though a tiger may be biologically more suited than I to stand starvation, if I'm sure of certain death on the ground I'll take very long to come down. And, who knows, I might just find a few eggs.

Well, jobs are high stress affairs too. We often have to maintain production systems that fail in cryptic ways at the most inconvenient times. I postulate that such situations are more stressful than solving some binary search tree problem on a whiteboard.

Im no neuroscientist or psychologist, but the stress of being sized up by other monkeys based on superficial first impressions that you know you dont happen to be very good at making, is WAY different than the stress that gets produced when a "cryptic" system needs fixing.

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.

Most of my developer jobs haven't been particularly high stress. Perhaps there is some selection bias here in that if you rely on the usual high stress interview process for developers you increase the chance of working with people who create systems that regularly need hot patching in production. Sounds like a dreadful job to me, so I guess that if there is any truth to this speculation that I should be happy about the selection mechanism.

Not at all. If I fix a production issue it's fixed. Either it is or it isn't. In an interview, I'm trying to impress another human. Who knows if I do a good job at that. Computers and their problems are simple in comparison. Judging a humans reaction, A LOT of developers are seriously bad at that. I'm pretty good at it myself but I hate it. I've had very few interviews that I didn't receive offers from but even I dislike the human part of interviews.

Interviews are not the same as celebrating your first 5 million dollar month and your CTO nudging you and saying this had be right or we are both looking for a new month

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

I deal with that kind of anxiety feedback loop in interviews, especially when I feel like I have no other edge besides my interview performance and resume, i.e., no personal connection. At my current job, they gave me the questions on paper and left me alone to answer them. I did well with that. (I also had a personal connection.) Later, I did a phone interview with Google based on having come up on one of their LinkedIn scans, and it went terrible.

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.

I've been meaning to read this http://www.amazon.com/Choke-Secrets-Brain-Reveal-Getting/dp/... hopefully got get some insight into my own "freezing up"

It's not just a born talent thing. Practicing interviewing and solving problems on a board in front of someone can do a lot to help you get over that anxiety. Yet most people never bother to practice and then wonder why they are bad at it.

This is weird. I would definitely fail your interview. Yet, at the same time, I've shipped over a dozen products, dozens of releases, consistently, to hundreds of thousands (if not millions) of people. I have a solid track record of clean, bug-free, efficient code. In 14 years of development, I've never had a bad review, and I've consistently ranked on the 'A-track' at all companies that I have worked for. I have low ego, work well with others, am a great teacher. Yet, my top priority is the craftsmanship of software: understanding user requirements and shipping great products that meet those requirements. My priority isn't being able to describe the intricacies of closures.

You have to look at the candidate's overall performance in the interview; not the answer to a single question.

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.

I can get anything I need to done in JS and I have no idea what a closure is. I've even written an emulator in it.

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.

C# people tend to use lambda to mean lambdas, closures and sometimes anonymous functions.

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.

Yeah, it's language sugar to capture variables (including automatics) from an outer scope and make them available to an anonymous function. This may involve copying the variables to other storage (e.g. to heap) if the anonymous function will be run outside the context of its caller.

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

Which is why when I want to know that you actually understand something as basic as closures in Javascript, I don't ask for the definition. I ask you to demonstrate it.

But if you don't know what it's called, or what the term means, then you're not going to be able to do that either.

I don't think everyone agrees, but I think usually, a closure refers to the implementation of that concept, and not the concept itself. The implementation being a pair of the static code alongside the captured environment.

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

You've never passed a callback to a JS function?

That's an anonymous function not a closure. A closure references non-local environments and can "access those non-local variables even when invoked outside of its immediate lexical scope" as Wikipedia puts.

I don't understand your contradiction to the parent poster. All JavaScript functions are closures, including anonymous functions that don't reference any lexically-scoped variables, and even named functions at the top level, which close over the global environment[1]. Also, callback functions don't have to be anonymous functions, you can just as easily pass named functions.

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

I know that confusing anonymous functions with closures is a common misconception. I also know that callback functions don't need to be anonymous, but a lot of the times they are, at least in the JavaScript code that I've seen.

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

Funny thing: I would pass his interview, I know everything he asked and have opinions on everything he asked, but I am so terrible at javascript + html + css. I HATE doing that kinda work. Those three freaking languages man.

> if you freeze up in interviews, are you also going to freeze up in developer meetings?

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.

Not to mention getting a job or not getting a job has the potential to be life changing. There are very few developer meetings or code reviews that will have such a huge impact on one's quality of life.

I used to work at Google. I saw a lot of good candidates get rejected. I myself was rejected multiple times before I got an offer. I was talking to my manager who was on the Hiring Committee about this dilemma, and at the end of the day the fact is that good companies don't give a shit about their false negative rate - only their net positives.

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.

I interviewed w/ Google a couple of years back, didn't get hired. Interviewing is a two way street, and I won't BS if I don't know something. That said, had one interviewer who had 0 personality, 0 people skills, and didn't introduce himself. He asked one of the typical open ended questions, which was fine, we went through it a bit. At the end, he claimed there was actually a closed answer to the problem, wouldn't actual say what it was and just walked out. The two of the other few people I talked with were interesting and engaging. But it was seriously a mixed bag and didn't present a good face for Google.

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.

Given that google has recently publicly denounced their own hiring methodology (that they've been using for years), I wouldn't use them as a shining example.

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 think Google's hiring is less about finding a few good engineers and more about collecting impressive specimens of humanity for a dream team. They're playing a different game than most, and that's their prerogative.

In reality nobody gives a shit about the false negatives. If you want to make a statistical argument you have to base it on the false positives. It looks like there is no such thing as a "false positive" in Google. They've been hiring puzzle-solvers and phone-dictation-coders for 10 years, only to suddenly turn around and say "puzzles are not a good predictor for success, nevermind we used it for 10 years, still no false positives".

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

Good companies should care about their false negative rate, as if they're smart they will realise that unlike Harvard their pool of potential candidates does not completely refresh each year. As you yourself exemplify, Google are now seeing many candidates who have applied before. While there are more than enough fresh bright young people growing up each year to fill Harvard's interviewing pipeline with first-time-candidates, there clearly aren't enough new top-rate computer scientists (who are interested in working for Google) coming into the field each year to fill Google's interviewing pipeline with only first time applicants.

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.

They're not trying to find the best out of all possibles candidates, or the least likely to fail. They're selecting the candidate that it's easiest to make a decision on.

The freezing up is a factor of anxiety, and anxiety can have any combination of triggers. What usually happens in an instance like this (I'm assuming it's similar to test anxiety) is that somewhere along the way, they froze during an interview, and the memory of that compounded the problem for the next interview, and so on and so forth. So the anxiety could be tied solely to tech interviews.

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.

I also get very anxious during exams and always make silly mistakes. It saddens me to see some some interviewers on this thread that naively believe that the kind of stress a person feels during an exam (especially one where the tester is sitting in front of you and watching your every move) is the same kind of stress you might experience while trying to fix some problem in front of your computer.

Well, the thing about anxiety is that it's very irrational. Unless you've suffered from it or, like me, are very close to someone who does, it's very hard to understand. (I still have only a surface level understanding after a 10 year relationship with a sufferer.)

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'll try to turn the table on you. Pick some particular technology that you don't hold in your head. three.js, Angular, Bootstrap, canvas, WebRT - whatever. I'm sure among those we'll find some details you don't have in your head right now and you will look up some APIs/details. Now I'll structure my interview around those topics which I happen to hold in my head since we use them all the time.

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.

What you just described isn't a 'tech interview' though, it's a 'bad tech interview'.

I agree a few years ago I had to pick up Pl/1G to look after one of BT's Billing Systems took me all of a week.

Numerous people cannot remember the names of acquaintances they've lived and worked with for years. If you name a concept a programmer works with every day, it's entirely reasonable that that programmer does not remember the name because she knows the concept by its syntax, not its name.

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.

Exactly. I am a very vehement opponent of quizzy, obscure-knowledge or high-pressure tech interviews. That said, I think a good tech interview is irreplaceable. I like to work through a complex problem with the candidate, oftentimes I don't know the answer, nor do I expect them to be able to finish the problem (this is made very clear) -- I do expect them to sink their teeth in and think out loud with me.

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.

> relatively low-stress interview

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

Nearly all interviews with technical staff are low stress in my experience.

Well, your experience is different from that of a lot of other people.

if you freeze up in interviews, are you also going to freeze up in developer meetings?

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

I can see it now: second prize is a set of steak knives. Third prize is you’re fired.

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

Woah hold on - you're firing people for getting things wrong in meetings? Most people would be unemployed.

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.

> Woah hold on - you're firing people for getting things wrong in meetings?

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.

Ah okay, good, that's a more reasonable discussion then.

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

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

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.

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

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.

Possibly, a senior front-end developer shouldn't be exclusively responsible for those higher stakes meetings?

Are job interviews really that high-stakes? There are always more jobs for skilled tech people.

People have been told for their entire lives that job interviews are high-stakes situations. Even if it's a job-seeker's market, it's usually a stressful situation. You're in someone else's office, generally outnumbered, and most of the interactions are the kind that make introverts sweat.

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

There are always more jobs, but not always of equal desirability. Knowing that this company is the only one in the perfect location, on a project that fascinates you is about as high-stakes as it gets.

"More jobs" doesn't really matter if you really want to work at a specific place.

If you freeze up in interviews, then it doesn't seem like the problem is with interviews -- the problem is with you freezing up

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 is also an example of the "extraversion bias" in company culture. http://www.theguardian.com/technology/2012/apr/01/susan-cain...

For a well done interview, the problem is definitely mine. I wish I could reliably do the right thing and show a quality thought process as I iterate towards a good answer. However, I need to be away from the pressure to speak in order to solve problems. Sometimes this only takes a few minutes, but that silence in an interview ruins my composure.

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.

Thanks for this blog entry. I happen to be going through this problem right now. I'm a developer who just moved to SF. There are tons of jobs, but I freeze up during tech interviews. In the past I have landed jobs at small companies with a looser interview structure where I can basically distract them with interesting nerdy stuff so the time runs out before they can get to the programming questions.

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.

What many candidates don't realize is that the hiring manager has probably gone through 1,000 or more resumes from recruiters or retained search agencies, phone screened 20-50, and interviewed 5-10 to fill one position.

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

The article doesn't say "interviews don't work". It says "interviews don't work for me, so I get my foot in the door another way". He's not really arguing that they are a bad idea in general, but he simply suggests he'd do better with a test project.

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 think part of the problem is the breadth of material for which you can be questioned in. Since I live in the Java world, let me use that as an example.

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.

i've forgotten the most elementary stuff in interviews.. half the time if someone asks me what object oriented programming is, i can't remember basic tenets (encapsulation, polymorphism) yet i have no problem coding up a dependency graph pattern.

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.

Just replying to state my shock at how many people are defending poor interview performance.

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 seems false to me. Interview stress isn't deadline stress isn't code review stress.

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.

"so let's test them while blaring a foghorn in their ear"

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.

all drivers need to be able to drive well under stress

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

Absolutely. And if we conducted driving tests like we conduct technical interviews, it would be something like:

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

Since a driving test involves driving, and I've never once encountered a technical interview that involved any reasonable facsimile of an actual technical work environment... No, absolutely not.

My best technical interview was a take-home programming assignment. I could ask questions by email. After a week, I would present my work to the other programmers and they'd ask questions about why I did something a certain way.

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

Please name and shame!

In a driving test, you still get to actually drive. A driving theory exam is a better comparison.

Many people, me included, experience something called "interview anxiety". It is only ever present during interviews. It may not be rational, but it's how our minds work.

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.

Why? Interviews are an unnatural situation. I have hired people who did not interview well but were great at the work.

But have you also hired people who did not interview well and weren't great at the work? The goal of interviewing is to avoid false positives, not to avoid false negatives.

"The goal of interviewing is to avoid false positives, not to avoid false negatives" - why is it? I can rectify a false positive, but if I miss greatness I might fail. If you hire people that others do not look at you can get people who are very loyal too.

Rectifying a false positive is very expensive (cost of time they're not producing but drawing a salary, eating dev time for training, etc. + cost of firing), and firing people is a morale issue as well. 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).

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

I think part of the problem is that the technical grilling isn't necessarily reducing false positives after a certain point. You may simply be selecting people who have front-loaded data structures in an "exam ready" way and rejecting candidates who have a fine background in this area but aren't exam ready. Do you really reduce false negatives by doing this? I almost have to wonder if you increase them, since you may simply be selecting for people who know how to prepare for an interview (and who aren't so busy with important work that they can afford to drop everything to front load the information).

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.

I don't see the relevance. The fact that you're asking someone to code a mergesort or a red-black tree tells me that you don't know how to interview, not that interviewing doesn't give you useful information. Candidate #2 sounds like they passed the interview - what did I say that made you think I'd reject them?

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.

I really want to address this in more detail than I have time at the moment to do so. I am a dissenter on this topic, though, so I would like to ask you to elaborate on your view of the trade-offs.

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

> How many false positives do you know of who didn't produce anything?

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.

Then you're asking the wrong question. If you want to test a theory, you try to disprove it, not look for evidence to support it.

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

True. Sr developers need to be able to handle stress. However, I don't think an interview accurately measures a person's ability to handle under stress.

I'm shocked that you're shocked. An interview is a contrived situation whose social stressors do not at all match those of programming a computer.

You aren't looking at the entire picture. Some have trouble in interviews because of learning disabilities and social anxiety but do well in the workplace once they are comfortable with the people.

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.

The main issue is that a lot of those interviews are poorly correlated with actual job performance. (People should familiarize themselves with Daniel Kahneman's related work there). Even the outcome of the interview may have more to do with the mood the interviewers are in and various social factors and signals then some objective measures. Most of my experience is interviewing others but it is certainly a reality check, which everyone should go through occasionally, to go interview somewhere else.

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

> I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/specificity works. Give them an example webapp idea, and ask how they might architect it. ... None of these are gotchas.

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.

Freezing up in an interview doesn't necessarily indicate that the person won't be able to communicate in a normal business setting.

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 level of position being interviewed for matters a lot, too. When I hire a "senior developer", part of what I'm hiring is someone with the experience and ability to teach junior developers. Someone who is unable to articulate basic concepts in a conversational context is not that developer.

I'm not sure you and OP are talking about the same thing. What you're describing as a a tech interview (as I understand at least) sounds like a delight to me. I enjoy talking tech and am happy to wax poetic on any of those topics. But the tech interviews I've recently done (for web developer positions) have been more focused on com-sci concepts and whiteboarding exercises (sometimes in front of 3-4 people on a video line) on arbitrary things like solving mazes according to special rules or building a donkey kong clone in javascript. Generally nothing that you would do as a web developer. I'm a fairly accomplished developer, but it's easy for me to look stupid in front of even a junior developer when I'm writing code on a whiteboard. I use google a lot while I work (without shame... until I'm at a whiteboard) and I reference other parts of the codebase for context. The best offer I got was from a company that did exactly as OP suggested... gave me a short contract job and evaluated on the code and my interactions during the job. That's also how I've hired developers for my own startups, and the results were excellent... they've all gone on to top-tier companies.

Generally, I'm not hiring people to explain things out of the blue to people who already know the answers. I'm hiring them to build things. So I don't like to spend a lot of interview time on pure quizzing.

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?

I think it's important not to get _too_ caught up on terminology, though. Someone who is already familiar with say C, C++, Java, and Perl, HTML, and CSS, but has only done some basic javascript (just to choose a random grab-bag) might look at you with a blank stare if you ask them about a closure. However, they may well be familiar with the concept, as in Java an anonymous class has many of the same properties. And I would argue that such a person would probably be able to pick up javascript and become effective in it in a matter of days, provided that they already have an extensive development background in other languages.

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.

As someone who recruits I'd say that I don't think the point is that there are parallels between interviews and other situations and the candidate is being rejected because of that, it's that I just didn't get enough information to make a decision.

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

'Do x in y seconds or you die', is totally different than 'Do x and we shall review it later' by your friends.

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.

"Maybe somebody can explain this better to me -- but if you freeze up in interviews, are you also going to freeze up in developer meetings? During code reviews? When you're in the room with clients?"

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.

If you're looking for something very specific and the hiring is such that there's no time for a hire to get up to speed, vetting candidates to make sure they already have exactly the knowledge you need makes sense. But a lot of technical interviews are not really doing that. Google does not care about the specific knowledge they ask you about at interviews for the most part; they have so many Google-specific internal systems and processes you couldn't possibly have any experience with, that there is going to be some getting up to speed anyway. Instead, they're using the interview gauntlet as a proxy for something they're actually interested in, something vaguely like "technical skill".

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

Personally I find that when I meet new people, I have an instinctual assumption that they are more knowledgeable and better than me in every measurable way, I am intimidated.

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.

Maybe somebody can explain this better to me -- but if you freeze up in interviews, are you also going to freeze up in developer meetings? During code reviews? When you're in the room with clients?

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

Truthfully, I'm not certain I'd trust someone who can go through an interview without freezing up or having any similar problems. Confidence is a valuable thing, but only in moderation.

I find it very bizarre that anybody would say something like this. Are you afraid of people who are more confident than you? Would that deter you even if they demonstrate superior technical skills?

I find it very bizarre that you don't see a need to keep out people who are overconfident. Are you afraid of people less confident than you? Would that deter you even if they demonstrate "superior technical skills" (whatever that means)?

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.

Oh well, if you think that everybody who doesn't freeze up in a job interview is automatically overconfident this discussion can't go anywhere.

It seems like you're focusing on the specifics of what I said without getting the general idea of what I said. The key phrase in my original comment was "or having similar problems". I'm not saying that you must freeze up to be hired by me. All I'm saying is that I consider it to be a good thing if a candidate shows some signs of inconfidence (one of which may be freezing up). That means they're taking the interview seriously and that they're not (too) cocky.

No, I don't focus on the freezing part, but you just confirmed it, you favor a lack of confidence. Out of curiosity, what do you consider similar to freezing up? A weak handshake? Avoiding eye contact?

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.

I take it you've never heard the word "overconfident"?

People who don't freeze in interviews are overconfident according to j_baker, I got that, I just don't understand how he came to that conclusion.

Ever heard of empathy?

FWIW, this is exactly how we recruit at my startup. In fact I was a little worried that it might be a turn off, so it's nice to hear that it's actually preferred (at least by some). Things we're looking for are the ability to get shit done and ship. We aren't looking for genius chess players, we're looking for curious problem solvers with a sense of responsibility and accountability.

Yes the problem is with freezing up. As a person with ADHD, high pressure situations will cause a lockup if my brain due to the inability to focus.

"Imagine someone's being hired for a front-end position, and we don't have months to get them up to speed."

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

Why do you need them to explain how a closure works when you could do something like the OP suggested and give them some work to do on their own time that allows them to show you how it works?

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

Unless you're literally looking for someone who can be productive within the first 2 or 3 days of hiring (which means your product/stack is fairly generic and you're hiring some specialist), I don't think this is a great kind of hiring methodology. I recognize you say "we don't have months to get them up to speed", but I think your whole post would be more true if you said "one month" or "2 weeks" rather than "months to get them up to speed".

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.

Well, for most positions I don't need somebody who can talk to clients comfortably and I don't care if they are shy or quiet in meetings.

Would you be kind enough to explain further why knowledge of closures is a priority...?

IMO, it's because they're abstract enough to be completely opaque to someone who doesn't understand the concept of them, but ridiculously simple once you do. Also, if you're doing a lot of front-end/javascript work you're bound to have run into them, even if you don't realize what they actually are at the time. For me it was just one of those "a-ha" moments where you realize there's an easier/better way to do something. And if the interviewee doesn't know about them before the interview, hopefully s/he has learned something from the interview (I learn a lot from interviews just from looking up all the stuff I didn't know).

Reply on news.ycombinator.com