Hacker News new | comments | show | ask | jobs | submit login
I will not do a tech interview (medium.com)
1032 points by ikeellis 1038 days ago | past | web | 542 comments



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


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.


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.


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.


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.


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.


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


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


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?


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.


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.


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


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.


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


> I politely suggest that a short contract job might be the best option for a company to evaluate a senior developer

I like the twist of doing the contract off site on the developers own time.

Every time I see someone on hacker news saying, "we've solved the interview problem. We just require every new hire to give up their old job and contract with us for a week to see if they are a good fit", I often wonder about the quality of the people they hire as I have yet to run into a talented dev who would quit their current job to do this one week contract for hire option.

Doing contract work via take home seems like a nice balance here as even people with kids have 2-3 hours free after kids go to bed. Done over a few nights in a week makes much more sense.


It would also breach the work contract of many developers. Most work contracts tend to (1) prohibit you from taking on other paid work (2) claim copyright of the work you do while under employment (which is why the FSF & Apache foundation require employer waivers from contributors).


Do you have a source for this claim? None of my contracts in the US have ever had something like this. It's in fact illegal in most jurisdictions, including California.


>It's in fact illegal in most jurisdictions, including California.

IANAL, but AFAIK it's absolutely not illegal in California; what's illegal is preventing you from working for a competitor AFTER you quit.

I've never had a salary employment contract in California that DIDN'T say they owned everything I did in my off time, at least if I was working on something in a similar domain. The best contracts explicitly state that I can get an exemption, or that I can work on unrelated projects, but all have the clause.

If it's illegal, a lot of companies are breaking the law.


The interpretation is complicated, but its neither black or white. Also, its standard in asymmetric contracts (EULAs, employment, rentals) for the drafting side to completely overreach.

RTFM here:

http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&gr...


>.... except for those inventions that ... [r]elate at the time of conception or reduction to practice of the invention to the employer's business, or actual or demonstrably anticipated research or development of the employer

Seems pretty clear on the "similar business" front. IIRC that's been the wording in many if not most of the contracts I signed while I was still working as an employee in CA.

I've mostly worked in games, too, and so that pretty much meant "no game dev in my free time," period. A strong motivator to go indie/consulting.


That document actually says that YOU own everything you do outside of work, so long as it doesn't use company resources or is directly related to your work at company.


The document most certainly said that my employer owned everything that I did that was related to my employer's business. The thing about working on salary is that there's no punching in and out; just because I'm working at home doesn't mean I'm necessarily "outside of work" -- I worked at home doing paid work for over three years, in fact, seeing the inside of their office only 2-3 days a month.

I work in games. If I do something in my free time that's game-related, it's arguably related to the work my company does.

So I quit and started contracting. Now I own what I work on when I'm on my own time.


You want to check the small print of your contract but it depends on how related to you day job it is - the real point is could you afford to fight your employer.

And if you get caught using any of employers code like Sergey Aleynikov you are SOL


You're a fool if you'd sign away copyrights to all work you do outside of your place of employment. Actually, that shouldn't even be legal.


You could make it a short take-home assignment where the code doesn't get used by the interviewing company and the assignment is short enough that the interviewee doesn't feel like they need to get paid for it. It would basically be the same as doing it in-person but removes the added stress of the over-the-shoulder scrutiny, leading to a more realistic scenario where a developer has resources such as Google and Stack Overflow at their disposal.

In my engineering days, a company I interviewed for had me prototype some stuff in SolidWorks but gave me the courtesy of working alone. I just had to tell them when I was done. Even this was much more preferable to an in-person on-the-spot tech interview. I got an offer for that job, but if I had to perform the same task with someone watching, I don't think it would have gone as well.


This is the root of the problem with contract-as-interview, as far as I can tell. It wouldn't be completely unreasonable for someone to take a few days off from their job to interview (although I wouldn't do it). But both of the points you mention are standard for creatives, at least in the US, so I don't know how many people you'd legally be able to interview.


How would this be enforced?

I suppose it could end up being more of a problem for the hiring company after this practice became more widely known.


I've seen companies do a "challenge" style interview, where it's less of a contract and more of a "take this problem home, code something up to solve it, push to github and let us know when you're done". Then the interview portion is discussing the solution. It means you can calibrate across candidates better, but I think the advantage of an onsite contract job is the two-way feedback, especially in a smaller company.


This is the way the company I work for currently does it.

They provide the candidate with a piece of terrible code, ask for a code review of as many issues as the candidate can find, and also for a refactored copy of the code. Both of which are completed remotely on the dev's own time.

This is before even meeting the candidate in person. Once we meet in person for the first time, another terrible piece of code is provided -- in this case a basic data structure -- and another code review is requested. The candidate is given 15 minutes to complete it.

It's interesting what comes back. Some people comment only stylistic issues, others only logical or architectural issues. One person got up and left during their alone time.

Other than these, no coding is required.

So far, it's worked out pretty well. And when I was going through it, I enjoyed it.


I think that a lot of companies forget that they are also being interviewed during their interviews. Were I to interview at your company, I would think that your employees spend most of their time performing code review. I would probably walk out, too.


I can understand that take on it.

Our take is more that if you can recognize what is wrong with the code on multiple levels then you can most likely write good code.

This is easier to check on non-trivial code when done through a code review then by getting the interviewee to write the same kind of code that every other interview looks for. The submitted code sample does this as well.

I'd also want people on my team to be able to successfully refactor legacy code just by looking at it and being able to identify where things can be better cleaned up and tested.


I am completely behind code review and refactoring. I am our company's Chief Refactorer (a title I just made up, but it's accurate), and after instituting code review a few months ago, it has made our development process so much better. At this point, I hate merging in a feature that I've written without having someone else review it.

So that's not my issue. I was pointing out that your interview process seems to involve only code review, based on your comment above. Put yourself in an interviewer's shoes: in two different instances, you've been presented with bad code and asked to code review it. Personally, I would be concerned that (1) your company writes bad code, and (2) I'm going to be expected to spend all my time reviewing and fixing other people's bad code instead of writing code myself.

Now I doubt that's actually the reality of working at your company (at least I hope so!), but first impressions are very important, and that's what your interview process would tell me if I were interviewing there.


In my experience, these take home projects are woefully underspecified. Do they know this and expect me to email them with "good questions"? Or want me to not email them and "fill in the blanks" on my own? Do they want something that "just works"? Or something that is "reusable"? And so on. There's a reason we don't write production code by just throwing a document over the wall.


>>>>In my experience, these take home projects are woefully underspecified.

Completely agree.

I'm still not sure what these "challenges" even prove. If you're a developer, you should have reams of examples of code, a github account with work, and plenty of other avenues for people to check if you can do basic coding from scratch. Even a junior developer will/should have several examples of work they've done while in school.

I've been in a lot of "technical" interviews and once they start asking coding questions, I usually ask them if they've looked at my online portfolio, or the examples on my github account. 95% of the time, I'm able to pull an example which deals directly with that they're asking.

Doing this has two effects. One, it proves I can do what they're asking. And two, it puts the responsibility back on the interviewer. It's like asking, "Did you do your due diligence, or are you wasting my time asking me this question?"


We do this at my job. We try to come up with projects that are good fits for the candidate, usually a small version of a problem we've recently dealt with.

It's not a first line, though. We tend to start by actively recruiting/headhunting. We cherish recommendations from current or past employees, but we'll also open the position to all on the off chance we get a good application through traditional routes. HR only becomes involved with the process after an offer has been accepted or if the hiring manager has questions/concerns.

After an informal lunch with the hiring manager, you'll be invited to meet with some senior developers for about an hour. These meetings are mostly to figure out what the candidate thinks their strengths and weaknesses are and gives us a chance to talk about the stuff we plan to work on in the near and not-so-near future.

Once we have a fairly basic understanding of each other, we'll come up with a project. Think your strength is on the front end? Here's an API we wrote. Build a widget with the data. Think you're strongest at databases? Great, here's a database project.

We don't care if you have a lot of questions or if you fill in the blanks. We give as little direction as possible at first on purpose. Write it in whatever language you want to write it in. We want to see how the candidate works. If they ask questions, great. If they don't, great. Do they ship something?

We make sure to stress there's no wrong answers. At all. The projects are designed around your perceived strengths because we'll figure out your weaknesses and will compensate for those during the 90-day trial period all new hires have to go through anyway.

The point is to see something we can discuss in a later, final round. Even failure to complete is acceptable, so long as you can articulate why.

None of this is hard and fast. We have had candidates who, for whatever reason, can't or won't write code outside of their current position. We'll adjust. Our process isn't rigid at all. We try our best to take a holistic approach. It's only bit us in the ass twice, mostly due to culture issues because the hiring manager made his decisions unilaterally. Since then, all senior devs and a few others on the team meet all candidates before hire and can give management input.


My current company does this. It seems to work pretty well, but it has some of the same problems as other methods. In particular, the standards applied to the solution vary greatly from "Does it work and run at most 40x slower than expected?" to "It heap-allocates things that could be stack-allocated, so we should pass".


Hmm, how about applying the same standards to the solution as you would to internally-committed code (peer reviews, etc)?


Doing contract work via take home seems like a nice balance here as even people with kids have 2-3 hours free after kids go to bed. Done over a few nights in a week makes much more sense.

Initially, I was going to react negatively to this (as a father of two kids under the age of 11), but the more I think I about it, the more I like it. I assume that if I was scheduled for a technical interview, I'd likely spend at least 10 hours preparing for it (with perhaps only a bit of assurance that I had prepared properly). If I were given a ~10 hour contract project, I would know the problem up front, and be free to complete it without the stress of a whiteboard session.


For me this part about preparation is the hidden value of this approach. For most interviewees the interview isn't a 2 hour process, it's far more time spent in potentially-irrelevant preparation. It seems like companies might as well turn that time into a more direct skills evaluation.


And, if I'm reading you correctly, it may end up being a benefit to the interviewee, too. At the end of the process, whether I got the job or not, I have additional "implemented X in Y" experience.


I'm slightly embarrassed to say that didn't even occur to me, but yes. It makes the interview experience helpful for something other than more interviews.


"I often wonder about the quality of the people they hire as I have yet to run into a talented dev who would quit their current job to do this one week contract for hire option."

I wonder that, too. The very best people usually have a job that they like well enough, but might change jobs for a real offer.

"Quit your job and we will probably hire you" is not so attractive to experience people, who are usually no longer in their 20s. Even if a developer were inclined to give it a go on his or her vacation time, most employment contracts require notification for taking on additional employment -- it is rather awkward and annoying to the candidate to jump around these hoops.


I've always assumed those companies are weeding out older applicants. They are going after fresh graduates who are smart. That's all they want.


If I were looking for a job, I would really only consider a 10+ hour "take-home" interview if I already had extensive dialog with the employer, met their team, and determined proper fit given my background. I also don't know if I would be willing to put in the time if I was still competing with others for the same position. I know that I would not be able to put in as much free time as others, and devoting that much time to something that might only be used as a measure for comparison is a waste of my time.


I agree that it seems unrealistic to expect someone who is currently employed to put everything down for a few weeks to do a trial project. I've only agreed to them when I was already between jobs. Of course the prospect of multiple weeks-long projects before finding a good position doesn't sound very thrilling. Not sure there is a perfect solution.


What do you think will be the quality of work produced by someone who works all day at their regular job, and then after putting the kids to bed at 10pm, works for another 2-3 hours on the contract project you assign them as part of the interview process, and does this for a week straight?

Personally, my brain is completely fried by the time I get home in the evening.


Left a comment above, but thought I'd ask again... anyone have any experience with GroupTalent [1] which seems to enable this type of small-contract-as-an-interview process?

[1] https://grouptalent.com/welcome/


Hi - I am the founder of GroupTalent. Mahmoud above has had experience on the hiring side of our platform. I can put you in contact with other devs (with their approval of course) who are doing try-outs and they will relate their experience directly.


Given the average success rate of interviews is relatively low this is probably a complete waste of time. If I am expected to do projects like that I am going to do some open source code I care about not stupid interview questions extended to a week...


I'd go so far to say that most interviews do not seem to serve much purpose other than to boost the interviewer's egos. The more that a company is full of engineers who feel trapped in their jobs or lives, the more that this seems to be the case.

The other irritating thing is that people seem to prefer selecting people who are technically more intelligent than they are, but who are less socially apt that they are. It's so bad that I think entrepreneurs need to think about protecting their employees from themselves, because this cannot possibly be good for companies in the long run.

Lets just face it. Engineers often times have low self-esteem (especially compared with "business types")(edit: myself including), and interviews frequently become the one place where they can be on top. It's always re-posed as some "meritocratic" test of skill (isn't it always?), and it's anything but, because an interview setting is not effective at measuring whether someone has the initiative and creativity to get a job done.


I read things like this and I just wonder... Who are these people talking on the Internet, and what universe do they actually occupy?

Because they have some decent points about how the interviews they've been in have been flubbed by the people conducting the interview, but they seem ENTIRELY inconsistent with my experience at any place I've interviewed ever, and I don't think it's my experience any time I've conducted an interview either.

Maybe I'm just not working in the wrong part of the industry? I mean, I think I've gotten some variety in interviewing, like: Silicon Valley - a small-to-medium networking software startup, and a small social media startup. Seattle - Amazon. NYC - Bloomberg, a tiny mobile-software company, and a medium-size very-late-stage media startup.

... and they all have about the same in-person technical-interview processes, which is to say, a little bit of talking mixed with a series of exercises like: here's a toy question, go solve it for us. I say "okay, here's what I'm thinking, X Y and Z, this what you mean? do you care whether it's built more like this or more like that?" start throwing some code on a whiteboard, etc etc


I'd rather let the thread die down a bit before I respond.

I think I hold the record for bad interviews amongst my friends when I was asked to write my traditional Chinese name on the whiteboard. I'm not going to pull any punches here. I've simply lost faith in the interview process, and in the way we vet each other, and the way that we manage and communicate with each other, and I think that a core root of it is how we approach the interview process. The valley was supposed to be a collegiate and egalitarian environment, and I hope we keep it that way.


I think it's like anything, it has more to do with the individual differences.

For most people, cooking and eating aren't a big deal. Others create Soylent because it's too much to bear.

For most people, the standard interview process is fine. For others with self esteem (or other) issues, the process is so threatening they have to opt out entirely.


Lot's of very skilled people interview poorly. Nervousness, social stress, anxiety etc. So don't feel bad, people who interview applicants a lot know this. It's not a mark against you. If they are interested in you, they'll find a way to learn if you have the knowledge/skills they require for the job.

If I don't know the answer to a question or if it is ambiguious, I tell them. For example, I was once asked to describe how a TCP sessions ends. Well, that's implementation defined. What OS? Are we talking FIN ACKs or do TCP resets count as ending a session too? The RFC may say this, but in the real-world, software sometimes does it like that. Etc, etc.

And, many times the questions aren't made to be answered, but to draw things out of you (like the one above). And in these cases, you can turn the questions back on them. Put them on the answering end ;) and that's OK, those exchanges tell both sides a lot about the other.

I do like a few black and white questions. Like, "How many bits are in an IPv4 address" or "What data structure is a C++ set typically implemented in" and if candidates have no idea on an answer, then I do have concern over that. However, if they do not know the answer, but understand types and their sizes and data structures and their pros/cons, then that's good enough in some cases as well.


I'm not sure it's that simple. I had an interview where I got tripped up by a simple condition in a if statement. I don't remember exactly what it was, maybe it involved a quirky negation.

But either way I would've never had a problem with something that simple sitting here at my own computer. Did the interviewer understand that it was just an interview fluke? Probably not. After all, it was such a simple thing.

So I would warn against believing you can see past people's interview issues. Companies in general seem to have a misplaced level of confidence in their hiring processes, even assuming their proxies for intelligence weren't naive.


In the case of startups, you get people interviewing that have very little interview experience.


> So don't feel bad, people who interview applicants a lot know this.

They do, and they will count it against you. (A few people in this thread have actually said this)


In addition to the people overtly saying this makes you a no-hire, it's almost impossible not to use this even if you try. Someone smooth and mistake-less will make a better impression on you, and like with most fallacies, you're left flying blind on how much to adjust your expectations to counteract it.


I think those people are the vocal minority. In my experience most interviewers will go out of your way to get you to feel comfortable and relax during the interview process.


Ike, I understand your reasoning and admire the stand you've taken, but please don't do this. You're hurting yourself and the rest of us, too. Let me explain...

I may be one of the most contrary programmers here on HN when it comes to this subject. I have never shared code or given references before a job offer and I never will. I believe that reviewing code that's already been written has far too much risk for any benefit; permissions may be required, explanations are often needed (but never given the opportunity), and most of all, taken out of context. I want a prospective employer to do their own work to evaluate me, one on one, without depending on other code or others' opinions. I will do whatever it takes to help them do this, including interviews, meetings, and yes, coding for them.

As an interviewer, I have used many tools to get to know the interviewee, but the coding exercise has alway been, by far, the most important. If you can code, great. If you can't, I'll find out. If you struggle, no problem, we'll work through it. But I have to know, otherwise we can't move on.

The trial project is a great idea, but for many reasons, it's not an option for many employers.

Do whatever it takes to get past the roadblock of not being able to do a tech interview. There are plenty of resources to do that. If you struggle and your interviewer is a jerk, then no problem: you didn't want to work there anyway. If you struggle and your interviewer helps both of you to solve the problem, then you've both learned a lot about each other.

(Also, please try to avoid language like "I will not...". Except for murder and ethical issues, this will probably hurt more than it will help.)


> I have never shared code or given references before a job offer and I never will.

Yes, I think our concerns are different than the OP's.

A scenario that has played out for me is that I get an e-mail or call from a headhunter. They want to send my resume to a company. The company likes my resume so I get an interview. Right away they want three (or sometimes more) references. Often they say they prefer, or even require, that they be managers. Obviously this means I have to contact my former managers and co-workers. I have to make sure I still have current contact info for them for one thing. I also want to give them a heads-up that someone might be calling them for a reference.

Perhaps I'm not asking for a big favor but I'm still asking for a favor. So every time I go on a job interview, I have to ask several people I know for a favor. Some of whom I might not have had much contact with in the subsequent years. Then I have to contact them out of the blue and ask them if they can give me a reference (I usually do keep in contact with people, but don't want every other contact being me asking for a reference or a favor).

Like you, I think it's understandable if the company is about to offer me the job and as a last step want to get some references. But I have people telling me they want to talk to my former managers before I've even had an in-person interview.

Compared with this, someone grilling me on data structures, or paging, or TCP/IP behavior, or whatever is pretty minor.


I completely agree with this; I understand and have sympathy for Ike's position but like you I cannot proceed if I can't establish that you can code. The technical interview is currently the tool I use for that.

Having said that, I think that an at-home project prior to the interview is useful both for pre-screening but also as a sanity check on the conclusions of the technical interview - if someone blitzes the project but flunks the interview that would make think that maybe the issue was the interview (or the interviewer) and not the interviewee.

Lastly, I think that if someone is aware that they do not do well at technical interviews then the best way to deal with this is be up-front with the interviewer, and try to bolster your case by having some code (perhaps on Github) for them to review. No-one I know likes an awkward or failed interview - we want people to succeed - and if you're honest with me about the issues I'll take that into account.


I have passed a bunch of job interviews in the past - but I feel the exact same away and hire this way these days. I really do not see the point of brainteasers or white board coding questions if you have a budget where you can just pay out a contract like this.

Also, I believe there was an article posted here a few weeks back that indicated Google's brainteasers did not lead to quality candidates - I know I am cherry picking something that supports my beliefs but it was here nonetheless.

Also, I have interviewed a lot of people with 4.0 BS/MS in 5 years that turned out to be horrible employees. They were awesome with the brain teaser questions but sucked when they actually had to build something.

I guess I do not see how you can lose if you take the contract-to-hire approach ..


I guess I do not see how you can lose if you take the contract-to-hire approach

I agree with most of what you said, but one way you can lose if you insist on contract-to-hire is that you are filtering out a portion of the highest quality candidates who are only interested in immediate full time hiring.


Agree with this. There's a definite stigma with contract-to-hire, at least in my group of tech friends.

No one desires to be in a contract limbo where they aren't sure if they're going to be hired for real or or if they're doing the job search all over again in a few weeks.

Further, as soon as you use contract work to determine hiring criteria -- you've added your management into the mix. Are expectations made clear? Is the person's time managed efficiently? If management fails at any point then it's detrimental to the prospective employee's future, likely not by their own fault.


The contract doesn't/shouldn't be for a meaningful amount of work. It should be for the smallest amount of work that will allow you to evaluate the candidate. It doesn't even have to be for 'real' work - it could be a problem that has already been solved, or something that you think could be better but isn't a priority.

The point is, there's no reason for it to be a genuine contract position, and every reason for it to be concise enough for them to fit in during their off hours. After all, you are going to have to look at it too :)

And they do have the time for it: after all, they are making the time for interviewing.


disclaimer: i am 1/2 two members of the management team at my company - if it was larger - this could be a problem I agree


I don't think many candidates are interested in "immediate" hiring. Most people I know need to take extra time to wait for other offers to come in.

It also gives the candidate a way to see what kind of problems he'd be working with, and the quality of the code-base, working conditions, etc.

I think it's a win-win.


Many candidates with current jobs that they would like to leave are only interested in immediate hiring. They do not have the luxury to take several days off of their existing job for a tiny contract which might or might not land them a job that they might or might not prove to want.

One size definitely does not fit all here.


Nearly all of the high quality developers I know aren't interested in contract-to-hire, I know I'm not at all. To many things can go wrong in a short contract window, and regardless of the reality, most immediate hires feel they have a much stronger connection to the employer.


Well I would want contractor rates >$550 perdiem for this short term contract and via my company so I can reap the tax benefit.

Trouble is most employed people will have restrictions on outside work and if its related work the current employer will own that IP.


I recently switch jobs and can say with certainty I had no interest in contracting or contract-to-hire positions.

Quitting a full time job for a new position is a big commitment on my part, and I'd like a big commitment on the other side of the table. Not to mention contracting gigs don't usually have insurance, vacation, or other benefits.

If it means a more rigorous interview that's okay with me.


It doesn't have to be immediate, but most high quality workers will not be interested in anything that requires them to spend a period of time without a full-time job. So whatever contract work you give them will have to be small enough that they can do it while still working a full-time job, or you will miss out on most of the high quality people.


All of you guys are imagining some sort of 6 month junky contract to hire situation. All I'm talking about is a 3-10 day contract like the article mentions.

An unemployed candidate can do a contract like that while evaluating other jobs and possibly waiting for other offers to come in.

An employed candidate can do the work in off-hours.


>filtering out a portion of the highest quality candidates

if you're not able to easily spot such a candidate without attempting to make him/her to jump through the gimmicks (brainteasers, contract-to-hire, etc..) - well, it indicates the issue with your company and hiring practices in particular are deeper than just what gimmicks to apply.


> if you're not able to easily spot such a candidate without attempting to make him/her to jump through the gimmicks (brainteasers, contract-to-hire, etc..) ell, it indicates the issue with your company and hiring practices in particular are deeper than just what gimmicks to apply.

I'm not sure if this is a joke, but I'll bite.

The entire problem with hiring is that no-one, I repeat, NO-ONE is capable of determining who are the best candidates. If they could then everyone would the same formula and this would be a solved issue.

GOOG and MSFT have tonnes of hiring data and they admit they can't do this very well. It seems very presumptuous of you to assume you can and anyone who can't is somehow an outlier.


Good point. Maybe the best approach would be to let the interviewer choose the approach that works best for them. It would be sooo refreshing for a company to present me with interview options that will showcase my skills the best.


I've become a real believer in the "portfolio". I make the assumption that any person with a github (bitbucket/etc) site with a track record is someone worth looking at; if their portfolio demonstrates quality work and the resume looks all right, I'll recommend them.

Yes, false negatives, people with horrible IP agreements get screwed, etc. False positives are much worse than false negatives in the common business wisdom.


It seems to me like software engineering is one of the only fields with people arrogant enough to assume that every good and passionate programmer should also be doing programming as a hobby.

I loved software engineering so much that I decided to turn it into a career, so that I could do it every day. But now you want me to do it every day and every night? No. My work during the day is fulfilling. My hobbies provide variety and an opportunity to pursue other interests.


It seems to me that software engineering is one of the only fields with people arrogant enough to assume that employers should hire folks without being able to see what they've actually accomplished.

A "portfolio" does not have to, and should not, consist of side projects. Don't have any real code that you are allowed to share? Obviously, many employers won't hire engineers without reviewing existing code or having you engage in a coding exercise, but here's an idea: take a bunch of screenshots of public-facing applications/functionality you've built for your current and/or past employers. With WordPress and a $25 portfolio theme, you can have a decent-looking showcase of your work product up and running in a matter of hours.

If you have absolutely nothing that you can share (code, screenshots, a URL, a "case study") with a prospective employer, it's not the prospective employer that has a problem.


What? Not everyone works on front-facing, UI applications. What if I contributed a good amount of code to a large tech company's networking infrastructure. What do you want me to show you? A picture of the servers? A picture of Amazon's homepage or google.com, if those are the companies I'm working for?

Not being able to show "code" or "screenshots" is not the fault of the prospective employee (as you "oh so subtly" implied with your last sentence).


If you're concerned about your ability to convince a prospective employer that you're the real deal, that's for you to figure out, isn't it?

The point here is not what you share, but that you have something to share and can present it in a manner that's compelling to your prospective employer. In some cases, that might be nothing more than a well-written, detailed description of what you developed. In others, a picture is worth a thousand words and can a preferable format for somebody who isn't a great writer.

And finally, while I wouldn't be so naive as to argue that "engineering" equals "working on public-facing applications", engineers should consider the risks of roles that do not enable them to work on systems that are "visible" or "close to the money". Obviously, there are some industries and specializations that provide lucrative opportunities that don't do this, so there are exceptions. Not every young engineer, however, can realistically count on being able to build a decades-long career in these industries/roles.


> A "portfolio" does not have to, and should not, consist of side projects.

I agree with this

> If you have absolutely nothing that you can share (code, screenshots, a URL, a "case study") with a prospective employer, it's not the prospective employer that has a problem.

I disagree with this. If you require this to be true, you've instantly excluded everyone's experience in either government (particularly defense), or industry when you work on internal services. There's a huge number of enterprise developers at my current company who will never be able to show you their work because they're all internal applications. Maybe a "case study" would work, but you have to be real careful of not to cover anything that doesn't fall into the trade secret category.


If you're in an industry where it's typical for candidates to be limited in what they can share, then ostensibly the hiring criteria and process would reflect this.


If I have two candidates and the only signals are (resume, portfolio), then I will select the highest signal. I am sorry, but I can't in conscience decide to take someone without proven work over someone with proven work without other information.

If your resume is significant, then I will probably add to the signals with a phone call followup. I'm not looking to create false negatives.

I also want to point out that taking some time to develop a small and interesting project (say, a pure left-leaning red-black tree with deletion - not much code, but tricky to get right) does not take that much time and massively demonstrates your capability over having nothing at all. It also demonstrates your social awareness of the state of the field when you have a github account with projects in recent technology.


> If I have two candidates and the only signals are (resume, portfolio), then I will select the highest signal. I am sorry, but I can't in conscience decide to take someone without proven work over someone with proven work without other information.

On the upside, the person with a code portfolio and less other hobbies is also more likely to be winning to commit more of their time to work, stay later, do "hackathons." It's a win-win for the employer! /s


I couldn't agree more. I think far too many candidates fail to make an effort to demonstrate what they have achieved in the past, which is generally a pretty good indicator of what they're capable of delivering going forward. Although portfolios are a must for designers, I'm always amazed that more developers don't put something similar together to showcase their work.


Early in my career, I decided to transition away from mechanical engineering and applied for programming jobs. Many companies refused to even talk to me. But for one that did set up an interview, I brought in listings of software I'd written. I basically ran the interview, bringing out the listings and explaining what I did, and I got the job.

I've interviewed many candidates, and it surprised me that pretty much none of them would take the initiative and sell me on what they could do. They'd passively wait for questions and then answer the questions.


Right. Most "brain teaser" technical interviews are just an oral test. We all know that passing a test is hugely different from productive work.

I don't understand why technical interviews are not more oriented to "how would you design X? Ok, what objects? What interfaces? How does that work, explain like I'm your 10yr old nephew? Ok, pseudo code that part. What are challenges with it? Have you coded similar things? Tell me about one. How would you do it different now? How would you convince me that it's worth refactoring? How about if I was your peer and I told you your idea was the worst thing I'd ever heard? Ok, now assume I'm working for you, and it's my second week, explain how to write your new design from scratch, and what some gotchas I should avoid are?"

We all know that green field coding is a rarity, and most time is spent writing/running tests, refactoring, bug squashing, design writing, code reviewing, team managing (always at least upwards and sideways). Most of this is still "technical", but seems to be overlooked with endless stupid brain teasers. I know what Knuth volumes are, I know what google is, and I know my basic algorithms. Most people don't need to have memorised how to implement random algorithm x.


> Google's brainteasers did not lead to quality candidates

This is why we at Google don't (or shouldn't, at least - it's widely discouraged) ask brainteaser questions in interviews.

I disagree on whiteboard coding though. I don't find it that easy, but I think it's reasonable to expect a demonstration of relevant skills before you hire a candidate. Any sensible interviewer won't expect syntax-perfect code on a whiteboard, but it's at least a way of seeing if the candidate can walk the walk rather than just talking for an hour.

> I guess I do not see how you can lose if you take the contract-to-hire approach ..

For the first month, the vast majority of people are relatively unproductive. After the next month, good candidates are generally still going through a significant learning curve. Contracting several candidates for a few months to pick one who seems good enough is expensive for relatively little output - apart from salaries, they need desks and computers etc, and you have to do some interviewing to pick them in the first place. It's not a worthless approach, but I don't see it as a panacea.


Well, the person that referred to the article used the wrong term. Certainly brainteasers don't work, and they have been prohibited at Google for awhile. But the recent article stated that there was no correlation between interviewers and job performance. That the beloved hash table, distributed computing, priority queue, red-black tree questions that you pepper people have nothing to do with the quality of the person you hire.

Which I have argued many times on here, should be glaringly obvious. Measure what you want to measure. I have never said "I'm so happy we hired Jane, she just tore up that smart pointer implementation yesterday". I like and dislike colleagues based not on comp sci algorithms, but whether their code is readable, how many bugs are in it, how quickly they can produce production quality code, whether they are responsible and hit deadlines, if they ask for help when they need it, if they offer help when other need it, if they are creative, if they are doers and achievers, if they take baths (seriously), if they step out of their office and interact once in a while, if they are problem solvers, if they read and keep up with their field, if they are capable of learning, if they write good documentation, if the client likes them, if I like them, if younger people look up to them, if older people feel some pressure because here is somebody up and coming, if when I go to modify their code I only need to change it in one place, and my change fits in naturally without breaking 15 different things (because it is designed with extensibility in mind), and that my heart beats a little faster because their code is just so beautiful. And so on.

Google doesn't try to measure any of that. At all. And then you (google, not you archangle_one) express mystification at why your interviews do no better than chance. There's a clue there, I'd say. If you don't measure job performance, why do you think your measure say anything about job performance?


i once needed a job so bad and was asked to solve a Rails challenge. i never did Rails before but i learned it and solved the challenge in a week. i also thoroughly documented my learning process and decisions. However i was rejected for being too fresh which i understood, i learned a lot during that week and even though i didn't get the job i feel that i achieved something. so i also don't see how you can lose with a contract-to-hire approach.


That's great that you got something out of it, but I have to wonder why it took them until after you completed the task to figure out that you were "too fresh."


the best reason i remember was that it wasn't unanimous. my submission had to go through several people, and while the guys who i had direct contact with showed that they liked me, the decision came after their meeting with the CTO.

They also knew before hand and gave me a chance perhaps i would do something very impressive. i'm not saying my submission was perfect, i might have done a couple of things wrong, or during that period they might have found someone better, there might have been several reasons i think, but i still learned a ton about Rails.


Given the plethora of comments, this will likely get buried but I'll weigh in regardless as those who suffer from the anxiety issues the author mentioned will likely scroll through most of the comments.

Every issue the author mentioned can and should be mitigated by a decent internal recruiter or manager. Essentially whoever initiates the contact with the developer maintains a responsibility to ensure that their 'candidate' is as comfortable as possible throughout the process, regardless of who they are meeting.

I've dealt with plenty of people who suffered from the exact issues the author describes. It's a lot more common than you'd realise. I've also dealt with rare occasions where I've helped candidates with autism, aspergers and even down syndrome through the interview process.

If you form a decent rapport with your candidate and truly comprehend what they really want from a job with your company as well as 'grok' their personality type and limitations then there really is no excuse for dumping them into a situation where they feel so stressed and under pressure that they shut down.

Your responsibility doesn't end with the candidate though. It's equally important to ensure that the people who will be interviewing this person after you have a decent understanding of the type of person they are about to meet and to ensure they are equipped to deal with a situation where the person being interviewed begins to crumble.

As for references to previous submissions and comments where people claim to have "solved the interview problem", I call bullshit. Every company, every hiring manager, every team, every job and every candidate is different. The silver bullet to 'solve' the problem simply doesn't exist and never will. Sure there are companies with fantastic processes but for every 'perfect process' you show me, I can show ten companies where that process simply wouldn't work.

The best thing about these discussions is that it encourages people and companies to simply try harder and that's never a bad thing.


Unfortunately I think people who take the type of care you outline above are in the minority of recruiters/hiring managers. I don't know what the solution is, having been on both sides a number of times.

What I worry about most isn't that the contemporary coding interview creates false negatives. What I worry about is I suspect that it unevenly creates false negatives.


Not quite the same, but I once had a no name company (getglue) tell me that I need to do a 3-hour programming assignment before I can interview with them. I have too much self-respect for myself to put myself through that process. I declined the "opportunity" to interview with them.

The interview process is broken and many of the interviewing techniques either do not correctly judge a candidate, or place too much burden on them. I guess the reasoning is that a false negative is better than a false positive.


Good decision. I regret very much that I didn't make the same decision you did.

I did a 5-7 hour programming homework assignment, didn't hear back for weeks, and then it was just from a recruiter (sorry, we've decided not to continue the process).

I won't do it again, ever. It's not the wasted time that I regret so much. I do agree with you that there is a self-respect element to this.


I'm curious, is this a money issue, i.e., you refuse because it feels like working for free? Or is it just a principal thing?

I doesn't seem unreasonable to me to ask even a senior developer to do a small coding assignment as part of the interview process unless they can show a good, relevant coding sample.

If we're going to agree that whiteboard coding isn't a great way to evaluate someone, and we can't ask you to do an assignment on your own, what else is left? Talking about past experience is great and an important part of an interview, but I think most people want to (rightly so) see some code at some point before extending an offer.


I'm curious, is this a money issue, i.e., you refuse because it feels like working for free?

Not OP, but it doesn't "feel" like working for free. It is working for free.

Having someone perform work for you without paying them is illegal in the United States (see minimum wage laws).

There's a simple solution; pay them $x per hour to do your 3 hours of work. Even if you pay them $100 per hour that's a cheap way of filtering out pre-screened candidates.


Hm, I guess I didn't think about it that way since we wouldn't actually ever give out "real" work, we give out the same problem (which is an extremely scaled down version of a real application) to most everybody who passes a phone screen.

I think paying them is perfectly reasonable, but I'll also note anecdotally that having done this for many candidates for years, I think very few people have ever declined.


>>...which is an extremely scaled down version of a real application

You're putting the candidate in a very vulnerable and stressful position:

You're potentially asking a candidate to solve a problem with your application (even if scaled down)--

The question/assignment could be a long-standing issue your staff have been unable to address on their own and you want to try to find out whether you can get a free solution from qualified people.

The candidate(s) could get the correct answer, yet you could walk away from the process with a free solution.

>> "I think very few people have ever declined"

That's short-sighted - they're not declining because the want/need a job and are already vulnerable during the process; many would not, understandably, have the presence of mind to decline.


You're really twisting my words quite a bit here. We give out a very greatly simplified version of a real (solved) problem so that we're screening for skills relevant to the position, not because we need people to work for free.

I just don't see a couple hours spent on a interview programming assignment as being any different from the 5-6 hours you spend in the office being interviewed, which by the way, you don't get paid for either (excepting reimbursements, etc).


Interview programming assignment = work? I don't agree with this.


I think they wanted him to do a 3 hour code test before they even talked to him


Would you rather go to an in-person interview and waste half/full day?

I'll do a take-home programming assignment anytime over an in-person interview to gauge mutual interest.


I once had a no name company (getglue) tell me that I need to do a 3-hour programming assignment before I can interview with them

In that case, I would think I was the subject of a psychological experiment entitled, "How far can we push developers".

Although it would be tempting to accept the offer and then write whatever code they asked for in QuickBasic 4.5 (circa 1988) telling them they need to use something more stable than the crap they're using.


Write the answer in Scheme.

I've only ever answered one interview question in Scheme, the problem was perfect for it. :) I first had to check if the interviewer knew Scheme, and he did!

I fear it has been long enough that I could not repeat such a stunt now days, but last week a resume came by my desk that had LISP listed on it, so I prepared some problems that would be trivial in LISP just in case. Unfortunately it was as I had suspected, a stale language listing that should have been removed from the resume long ago.


I agree feverishly with you post.

I've been a dev for 10 years and worked in Sydney, London, New York & San Francisco. What I noticed is that San Francisco has a very different "technical" interview approach that is very CS focused. I studied a CS degree (7 years ago) and think it's stupid that I have to dig into knowledge that I have not needed professionally over my whole career.

I've built successful startups, coded mamoth apps used by millions of people, but failed interviews at companies like Yammer.

I wrote a post about how I conduct technical interviews for my company airpair.

http://hackerpreneurialism.com/post/43661666180/how-i-conduc...

Pair Programming is KEY.

Also, side plug we've been getting lots of business both around preparing for interviews and helping to interview candidates when you don't have in-house knowledge to vet skills you don't have.

Here are some examples:

http://airpa.ir/1d5sqR6 (Need help reviewing candidates code)

http://airpa.ir/1dteU8H (Need help interviewing an iOS candiate)

http://airpa.ir/173ily2 (Needed help preparing for JavaScript interview)


Well, I need to interview candidates because I need to know if they are up for the job when systems breaks. If a table query fails because it needs a btree index due to range searches, I want the candidate to know how a btree index works and why it fixes the issue. Also If somebody cant tell me the difference between http udp and tcp, its a no hire for me.

So for me, I really want to interview somebody before he can work with me.


Can you not understand that there might be people who can complete your task easily, yet who have extreme anxiety about interviews? I actually understand this issue -- I've been trying to switch careers into programming for the past year. I've know several languages well (Python, JavaScript, some C), can use git, and have a few decently impressive projects on my Github profile. I also contribute to a pretty well-known open source project. As a result, it's not hard for me to get an interview. Nonetheless, I've discovered that despite being very good at interviewing in my prior (well, still current) career, I completely freeze when I interview for programming jobs. Programming interviews seem incredibly confrontational compared to my current profession. Interviewers seem to be out to trick you at something, or else to prove how much smarter they are than you. So I predictably freeze in these types of situations, to the point where I blank on things that I can usually do, even under pressure. It's been a big shock for me, since I did very well in school and went over a decade without "failing" an interview (i.e., taking an interview and not getting an offer) before attempting to transition into programming.

But I love programming languages and software development, so I do contracts from time to time, which always go well. Unfortunately, I've not yet done a contract that was actually for a company that was actively hiring employees (most were for small businesses with no full-time developers). But this post has given me some hope. If there are companies willing to let a candidate work on short-term contracts to prove their worth, that means there's hope for me yet to be able to move into software development full-time.


>Programming interviews seem incredibly confrontational compared to my current profession. Interviewers seem to be out to trick you at something, or else to prove how much smarter they are than you.

well, welcome to software engineering. The interviews are for the reason, they let you peek into your future job. If you can't manage that environment for 4 hours of the interviews, how you're expecting to manage it for many years if/when you get into software engineering?

I'm not trying to be mean, i'm just warning that something like having a fresh out-of-college arrogant Millenial reviewing your code means - well suffice it to say that at my previous job it drove 6 out of 8 person team in 1 year, all from mid to senior engineers, me being 7th, to either change the team (3) or leave the company (4). The guy is a pest, smart, driven, high GPA from top University...


I realize that it can be hard to understand without having experienced interview anxiety yourself, but it is an entirely different environment.

I suffer from interview anxiety to the same extent as the author of this blog post. Though I am a very skilled developer, I completely freeze in these situations (I even failed a fizz buzz test once). This doesn't translate to difficulty with on-the-job stressful situations however, as my anxiety is only present in interviews.

Most of the anxiety stems from me running through negative thoughts in my head ("I'd REALLY like this job - I'd better not screw up.", "I did poorly on my last interview. I'll probably do poorly this time", "The interviewer can probably see that I'm anxious.", "Does my voice sound shaky?", etc.) to the point where they trigger a fight-or-flight response.


>I realize that it can be hard to understand without having experienced interview anxiety yourself, but it is an entirely different environment.

my point isn't about denying interview anxiety existence (i suffer from it myself), and it has solid science foundation - speed of dopamine removal once your system is flushed with it. Some people have it faster, some slower. The former ones are great performers in acute short-term stress, while the latter ones are better at long/deep concentration on a task.

My point is about interview situation being preview to a lot [not all, yet a lot and many of them will be key ones] of future situations.


I understand where you're coming from, but I disagree that this is a matter of individuals' responses to stress in general. I know that in my case there is nothing else I have ever experienced that can trigger a stress response equivalent or even similar to what I experience during an interview. It is irrational, but it is entirely separate to anything I could experience through professional work. It is not the questions being asked during the interview that cause anxiety, it is the interview itself. I actually find that I work quite well under high-stress and high-stakes work environments.


from your descriptions it sounds pretty much like my situation.

>I actually find that I work quite well under high-stress and high-stakes work environments

not getting the stress and being able to manage it is 2 different things. Couple jobs ago we had real clients with real problems, and it happened pretty naturally that i became the top "firefighter" that is brought in when support, escalated support, services/solutions, related development, etc.. exhausted their options and various executives on both sides are having sparks out their tailpipes - one may call this a high-stress and high-stakes environment, yet i just wasn't getting any stress, to me it was a simple 2 step algorithm : 1. forward me your AWR report (and this is instructions on getting it) 2. this is your root cause, config changes, emergency patch, etc... Simple, familiar, no stress (which i can't manage as i just get paralized/stuporred by it, like, in particular, in many interview situations)


I hear what you're saying, and to a certain extent I agree. However, maybe that's the other benefit of doing these kind of pre-hiring contract jobs. They let me see what kind of an organization I would be working with.

In any case, what are you doing now, having left your company because of the environment that you see as plaguing software engineering? Did you change professions, start up your own company, or find a company that didn't have these issues?


droning at a BigCo. with guys we go some way back.


> Programming interviews seem incredibly confrontational compared to my current profession. Interviewers seem to be out to trick you at something, or else to prove how much smarter they are than you.

Many interviewers are poor at doing interviews. :(

I do not try to trick anyone in any interview I do. I put forth a problem and ask people to work towards a solution. If I feel the solution can be improved upon (not necessarily to get the answer "I want", but in an overall sense of software engineering) I start asking exploratory questions about why some piece of code was implemented some particular way.

I have a set of questions I ask every candidate that comes through, the questions start off easy and work their way up through a progression of difficulty. None of the questions are me thinking I know how to do best, and on 2 occasions so far I have hired people for at least in part giving better answers on the questions than the solutions I knew.

As for confrontational, I try to remember that almost everyone is below optimal during interviews! I get nervous during interviews as well, I don't expect people to be at the top of their game and nail everything, silly mistakes that normally would get filtered out before fingers hit keyboard end up being put on a white board for fear of time. I get that, I do the same damn thing when being interviewed. :)


Interviewers seem to be out to trick you at something, or else to prove how much smarter they are than you.

I'm sure there is a lot of that out there, but that is definitely not my reason for asking hard questions.

We will always be interviewing at least a few people to fill a position, I think that's natural. Suppose I ask you and the other candidates questions... and you all get them all right. Well, that's fabulous, but now I have no way to distinguish which of you actually knows more about a particular subject.

And I think it would be stupid for me to ask the interviewees to answer questions to which I don't know the answers.

So we're always going to be in a situation where I'm asking you at least some questions that you don't have the answers for. I need to test your limits, and see how firm a grasp you have on various subjects.


[deleted]


Well, that is pretty offensive. You're calling me incompetent, whereas I'm definitely a competent person. I did well in school (3.6 GPA in a good college), finished a master's degree, and have done well in an established, albeit dying, profession, including speaking at conferences and writing for trade publications (and even co-wrote an article for a peer-reviewed journal, which is unusual for my profession). If you're referring to my programming chops, well, I think it's pretty impressive that I taught myself to code in my 30s, and that I am now very comfortable in Python, JavaScript, and (to a lesser extent) C and Lua. I even play around with languages like Haskell and Ada for fun. I taught myself git, built several large web applications (which are part of my portfolio), and have almost finished a complex Android application (thus adding basic Java to my list of languages). I've unfortunately not yet had the opportunity to be mentored by someone more experienced than me, or participate in a large team-driven project, which I realize is now holding me back from the next level of programming expertise.

I could make similar presumptions about you based on your response, but since I don't know you at all, I'll refrain.


Perhaps the solution is for the interviewer to tell you upfront "I don't know the answer to this as well, let's try and find a solution, together, but you start first"?


Hmm. That might work. But I'm skeptical, for the following reason: the main problem seems to be that most people who have done tech interviews and who don't excel at them have already been "traumatized" by prior interviews that their adrenaline is pumping and almost no amount of sane approaches can lower that tension in an hour or two. Maybe if you spent a half-day doing non-stressful activities and meeting people, and established some modicum of trust, that approach might work. But in an hour or two, there's no way for a stressed candidate to dial-down their anxiety.

It's funny, for years, I was always the one who relaxed and excelled at interviews, because in my current profession, interviews are fundamentally social affairs where you talk about your accomplishments, publications, etc. So as you can imagine, I went into my first tech interview entirely unprepared for the confrontational puzzle-fest that was to ensue. I found the whole experience so jarring that I still am hesitating to pick up the phone and try to schedule an interview for a company I know I would enjoy working for, and for whom I could do great work. I think I require some sort of Zen experience that rids me of my ego entirely before I can approach an interview with the same equanimity that I used to have.


I never understood the fascination with asking an applicant about minutia of data structures and algorithms. Isn't that the domain of reference material?

I gain much more insight into a person by asking them to describe a large system they've designed, what choices they made, the effects those choices had, ect. How did their initial assumptions hold up through the course of the project? How did they adapt to changing requirements? These are the things you can't find the answer to in 30 seconds on stack overflow.


Put yourselves in the shoes of an employer. There are a hundred candidates applying to your position. Would the answer of "just trust me" convince you to hire one person above the 99 other applicants? If only one of those 100 applicants showed they had the skills you wanted, right out of the box, wouldn't you feel better about hiring him?

I think the attitude of "they should hire me, since I can learn anything" is self-centered. There are a lot more people that can't learn. Without testing methods available there is no way to distinguish the self-starters from the frauds.


The problem is that most companies make terrible decisions about which skills they want right out of the box. They can't get people that are 100% on everything they actually need (as such people are unhireable for the job/pay they're offering), so they settle for people who know a lot about B+ trees (or more likely, how to reverse a linked list and do a bad version of quicksort on a whiteboard) because that's what the folks who have been studying their "how to get hired at a tech company" webpage know.


I get your point, but knowing the differences between http, udp and tcp isn't minutia ... it's cornerstone knowledge for anyone working with distributed systems.


I'd tell you a joke about udp but you might not get it.


I'd tell you a joke about TCP but if you didn't get it I'd have to tell it again.


The answers of "look it up in a hashtable" and "look it up in the literature" will get you through a lot of interviews


If only there were some way an employee could learn about btree's after taking a job...


On the job training? Heresy! Shun the unbeliever, shun!

In my own current position, I would not have gotten the job if they had interviewed me then like they interview new hires now.

Don't know how to find and recover active but deleted files? Goodbye. Don't know how to follow strace around a distributed environment? See ya. No idea how the elevator works? Why are you even applying?

I know how to do all of those things now, because I asked questions of my colleagues and the internet. I'm now the lead developer, not because I knew everything coming in, but because I am able to learn.


I don't want my employees to have to learn everything just-in-time. By that logic, the people you hire wouldn't need to know anything. In addition, they don't know what they don't know, so they may not even know that they need a btree index.


I hire people based on their ability to learn, not what they know.

If you're asking interview questions that can be googled in 20-30 seconds, you're wasting your time and theirs.


You have a pretty low opinion of our field if you think everything that you need to know about our field can be googled in 20-30 seconds. I'm not arguing about minutia questions, but if you can't be bothered to understand how and why to optimize a database or the difference between TCP and UDP (really?) and that's what the job requires, then I don't want to hire you.


My argument is don't play puzzles, don't ask stupid questions about "What does this command do with these flags?".

An interview should be the same as a discussion about concepts you'd have with a colleague. Does the person know the concepts? That's all that matters.


Basic computer science knowledge (and yes, B-Trees qualifies) cannot be learned in 20 seconds. Most of this knowledge is actually a prerequisite to being able to search Google properly.


Fair point. I was unfamiliar with B-Trees because most of my time is spent as DevOps/Networking/Sysadmin. It took me 15 minutes to learn and understand what they are and how they work.

http://slady.net/java/bt/view.php?w=800&h=600 http://en.wikipedia.org/wiki/B-tree http://en.wikipedia.org/wiki/B%2B_tree http://guide.couchdb.org/draft/btree.html

Now if you make understanding B-trees a prerequisite for the job, I can at least learn it ahead of time for the position.


how often does a normal software developer find himself in a situation where he has to know about B-Trees in depth?


Basic computer science problems creep up often enough (about once a month) at my mostly normal job. We had to implement a prefix trie (specifically a modified radix trie with extra caching) to solve an interesting problem.

If you don't know about these data structures or algorithms, you won't even know where to look.


When he works for the company that this whole conversation is stemming from.


Database indexes are very frequently btrees; understanding how a btree works can inform how you structure and query data, resulting in substantially better software. They're also a generalization of the binary search pattern, which every programmer should be able to describe and utilize.


This is a popular opinion which still makes hiring an art. The best people I have ever worked with are the people who are fast to learn, have amazing problem solving skills and are socially intelligent. That's it. No knowledge of btree required.


> I don't want my employees to have to learn everything just-in-time

What about just some things. And in most cases, it's not learning for the first time but brushing up on the topic. To expect people to have encyclopedic knowledge of every edge-case problem your company deals with on a day-to-day basis is ridiculous.


As OP said, you would not be able to google the specific B-Tree question because if you don't know about B-Trees you wouldn't know that you need to google it.

There's a difference between things you know you don't know (and therefore can google), and things you don't know you don't know (and therefore will not google).


"I can see you're a bright individual and you have a great track record for writing and shipping good software, which is clear from your github account and your previous employers' endorsements. I have no doubt you'll be able to come up to speed on <insert obscure discipline> which is something we use a lot around here. We're looking for people who can learn quickly. Welcome aboard!"


Except that in my experience, software development is mostly about learning things just-in-time. Most projects pose new challenges, or you want to use new technologies, and so on.

Imagine you hired some Cobol developers some decades ago, and therefore you would still be stuck using Cobol on your projects.


No, you would just fire all of the Cobol developers to bring in the experienced Pascal developers.

How does one become an experienced Pascal developer? That's somebody else's problem.


>I don't want my employees to have to learn everything just-in-time.

You can require knowledge without using dealbreakers like "you must know b-trees". A better alternative would be to say "you need to know 30% of the following group of things: b-trees, tcp/ip vs udp, ..." and so on.


This is a lot like what I try to do in interviews, because I'm mostly just trying to filter out liars. I pick projects out of the candidate's resume and ask them about things they had to have learned to do the job they did.


What if they could explain what a b-tree is, and why they are useful, but that they'd have trouble implementing one on the spot. If they told you the name of a good book they know that has an explanation of b-trees. That they read the chapter a while ago, which is why they can generally explain what a b-tree is, and that that's where they'd go if b-trees came up and they needed to write/implement one?

I don't mean to imply that this wouldn't be acceptable to you. I do "know" that I've been screened out after giving an answer like this (to the extent that I can really know the reason, legally they aren't allowed to say).


The truth of the matter is that, for most of us, when faced with a problem we work with what we know. If you ensure breadth of knowledge, you can get better at each aspect, but if you only know a few fundamental ideas, that means that you have to be capable of looking at a problem and rediscovering the right data structure to handle it with. Essentially, you have to be as smart as the guys who came up with it in the first place and more. Better to know the data structures and how they work.

Recognition is easier than rediscovery.


I suppose if you're a network engineer http/udp/tcp is necessary to know maybe off hand but not really, http isn't even in the same network layer so I'd find it strange to even ask about the 'difference'. UDP and TCP differences are more or less a well known question but even then I've had some ask the question expecting the most basic of differences and others with the minutiae.

btree index is also something that can be learned conceptually in about 10 minutes.

It is far more important for me to see that someone can explain a project that they've worked on in the past with enough details to demonstrate sufficient technical knowledge than a litmus test based on somewhat arbitrary facts. 'don't know what lsof is? Not hired, I don't want someone who can't use shell'


"http isn't even in the same network layer so I'd find it strange to even ask about the 'difference'"

Why? You just answered it well enough. There are people who could not say what you just said; you don't want to waste your time on them.


Actually UDP and TCP are the prototypical examples of a reliable versus an unreliable protocol.

Being familiar with protocol design is important no matter what type of programming one is doing, the ideas of ACKs, NACKs, and flow control pop up all over the place!


I don't know what kind of work you're in, but "knowing how a btree index works" (i mean how it really works, not just knowing the word "b-tree", if that's what you meant, nm) ranks pretty high in my book, it'd be outright bizarre if that same person didn't know the difference between udp and tcp?


Believe me, your DBA or the person who writes queries doesn't need to know how exactly B-tree index works. Or even "B-tree" term. Just being aware about indexes and knowing when and where to add it would be sufficient.


I agree in principle that not everyone needs his entire algorithms curriculum resident in his head all the time. However, a DBA should understand the characteristics of the type of index he is implementing. B-tree isn't the only game in town.


The interview process doesn't work for some because it's a gross power imbalance where the interviewee has no control. The interviewee suffers at the whims of the interviewer. Some interviewers enjoy their temporary power over people who are normally not in a position of no power. The interviewee has no recourse for whatever power trip the interviewer throws at him. Many programmers hate not being in control and get anxious at the prospect. The process is doubly hard for introverts, who may be brilliant in the quiet time when alone, but who fail miserably when suddenly put in a position of an extrovert selling themselves. It's unnatural and upsetting.

I feel this is different than in almost all social interactions, such as working with clients or participating in meetings. There is more equality and control in those kind of negotiations.


I walked into an interview once, expecting to go over my work which I'd brought along with me, much of it for the company I was interviewing for, so I wrongly assumed the interview was just a formality. They asked a couple of basic questions then opened a laptop, and BOOM! technical interview right out of no where.

I blanked. They just handed me the laptop and didn't even tell me it was a test. There were some comments at the top of a few javascript files and like an idiot I answered the questions verbally. The two devs just sat their smirking at each other like they'd won at something.

I'm not averse to tech interviews, but I do not enjoy the "look at how smart we are that we caught you out" attitude that comes with them. I'm shit at crosswords, that doesn't make me illiterate.

I've since been keeping an eye on their work and now I get to feel smug because it's been universally panned.

I also had to sit a test for what I call "the worst agency in the world" (AKQA and after 7 hellish months there I'm happy to stand by and put my name to that assessment, they're simply awful). I forgot to specify the radix in a call to parseInt. It was the only flaw and while they didn't make a big deal out of it, the interviewer was clearly pleased with himself for finding it. They then proceeded to ask ZERO questions about why I'd coded the test the way I had. Which is a shame, they might have learned something.

In my experience, there's nothing wrong with tech interviews, but there's a lot wrong with the people administering them. If I want to know wether a dev knows what they're talking about, I ask them to explain something they've already coded. If they can explain it, they understand it, and I usually learn something to boot. Everybody wins.


The whole point of tech interviews is to see if the candidate actually has the requisite skills for the job.

Off-site contract work is NOT a solution. Hint: the candidate may not be doing the work himself; he may be farming it out to oDesk or Elance at a fraction of the price and playing WoW all day.


The whole point of tech interviews is to see if the candidate actually has the requisite skills for the job.

The point of resumes is to see if the candidate actually has the requisite skills for the job. The point of interviews is to verify what is represented on the resume is likely to be true. And, as the op is suggesting, a small contract would verify that the candidate can complete projects for the company and to their satisfaction.

he may be farming it out to oDesk or Elance at a fraction of the price

This is just plain paranoia. No one would do this and expect to be employed at a company for very long. Also, if you've ever farmed work out to oDesk/Elance, you might not want that work to represent you in an interview process (even if you were able to have it completed in a reasonable amount of time).


You can tell this by the code, usually the people who offsite the code have the worst syntax, worst grammar and use foreign symbols in the code unless requested otherwise.

Also, after they have submitted it, go into detail with them as to why they did this, or why they did that. Tech interviews with puzzles, quizzes, and logic are just a massive waste of everyones time.


Easy solution to that is to discuss the work/code in the interview.


i agree..i remember when i was a graduate assistant we would interview students and discuss their submitted homework. It was such a clear indicator of who worked and who didn't. The rule of thumb though when interviewing teams was to meet them all at the same time and never individually.


I dunno. Between off-site contract work and a good design discussion afterwards, I think this would be a good solution. You could make an argument that a candidate that is effectively able to contract the work out and be able to competently discuss the solution (and other approaches) would be a great candidate for the job.


I don't know...seems far fetched. You should be able to sniff that out when talking with the dev about their code.

And if someone at oDesk or Elance does that nice of a job you should just hire them.


What about just setting the interviewer's expectations up front?

"Hey, as I'm sure you may understand, these sorts of on-the-spot interviews are a significant departure from the day-to-day environment under which I normally perform these sorts of tasks. I know this stuff well, but still might fumble a bit because of this atmosphere. Do you mind if I talk through this problem with you as I would if we were working on the job together?"

Short contracts can be great when you can afford them (ie, have time/are not currently otherwise engaged), but sometimes you have to work within the framework provided. Being your own salesperson is not all that complicated: manage expectations, build rapport, and under sell/over deliver.

A good recruiter can help fill in these gaps for you -- pre-setting the hiring managers expectations, coaching you up on interview strategy and tactics, and helping you understand a given company's interview process in full so you can mentally prepare. Unfortunately, most recruiters are not good and dealing with them tends to be a pain. We're building a better recruiter, online, at Mighty Spring (https://www.mightyspring.com). You control the whole process through a web interface, and simply request contact when desired. We're geared towards engineers and are currently in private beta. Will expedite invites to HN signups -- feel free to email me (address in profile).


Sounds like an interesting service, and I will e-mail you shortly for an invite. That said, can anyone recommend a good recruiter like you refer to here, who is good at helping candidates with good skills learn how to interview better? (if so, e-mail is my username at gmail)

I know recruiters have a bad reputations among most developers, but someone like that would be worth their weight in gold to me.


Those European university tests copied by Google, then copied by SV startups, mostly deliver two things, making the interviewer feel superior and filtering for submissive coders.

All managers dream of robots that can read minds and work for titles but lazy managers prefer to hire those who do what they are told, even if its pointless, even when done poorly or without imagination.

A good manager is worth his weight in gold. "I will not do your tech interview" while offering a short contract is an excellent way to screen out the lazy managers.


One good thing about reading/browsing HN is that you can get an impression of the ideas that are starting to emerge. One thing that seems to be emerging now is that people are rethinking the grueling technical interview process.

There was a huge emphasis on avoiding false positives in the interview process - largely because a single bad hire can do great damage to a software development team. But people seem to be learning that these grueling processes may not do as much to avoid the false positives as we thought, and are creating a vast number of false negatives.

I am no longer interested in participating in this sort of multi-day technical exam taking. I've studied stochastic processes, mathematical optimization, data structures and algorithms. I've taken exams on them. I've hit the books for a couple of weeks prior to interviews where I've been grilled on these subjects in greater depth than I experienced during my exams in grad school. It's important knowledge, I get that, but I don't want to have to mentally reload the material in "exam ready" memory simply to pass yet another interview. I will rely on my general knowledge and my ability to look things up on the job. My interviewers should feel free to evaluate my knowledge, but does this really have to be more grueling and take four times as long my final exams in college/grad school?

It's not that a technical screening isn't valuable, it's that the grueling nature of these interviews means that if you can't recursively print out all permutations of a string on the spot, right now, don't get confused up there at the whiteboard, you're a no-hire. It can be very clear that the interviewee is aware of what mergesort is, how recursion works, the importance of run time in algorithms, and that the candidate almost certainly at one point implemented it. They want to see it, now, in code, on the whiteboard. Or, these days, typed into a screen that an interviewer is looking at.

A couple of years back, last time I was looking for jobs, I spent one and a half days in interviews. I was asked to code a singleton, add a branch to a binary tree, traverse a binary tree, now without recursion please!, find the long term probabilities in a markov chain, formulate a linear program and prove that the dual of the primal is the primal of the dual, now with matrix notation please!, write a bunch of outer joins, convert a curve into a piecewise linear function (don't lose convexity, please), on and on. Each interviewer was fresh, I was shuttled from room to room. Then I came back for three hours of interviews with management. No hire.

Another special one was where I only got to talk to a recruiter, passed a few java tests (about an hour), and then took a homework assignment (spend no more than 5-7 hours, please!). Didn't hear back, didn't hear back, didn't hear back. About a month, and the recruiter calls, oh, they've decided not to pursue this any further.

This is a rant, and perhaps an angry one. I feel bad about that, and it doesn't feel great to admit that I've failed in these interviews, either. But I'm glad that some pushback against this practice seems to be building.


I can identify with your post. Now that I have small kids (1 and 3), I find the job search especially time consuming, precisely because of the need to prepare my "exam ready memory" and whiteboard coding skills. It's biased towards new grads and single 20 year olds, like many things in our industry.

On the bright side, in my most recent job search, I've noticed this type of interview style has become a lot less common. It still happens at the big SV firms (for example, I spent an entire hour phone interview doing multiple algo code problems and not once asked about my experience), but I think the smaller companies avoid it.


HN has its fashionable topics. Interview bashing is popular at the moment. It's also a suggestion to me that maybe there are more people looking for work right now. That's not a particularly good sign. Either the benefits to job swapping are too great to ignore, or there are too many failed startups, and companies failing to retain their staff.

Edit: Or it could be that "school's out for summer", and there are a fresh new batch of grads, masters grads and PhD's on the market.


Well, don't forget that all of us are just not interviewing to get jobs, but interviewing people to bring into our companies. It's important to get right, and passion about the topic is encouraging, don't you think?


For which kind of position one gets asked markov chains, primal-dual and alike math things in the programming interview?


"I was asked to code a singleton" This interview is over!


require 'singleton'; class Foo; include Singleton; end

Can I have money now?


Also, could you do a loop with an off-by-one bug, please?


Very cool! I suffer from the same problem :(

I had an interview with a small startup I adore and had to code a simple python scrapper with the startup's CEO. I was so freaked out I totally bungled it up. Needless to say, my confidence went down the toilet.

I think I should accept that I don't do the traditional tech interview well. Next time, I find myself in such a situation, I'll suggest the short contract or coding exercise.


There is a large research base on how companies can hire to gain the best workers. The smart thing to do is ask job candidates to go through a work-sample test. An additional thing to do (which involves some special legal steps in the United States, but can be done routinely in other countries) is to give each job candidate an IQ test. Evidence to back up these statements can be found in a FAQ

https://news.ycombinator.com/item?id=5227923

I've posted here on HN from time to time, which I expect to add to my personal website in a while. A job candidate who doesn't want to do a work-sample test is a job candidate who doesn't want to work for a smart employer.


When I started my career I was in the UK civil service. One of the best things I took from that experience was the formal training they gave me in interviewing.

The UK civil service used interview boards consisting of a manager of the role, a subject matter expert and an independent person from outside the organisation. It is an inherently high-stress situation for the candidate due to the numbers involved and and usually due to the room layout.

I was trained to account for the stress reactions and see past a freeze due to the situation and focus on clear demonstrations of skill and experience. If anything we were trained to try to make the candidates perform at their best in the board rather than probe to see their worst sides.

It was complicated by the fact I was employed in a highly technical specialist team (It was a military research agency) and few people we interviewed had any experience of what we were planning to employ them for.

We also consciously went beyond a general knowledge test and focused on how the candidate thought about answering questions rather than if they knew every technical detail. In that role technical detail was only a man page or a conversation with a colleague away if you know what you didn't know and were prepared to ask for help.

Any interview that stresses the candidate, quizzes the candidates memory of detailed technical facts and doesn't work from the premise that it is a high stress artificial situation is not going to provide a valuable outcome for anyone involved.

Edit: My best question to identify general technical competence starts with "Can you describe the TCP handshake?" and if they know is quickly followed up with "Why is it like that?". Unless there is role specific reasons to know TCP then it doesn't really matter if they don't know, if they do know I am really interested in their answer to why it is the way it is. Many even quite senior candidates have never considered it before and watching their process of thinking about it is very instructive about their ability to think about technical details in the abstract.


Thanks for writing that! I hadn't realized it before, but after reading your comment it seems obvious to me that an interviewing process should be designed like this:

a) Acknowledge and minimize the unavoidable stress of the situation.

b) Use more general questions where candidates can choose their preferred approach.

c) Allow them to show their strengths instead of seeking out weaknesses.


i remember getting rejected at the screening stage because i was not able to explain how an sql index works (i'm not a database guy although many people would think this is general knowledge). The next job i got was to build an r-tree for goespatial querying purposes into a database engine. i knew exactly what r-trees and b-trees were, i was exceptionally good with algorithms, but i had no idea what an sql index was. for me it was very ironic and i had since refused to go through tech interviews.


We have seen this situation crop up with employers who refuse to do try outs. these great devs then get picked up by employers who try devs out PS I work for GroupTalent so I am biased


Can we please put the name of the author in the title of Medium posts? Ike Ellis: I will not do your tech interview


This is interesting and made me think--apologies for being OT.

You request this because you can't tell from the URL, yes? Do you have some authors you'd have a greater desire to read?

I just got my invite to Medium and on some research saw where a notable dev (who's name slips my mind) was moving off then platform for a few reasons and I believe the URLs was one of them.

Now seeing your request I am thinking this is an interesting situation where it sort of levels the playing field (or could cheapen the experience) since you don't know who you're going to read based on the Medium URL.


Love this article, but am I the only one wondering why this fellow is interviewing so much if he's already been hired in a number of situations? Are the companies he's working for going bust, laying him off, firing him, or he's quitting? I'd think that if interviewing is his fear, he should do less of it and find a great employer and stay there?

It sounds like contracting might be what the OP wants to do more than employment if he's so good at selling that and not interviewing, but also not keeping those jobs long enough.

Or maybe I misread it? Sounded like he was hired a number of times for jobs, but went back to interviewing not long after anyways.


Some very opinionated people in this thread. My two cents...

I've had similar experiences to the guy who wrote the article. Something about interviews seems to make my heart race and I can stumble on very simple code. This is in strong contrast to how I am in normal social situations where I am highly confident and my personality is often infectious and passionate. I think it's a case of high anxiety in authoritarian/test conditions. Those that imply their working conditions are similar to interview conditions make a good point, however if that is the case I would prefer somewhere less confrontational and more forgiving.

Generally I prefer proper timed tests [0] without anybody watching. This is how I normally work.

I'm also one of those people that has to constantly look things up; actually I have a broad range of experience but I often find myself delving deeply into things I have only cursory knowledge in - imagine a librarian that remembers the locations of the books in a library and the analogy to knowing high-level concepts that allow thinking on your feet when used together with the correct reference materials.

Of course I believe that it's better to be good at making do with limited information. Understanding things from scratch is what I have been doing all my life. Like a chameleon when I look at some code that I did not write, it becomes my syntax and I quickly understand the contents. However different organisations and cultures sometimes prefer different kinds of engineers: there is either a preference towards robustness or flexibility [1].

[0] http://codility.com

[1] A test I would excel on would be being passed code in an unfamiliar language, domain, library or ecosystem and being told to quickly get to grips with it and add features/fixes (aka. flexible knowledge: unfamiliar territory which requires me to pull together a broad range of skills.) This is opposed to being passed a piece of code in a familiar language, domain, library and ecosystem and being told to quickly and robustly add a feature or fix to it (aka. robust knowledge: familiar territory which requires only a very specific set of skills.)


On-site interviews are a necessary for the most part, but phone screens have always been the bane of my existence. About 50% of the time I can barely understand what the other person is saying, mostly because the person conducting the interviewer is not a native English speaker. I almost never have an issue in person with non-native English speakers because you're able to pick up so much more context from subtle physical clues. I wonder if anyone else has this problem.

Disclaimer: My parents are non-native English speakers and I can't understand a thing they say over the phone, but in person I have no trouble.


I should do the same. I am not native speaker and everytime I start a phone interview I feel like I'm already 10 points behind in the game we are playing.


Tangential, but you hit on a really fascinating field in psychology with your post.

We have these differences--linguistic, cultural, even physical characteristics--that are huge. The differences that highlight a lack of shared background/experiences/origin/etc. can be found not only to be at play between, say, native and non-native speakers of a language but even separate groups within the same culture. You see that in how we handle subjective feelings of personal space, for instance --we Americans, for instance, tend to prefer greater personal space over say Scandinavian or certain East Asian cultures. But the fascinating thing is how those expectations can shift based on region, and on an even more micro level, affluence etc.

Even when the differences are minor, such as say race and skin color, the effects can be profound. If you look into what's called the cross-race effect, you'll find a tendency to have difficulty processing faces of members of other groups. If you've ever heard anyone say "all Asians look alike" or the similar "all Westerners look alike", this effect is what's behind that sentiment. And it's universal: this processing difficulty isn't limited to any particular ethnic group. Cross-racial identification statistics for eyewitnesses prove all too well just how troubling this can be even amongst ethnic groups that are otherwise readily familiar (i.e. whites identifying blacks and vice versa). But what a lot of the current literature shows is that the rate of difficulty can decrease with familiarity that shapes how we code faces and integrate them into

Anyhow, as far as communication is concerned, it's not just verbal. On the contrary, most of our cues are distinctly non-verbal: body language, gestures, expressions, prosody, paralanguage, and a lot more. People toss around Albert Mehrabian's "93%" number a lot without considering its context (namely, his work was limited to the communication of feelings and attitudes), but the broader point is that these cues serve as a means of helping to imply meaning to the words they accompany.

Now, where the really fun stuff begins is when you start to consider the universality of some of these nonverbal cues. Particularly with the face with microexpressions: involuntary expressions lasting only a tiny fraction of a second that correspond to six basic emotions. Contrary to the idea that expressions and meaning were culturally determinate, the research is fairly overwhelming that despite differences in culture, language, and even physical face characteristics, microexpressions and the emotions represented are consistent. Rules governing those emotions are be culturally specific, but how they're expressed and the emotions themselves aren't. Back in '71, Ekman went to the Papua New Guinea to show this with the Fore people even though they had almost no direct contact with the outside world up until the fifties, and at the time Ekman went, had no access to Western media or entertainment that might have given the Fore the experience with outsiders and their facial expressions.

Related to your post, however, are the findings that show we're able to recognize these expressions by people outside our own ethnic groups. In a sense, not only are the emotions and expressions universal but so too are our ability to recognize them. Biologically determined, hardwired. So talking in person, rather than on the phone, can make all the difference in the world.

If you're curious, I'd recommend taking a look at a reprint of Ekman's Unmasking the Face and Darwin and Facial Expression: A Century of Research in Review if you're curious about some of the historical origins of the work. The latter, in particular, is truly fascinating.


My current job hired me roughly the same way - short, informal with a very basic coding test just to make sure I wasn't bullshitting. Then I was given a couple of weeks to recreate a game they'd recently finished - didn't have to be perfect, just a prototype and an example of the kind of code style I write. Got paid to do it, spent a couple of hours at home a night working on it, came back in to present it, and voila, job offer. So far it's worked out great!


I've been a developer for 8 years. I have a good job already. When I get an email from a google recruiter, I usually think this:

My free time is very limited and valuable. Google sounds interesting, but here are my options:

a) Spend my free time exploring and building small projects with new technologies and techniques. Maybe work on a mobile app that could make some money.

b) Find my old CS textbook and notes and do algorithm studying and exercises just to prepare for an interview.

Doing a) directly improves my skills and has lots of benefits. I've been able to improve projects and gain a lot of good reputation at work because of things I discovered doing a). a) could also lead to making a revenue-generating mobile app. And perhaps most important of all, a) is FUN.

Doing b) just feels like a giant waste of time. Doing b) is a direct opportunity cost of not doing a). The potential return for b) is what? Going through a day long interview with judgmental engineers trying to look smart? And it's boring. It was fun learning in college when it was the first time and I had that aha moment of understanding. Now its just boring to go over it again and again just to rote memorize things. I would rather be building or learning something new.


This sort of reminded me of the old adage about people who "aren't good at tests." "Oh, I see. You're not dumb, you're just not very good at the part where we find out what you know." Software development is already full of anti-social and/or introverted people. I know, I'm one of them. If you're tipping off my "too much anxiety" scale then you're really up there.


The smartest hacker I know was approached by Google, apparently they found that he was working on some interesting stuff on LinkedIn. They asked him if he'd come in for an interivew and he told them "I'm not going to do an interview for you guys. You can either hire me based on my previous experience and sample work, or I'm not interested."

A week or two goes by, and they hired him without doing an interview.

On a separate note, I've always had the test anxiety problem so I could understand how an interview is more of an acquired skill and less of an indication of your coding ability. I can code, and I have no problem with understanding the material, but when it comes to taking a timed test and using a pencil and paper for something that I usually use a completely different input for (a keyboard and a monitor), I struggle with it. Some people dismiss it and say "well you obviously didn't know the material if you couldn't get it on a test," but I never agreed with that.


All else being equal, I'd still rather hire the person that doesn't panic. I think it's entirely fair to subject a potential hire, especially for an important position, to a certain amount of stress.

Most people I know, myself included, have suffered from anxiety or panic attacks at some point in their lives. It's usually possible to overcome this, though. When you realize that you don't interview well, are afraid to speak in public, freeze up on dates, are afraid to speak to clients, panic when your boss disagrees with you, etc., you can either work on it or try to avoid those situations forever. Frankly, I'd rather not hire somebody who convinced themselves that they have to avoid certain situations because they can't handle them.

I do love the contractor idea, though. Perhaps it would be best to hire somebody as a contractor for a small project and then have them present in front of the entire team and ask specific questions or ask for live modifications?


quit giving away my hiring secrets!

the brainteaser-whiteboard-fizz-buzz-5-member-panel interview is, and has always been, highly unreliable, if only for the sole reason that PEOPLE GET NERVOUS. gee whiz, what a concept. back here on earth us mere mortals have to deal with things like nervousness, forgetfulness, and intimidation on a regular basis.

let's not forget sociopaths or assholes in a bad mood who deliberately try to make people feel nervous. they exist. that's a thing. i've seen it with my own eyes.

it is an unreasonably strict high-pass filter that gives false negatives people who are otherwise perfectly valid for developer jobs. that's great if you've got millions or billions in the bank and have carnegie mellon grads lined up out the door. that's awful if you've got $50k in the bank and you need someone competent working on things yesterday.

SO much value can be won by hiring people who can't or won't deal with this kind of scenario. on both sides of the table.


Where I work, an interview is a full day thing. I'm pretty happy with how it works:

After going through an initial resume screening and phone call, you show up on-site in the morning.

You then give a presentation about some recent work you've done. For those fresh out of school, it's generally about their grad work.

Then you have a series of 1/2 to 1 hour interviews through the day, mostly with people who were at your talk that morning.

The individual interviews tend not to be the Google-style "please implement a data structure for XYZ on the board" sort of thing. Rather, we'll ask about things from your talk or your resume that interest us. We might describe some work we've done here, to hear what you think about the problem, how you might have solved it.

A lot of what we're looking for is how well you're able to communicate your responses. We also want to get a feel for personality, how well you work with others and how well your personality will interact with the people here. I believe this place is actually pretty diverse, and I like to think we don't fall into the "culture fit = 20-something white male" trap; however, some of the restrictions and circumstances of the work we do may make some people unhappy and we'd like to avoid that.

We also pick two people to take the candidate to lunch. This is supposed to be a chance to talk more about life in the area and what it's like to work here, although honestly a lot of that comes up during the regular interviews.

After all the interviews are done and the candidate leaves, the interviewers get together, share their impressions, and say whether or not they recommend hiring. The hiring manager then makes the final call.

It's not really suitable to everywhere, I'm sure, but I'm pretty happy with it.


Where do you work, if you don't mind me asking? This sounds a lot like the interview process for research/academic positions; if you've made it to the interview day, there is really no reason to doubt your technical skills anymore, and the interview becomes more about finding out whether you would find your place and collaborators to work with.


It's for research, specifically at an FFRDC. I don't believe there's any sort of "establish your technical skills" portion. My hiring process was a bit unique because I had already worked as an intern for 3 years, but as I understand it the usual process is 1) hiring manager finds the best resumes, 2) hiring manager does a phone interview with those people, and 3) hiring manager invites a few of the best prospects out.

The real technical skills part is the presentation. If you can give a good, 40 minute talk about what you've been working on, you've already put yourself in a good place.


Sounds like a gigantic waste of time if you're applying somewhere other than Google, Facebook, or any of the "Big Tech Firms".


Well sure, smaller places might not even be able to muster enough people to do that many interviews. It ends up taking about as long as a Google interview, but it's not just debugging assembly on a whiteboard. We tour you around the site, talk about what you'd be able to work on, etc. The interviewers are selected from several different but related groups so you hear about a lot of different work going on.

One of the facts of research life is that you'll spend a good chunk of time talking to people and presenting your work--it's the price you pay for being able to choose what you work on. This interview process seems to help select for people who work well in that environment.


I've always been great at interviews. I'm naturally outgoing, love to talk tech, and really try to show, rather than tell, why I'm a good fit for any particular team or project. That said, I hate traditional interviews. I hate begging for a job, and I hate having to kiss ass to some manager who has no technical competence. I have been fortunate in that I've landed three awesome jobs so far in my life. Two were short-term gigs but one of those gigs helped me network and was a huge factor in my landing my current position. All three of these jobs involved me saying "Hey, show me a problem and let me see if I can fix it for you." I don't believe in performing gymnastics for someone like a monkey, because I'm not looking for a spot in a zoo or a carnival. I like solving problems and I like helping other people solve there problems. So I agree 100% with this sentiment.


Couldnt have said it better myself.


this is a very good idea.

i've had multiple interviews where i did well on the phone and the tech-out, only to receive a "take home exercise".. with guidelines such as "it will be graded by style and architecture in addition to correctness of function".

This would mean half of my saturday in a coffee shop coding an elaborate solution using latest technology and good patterns.. with some resentment because i just wasted hours of precious (and scarce) free time.

Not only has this never lead to an offer, but in some cases i'd not hear back for weeks, with eventual vague comment like "it was good, but not great" or "it was great, but we decided to go with someone who happened to have more experience in X domain".. that's nice..


Same thing.

I got an open ended problem that would take a measure of forever to solve: Specifically to write a program (in your favorite language!) that would do natural language processing and discern emotions and feelings about subjects from text. We were supposed to include our own lexical parser.

The author's strategy scales poorly with complex and interlocking problems. Where it is more important to show potential ability to solve the problem (puzzles), holistic understanding (talkin' about it), or prioir experience (specific questions about libraries).

This guy should address his core problem (stage anxiety?) instead of advocating a solution that is only tenable in a limited number of cases and represents far too much commitment from the participants.


> I got an open ended problem that would take a measure of forever to solve: Specifically to write a program (in your favorite language!) that would do natural language processing and discern emotions and feelings about subjects from text. We were supposed to include our own lexical parser.

I know of a YC alumni company that asks for a weekend project on roughly that level and when rejected candidates ask if they can upload their work to Github, the company declines because they'd "like to keep an even playing field for future candidates."

Then you're left with choosing between having an awesome project you can't show off and being an inconsiderate jerk who uploaded code despite being asked not to.

Doesn't really make one enthusiastic for the next time you're asked to do an "exercise" or a "project."


I agree with that sentiment, I don't do well under the pressure of someone leering over me as nice and comfortable as they make it. Sounds like a good startup idea. Someone (maybe I will) make a site that formalizes the contract work concept. Instead of setting up and doing a project for someone, maybe a pair programming exercise on the fly over some days that neither the interviewer or interviewee is prepared for? 'Program Tic-Tac-Toe in x language', 'find the minimum value of this array given these properties of the array'. Could make it fun. Almost like a mini-mini hackathon. I'd much rather do that for 4 hours than random probes of knowledge from 4 people over almost pure academia.


Counterpoint:

This is a recipe for only finding unemployed people, and in my opinion, the best people already have jobs.

I have been offered to interview with YC startups that wanted me to fly out, spend a week writing code with them, and _then_ they'd offer me a job. I'm already employed, by an employer that legally owns all my code. I can't take a week off, write your code, and then _possibly_ get an offer. I don't have time for that.

Technical interviews can go afoul, yes. But, IMHO, they are the best we've got. They show respect for the interviewees time, and decisions should be made quickly. Will you occasionally miss a good candidate, yes. Will a bad one get through, less likely. That's about the best one can hope for.


Ideally the time you spend writing code is both compensated and under a Work For Hire of the company trying you out. Your current employer owns the IP of whatever you do during work ours and using their equipment not what you do on your own time.


Not at Google.


At least in California, employers are statutorily prohibited from claiming rights to IP that was created on the employee's own time and using the employee's own equipment, and agreements that purport to waive this prohibition are void.

(CA Labor Code 2870-2872; http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&gr...)


Great. CA law doesn't apply in Massachusetts.


This is how Automattic / WordPress.com has done interviews for 5 years now. There are some tweaks to do it well that we've learned over time, but there is nothing like seeing someone's actual work to see how they're actually going to work.


Every job I actually got was because a friend made sure that it happened.

I like this approach. In fact, something similar has happened to me in several of my job acquisitions. Networking trumps pretty much anything else.


I've noticed that when doing interviews with younger developers, you run into the problem of "They only know about the projects that they've worked on at fill-in-school" and they have no real world experience to base an interview on. I've even experienced this with interviewees that at companies I've worked for. I'm definitely a proponent of contract-to-hire because you can figure out if you really gel with the team. Plus there may be some things that the interviewee never thought of that you're really good at.


Maybe I'm the only one here, but I actually like technical interviews. Granted, I've done a handful of terrible interviews (either because of the questions or because the interviewers weren't prepared), but I think good tech interviews are very productive. I've been on both sides of the table: from the interviewee's side, a good interview allows you to show off your strengths and show the team how you work; from the employer's side, it's important to get inside the candidate's head and see exactly how they work and how the solve problems.

Now, a good interview isn't one where you ask question about the technical details of a language or a framework or how HTTP works or anything like that. Sure, good technical knowledge is necessary for most positions, especially senior ones, but information is really easy to pick up as you go, whereas real talent is not. Good interviews ask more broad, open-ended questions. "If you wanted to build X, how would you build it?" "If your app was really slow, where would you look to fix it?" "What do you think about framework/language/tool X in relation to tool Y?" Etc, etc. These kinds of questions let you really get into the candidate's head and figure out if he's a good fit, while still allowing him room to go in a different direction and play to his own strengths.


I too think something has gone horribly wrong with the "modern tech interview" especially in a large corporation. It feels like a Frankensteinian experiment gone horribly wrong relative to real world results-oriented development. If the actual job was like the "tech interview", and the actual corporation run like the "tech interview" process I would leave screaming inside of a week ;)

Practice can work against you. In one case I was worried about the algorithm and data structures side of things based on glassdoor posts. Spent a week of evenings coding algorithmic whizbangery. In the interview I obsessed on getting every line of from-scratch code right (obsessively focused is often how I code real software) and stopped "listening" to what was being asked. Double whammy was the interviewer was actually not very familiar with the solution to the problem (canned and complex do not mix well) and when I confidently but politely corrected him as we were coding, boy the color of the interview changed fast and game over. My bad, In the real world I'd politely correct a coworker too.

Or maybe what you should practice is writing out JavaScript with pen and paper like another interview. I hadn't written code out by hand for 15 years .. like since the invention of the keyboard. I did a terrible job despite having just completed a non-trivial very modern mobile front end project. Ri-donk-u-lous.

Be yourself, stay balanced, do your best, HR science is evolving too.


Technical job interviews as traditionally run in silicon valley culture are completely bogus. Many different better ways exist, one of which is the short-term contract work (with an eye towards full time hire). For my company, pretty early in my first conversation with a potential hire, I tell them that the hiring process will never involve having to write code on a whiteboard. I intend to keep it that way whether I'm the CEO of my startup or just a lowly interviewer drone in a big corp from now on.


I'm a big fan of what GroupTalent is doing - I am finding exceptional candidates through them.

One of their main features is contract to hire. I find many great candidates through them where I work.


The reason the san fran interview tends to focus on theoretical cs more so than other regions is because the plethora of berkeley and stanford grads in the area, who subconsciously prop the entirety of their ego on their college educations, and thus use it as a measuring stick for others, sometimes at the cost of a good, practical hire. I've seen job descriptions for FRONT END positions which list a cs degree as a 'must,' which is just absurd in today's day and age.


As an interviewer, my impression is that interview performance often does not predict success in the workplace. The most extreme example is for a case where the person aced (I mean absolutely aced) the algorithm questions I threw at him but was unable to get things done at work. In technology, we don't have a good way to filter by personality and conscientiousness - these unfortunately turn out to be pretty key in getting things done well.


> I politely suggest that a short contract job might be the best option for a company to evaluate a senior developer.

This article reeks of privilege, namely that of location.

The suggested is horrendously unfair to people that would need to relocate (possibly even internationally) to get a job.

I am currently interviewing for a large tech. company in Silicon Valley. I am living in England. It would take a substantial amount of resources for me to even meet the team in person, so of course they want to vet me via Skype or whatever before they commit to this. On the flip-side, if I'm going to be uprooting my entire life and moving to SF, I want some sort of guarantee I have a solid, full-time position.

I also wouldn't be able to afford a £1,000+ flight (and countless days of missed work) in order to do an on-site interview. Utterly preposterous.

Thankfully, the person doing the technical interviews has been a person who basically has the same job as me, so they understand the position and can see if I'm a good fit. The interviews were of the format that they pasted into some questions to a collaborative editor, I get to choose a language, and solve them. We are Skyping so I explain the reasoning behind what I'm doing etc. Code doesn't have to compile, I don't have to know the exact syntax for function calls (because who can't find that in seconds anyway), but it's about figuring out my though processes, confidence, ability to deal with new things, etc.

It'll be interesting to see what they think of me, but it seems like a reasonable process, and does not exclude people based internationally.


The contract work could be done off-site.


Not necessarily - for instance there may be requirements for physical access, data protection, actually working in the same office as a team member, etc.


I won't do tech interviews either, but not because I think I will fail at them. I think they are completely bogus and give totally the wrong signal. It's a waste of my time AND the company's time. I wrote up my thoughts on this exact thing a few months back: http://blog.getify.com/technical-interviews-suck/

TL;DR: Everything you need to know about if I'm a good fit is available online in my OSS (et al) track-records. If that's not good enough for you, that's not the kind of job I want anyway. I want to work for companies that value the full lifecycle of OSS work, which you can only see in such a way, and CANNOT judge via tech interviews.

By the time I walk in the door for an in-person interview, I expect you to already know that I am fully qualified (tech and otherwise), and you're looking now to judge my cultural fit by sitting me down in a real team meeting and seeing how it works, etc.

If I show up and you try to quiz my tech skills, you didn't do your homework on me, and I have no more time for you, so I'll just chuckle and walk out. Politely of course.


I'll probably take some crap for this but I go on gut instinct a lot. I've got a guy working for me who is awesome, we got on the phone in the interview process and 30 seconds into it I was saying "You're hired, I want to work with you". My COO overheard that and was running at me waving his hands no-no-no.

That was 2004 or 2005. He's still here. Great hire.

Sometimes you can just tell right away.

All that rambling aside, I'm with the people who dislike the techy interviews. I was #4 at Google and I don't think there is a chance in hell that I could pass their interview questions today. But I've done good work, created good stuff, they ping me from time to time to come back. So perhaps I should be hired but I wouldn't pass the interview process so far as I can tell.

What's wrong with the contract idea in the original article? As a manager, I love the idea of someone who is willing to demonstrate their skills in a contract. If I were out looking for a job I'd offer that up, it's try before you buy, what's the downside?

Can other managers tell me what is wrong with that approach?


I'm a big fan of this approach, and I've used it successfully when hiring at startups. But it hasn't seemed to fit in well with the hiring culture at large companies. We can't use someone's time for free, and initiating a contracting relationship is mired in red tape, so isn't really worthwhile for a small-scale project of the sort that's appropriate in this context. And asking someone to spend a couple days working on something that is going to be thrown away seems demoralizing and possibly counter-productive, since the fact that it's "just a toy" will doubtless impact the approach the interviewee takes to the problem.

Plus, in a large company, internal transfers are common. The social dynamic of asking for an employee who works elsewhere in the same company to do work for a different part of the company seems awkward.

Does anyone have any success (or failure) stories about trying to make this sort of approach work in a large company?


Being good at tech interview is an art, that few masters, and many are good at while being poor developers. I have countless tales of wow-thumbs-up-interview guys that turn out to be just good at that: interviews. Also, very anecdotal, but my best hires in 15 years have been poor interview performers.

So what's the answer? no, not contract to hire. Although good in theory, in practice many companies won't support or approve contract to hire for full time position. Call it HR inertia, a.k.a 1 of the 4 horsemen of death in bigger more established tech businesses.

So where am i going with all this? Well, that's why networking is important. Get the people you worked with to bring you in places. You don't have to impress anyone on a white board (who codes on whiteboards anyway) but put the emphasis on culture fit since you already pretty much have been tech screened by your old pals.

In conclusion, be nice to your peers. Especially the smart ones you work well with.


This is interesting and I like the small contract up front, I've done that myself, but I would say that performance anxiety is real and can be treated using not just medications but training your brain to recognize and work through it. My entire career I've been plagued with anxiety issues and have worked through them with help from doctors, reading a lot on the topic, and talking with others that have similar issues. There was a time when I would freeze up just talking one on one with someone. Now I'm capable of giving presentations to rooms full of executives. It is a never ending struggle and I still get nervous. But I can't let it spiral out of control to a anxiety feedback-loop.

My point? Don't just ignore the problem of anxiety when it cripples your life. Address it head on and try to work through it. It will help your life greatly if you can.


"I finally stumbled upon the cure when I interviewed at a small startup that had a different approach. I met the leads for lunch, then followed up with a social chat with the whole team. We talked tech, but they didn’t try and vet my skills."

Meeting potential employers outside the office like this (over lunch or coffee) has been so much more effective for me as well. It takes the pressure off on both sides and lets everyone really get to know each other. If you can't sit down with someone over coffee or lunch, how are you going to work with them?

We're gathering companies who are interested in this approach to hiring (and trying to make it a trend). Employees at the companies offer coffee meetings (their treat) that anyone interested in the company can request. If there's mutual interest, they meet for coffee to chat about the company.

www.treatin.gs


In our company we understand that testing up-front can be off-putting, but we rather pass up a great candidate than hiring a poor one (we do subscribe to Polsky view on candidates http://www.joelonsoftware.com/articles/GuerrillaInterviewing...). We allow them to test at their pace (codility.com) from home first, then we re-test them on-site (to avoid the 'someone doing my homework' effect). After that the next interview is pretty much talking on the code written code and approaches or decisions that the candidate took. So in that sense is a great piece to further discussion.

The issue is that where I work we can't subcontract as a way to 'test' for candidates. The code is so proprietary, and have so much red tape (Options Trading platform) that we don't trust anyone unless you are full-time. Also, the code is fairly complex and embedded in it's industry-speak that unless you come from the same industry subset, you will not be productive (like knowing what Black-scholes, instrument, or delta means). So the investment to getting any good developer to be able to produce is immense. We considered subcontracting for assessing a candidate, but it is fairly hard.

Also we have seen people that do extremely well on every other aspect of the interview but can't deliver when asked to write a piece of code. Good or bad it does show your ability to work under pressure (I am not sure if it's extreme in the financial industry, but stress levels here run fairly high... for a fun read http://codesnipers.com/?q=interview-the-wall-street-programm...). So when you're getting your coffee, someone comes and says 'we need to fix this' it will probably be as intimidating (or more) as having a code interview.

Lastly, maybe because we've seen it often enough, there are a ton of programmers that can't write code (yes, the fizzbuzz crew). Having the codility test filter in front of all eliminates a lot of that chaff we see, so we don't even bother with the candidates unless they get a good-enough result in codility (we do look at the code, not just if it passes/fails the unit tests, but we don't bring the candidate for an actual interview until we have a reasonable expectation that they can program). We understand we will miss Ike Ellis, and we accept that as part of the tradeoffs between time and opportunities.


I've never liked the tech interview format. Throughout my career I've run four different companies, all small, all resource constrained, so I never had the luxury of competing for the A+ talent.

I ask people for a list of projects that they designed and coded (live projects, so I can see how they function), to get a sense for how good they are overall, then will look at the underlying code. I value readability and documentation over fancy tricks meant to show off the author's MENSA status.

When it comes to the interview, that's all about assessing their personality, work habits, and broader interests. Friendly personality, good work ethic and broader interests = someone who is flexible, which is vital in a small company where everyone has to do a bit of everything.


Perhaps it's already been mentioned, but GroupTalent [1] has set up a business to offer this type of 'small project as an interview,' or what they call "Date a Company" to help guide primarily freelancers to full-time employment:

They did a pivot after acquiring Kyle's TinyProj [2] customer base, which included us. Wondering if anyone has any good experience with GroupTalent?

[1] https://grouptalent.com/welcome/ [2] http://techcrunch.com/2012/01/16/tinyproj-shuts-down-users-s...


Hi this is Manny, CEO of GroupTalent. I wanted to add context to the pivot comment. More than a pivot, we expanded our offerings to include try outs and full time opportunities. It turns out that there is demand for all, and someone may do freelancing for a while until they find the right fit. We strive to provide all the options for the entire career life-cycle. We still connect developers with contracts and short term projects - however we see the majority of the demand on both ends for try outs at the moment


Rule of Thumb, which might apply or not (;-D): People who think they are good usually aren't!

There are many reasons why people would come to you to ask for help or why you are more successful then colleagues. E.g. in my company we have a guy who thinks of himself as a web developer but thinks that CGI is the protocol the browser talks to the web server. It is not hard to be the best in such an environment. Don't compare yourself inside your company! Compare yourself to the rest of the world! Look on GitHub, read blogs, talk with people on software development mailing lists. If you still feel stronger than most people around you, you probably are.


I always walk in with this in mind: "Let's see if I want to work here". At the point where I'm really convinced and want to work there I get a little nervous ;)

I also insist on doing some work there, to prove myself of course and see how things work. how they are organized, tools and frameworks they use etc. And most important to get a feeling about the people there. I know it's hard in just one day but you get an impression. I left my last job because I wasn't feeling good there. No team spirit and a "cold" atmosphere. Why should I spend 8-9 hours a day at a place like that?


If you think interview is really a measurement of one's professional ability, then like any measurement, it has measurement errors. To me, it seems that this person has some sort of interview anxiety because of previous bad interview experiences.. So the anxiety kind of feeds back onto itself. In this case, the interview can't really measure his ability accurately. But this brings another question... How valid and reliable are those interviews? I really have no idea about that since I have never had a tech interview. Just a question to think about when it comes to evaluating a measurement


This piece mirrors my thoughts on tech interviews as well. Firing brain teasers at somebody under the pressure of a job interview environment gives very little indication of how the candidate will actually perform their day-to-day job duties. I've long thought that the short-term contract method was far superior. This is especially relevant in light of yesterday's post about the "Wretched Google Interview" (https://news.ycombinator.com/item?id=6243627).


> I politely suggest that a short contract job might be the best option for a company to evaluate a senior developer

Nice idea. Though I hope you don't expect to be given high priority stuff or be paid a full senior dev's wage during this short contract before which I don't know your abilities as I've not had some other chance to assess them.

Of course an active public portfolio helps here, as potential employers can get some idea of your output from that, but we can't truly rely on it as it can be faked (or be misleading for far more equitable reasons).


>Nice idea. Though I hope you don't expect to be given high priority stuff or be paid a full senior dev's wage during this short contract before which I don't know your abilities as I've not had some other chance to assess them.

The nature of the work isn't that important. However, asking someone to take a low-ball contract is a great way to filter talent. People who are good, or busy, will completely turn you down. People who are desperate or suck will gladly take the money.

This contract test should be last one you do. It should be either the full day on-site or the short contract. You also need to pay market rate if you hope to hire market rate talent.


>People who are good, or busy, will completely turn you down.

>People who are desperate or suck will gladly take the money.

I don't see that as a universal truth at all. Many decent people are out of work for various reasons (start-up just gone under, contract ended and haven't found the next one yet, just back in the market after illness or similar, new to the area, or like the post that started this discussion: they just don't interview well despite their technical skills+experience) and some of them are desperate for new work. Not everyone, even amongst the best people, are sat on enough of a nest egg that they can turn work down willy-nilly.

People who are busy won't be applying in the first place, or will take the technical interview option (which is presumably less difficult to schedule the time for) if offered instead.

> You also need to pay market rate if you hope to hire market rate talent.

For the job yes, of course. For the interview, which this short contract is taking the place of? I don't think so. You can't be too cheap of course, as that will make people doubt the salary range being quoted for the real job/contract.

Of course if a company were to try use this as a way to get quick short-term resource in cheaply, with little or no intention to take people on for longer contracts, their reputation for it would circulate PDQ and people would stop applying at all (unless really desperate).


Reading through here and seeing how many people are saying "You don't know x? You're an idiot, you're out!" makes me feel glad that I was able to get a job at all. Apparently I don't know any of the 'easy' questions so I must not know anything.

It definitely doesn't help with my confidence going into an interview and not knowing if I admit I am not an encyclopedia is going to get me disqualified right then and there.

I am sure that it has to do with the jobs and the locations and the companies but definitely freaks me out about my future.


As you had alluded references (and professional reputation) is the single biggest predictor of success. This is why resumes tossed over the transom to companies is such an inefficient process.

2nd to references is looking at real work products. You're in advertising? Show me your ads. You build websites, show me your websites.

Your method of short term contracts is a good way to get to both at the same point.

Any thoughts on recruiting college hires? They don't have work products, and in many cases don't know enough to be useful on a project with low guidance.


To go on a tangent, the OP mentions once being asked for his favorite video games...if I'm ever in a interviewer role -- and the candidate mentions in passing that he plays video games as one of his interests -- I think that'd be a great expository question.

For instance, a gamer who enjoys TF2 or better yet, Left4Dead...that's a partial sign that they enjoy teamwork, despite the downsides of dealing with weak-links and griefers. Someone who enjoys only Halo deathmatch...well, hopefully their skills match their bravado ;)


well you better have something to show then such as a public github repo.


Pass. I spend enough time at the office writing code that I can't show to the world because my employer owns it. I don't need to justify my six figure salary to my next employer by writing even more code on my off time just to prove I can write said code.


Well then how am I going to figure out whether or not you can code? The only thing I can think of is an expensive two week trial period which doesn't make sense since I feel that most programmers will either submit work or submit to a pop quiz.


> Well then how am I going to figure out whether or not you can code?

Provide the candidate with a PC representative of what you'd give to him/her during the course of his/her's employment and assign an ~one-hour-long programming assignment to complete while you sit nearby.

If the candidate needs a particular program (e.g., "I don't like Vim. I prefer to write my code in VILE!"), then give it to 'em.


This is still another variant of the pop quiz... but a better one.


Good developers cost, what, $120K-150K/year?

If a two week trial period is "expensive" to you, you don't have the budget for someone in that pay range.


It's expensive in other ways though.

A programmers who is currently employed but thinking about moving on probably won't agree to a two-week trial period because of the substantial risk that they get rejected afterwards and end up unemployed. That makes the trial period expensive to him. In turn, it makes it expensive to the employer as well, because you'll filter out good people.


Can they not do this two-week project after hours? Must it be in your office, on your schedule? Where you code, the hours you code, these do not matter. The code is what matters.


Sure, but now it's not going to get full time dedication, maybe half that if you're lucky. So it's more like four weeks. And maybe they don't even have that much free time, so it's even longer.


Time is an expensive resource for even teams in large corporations. Most often you'll be spending a week or two going over the context and rationale of existing stuff. This gets worse the larger and older the company.


You can figure out by discussing past experience, projects.


This is the easiest for people to fabricate and it makes it harder to discern good people from bad, especially when you can't actually look at the product of that experience.


I think it is quite easy to get to the level of discussions where one needs to be very smart to fabricate...

As for coding during the interview, I can't concentrate (get in the "zone") even when my wife watches me behind. So it is not about the stress, but the way how a programmer works.


It's funny, I have a very well developed github account and a couple of public web application side projects. I'm always curious where employers think that code came from when they reject me for not being able to do fizzbuzz on a white board in front of 5 people.


Your example shows that even within IT there are segments of people. There are people who are algorithm/book smart. They can code fizzbuzz, b-trees, etc... all day long on the white board. But those same people may not be able to ship something. There are other people who don't even care what a b-tree is until they come across some problem they are researching on SO because their shipped app is broken.

Each of those people are important to have depending on the companies situation and that's why no one interview process works for all programming positions.


A good github repo does go a long way. I have one project I did as an interview 'test' that I leave up there simply because it shows my thought process etc. It was not a proprietary thing so no sensitive information is in it.


If this approach became popular enough, it seems like this method could be easily gamed via outsourcing.


Good point but it's better than nothing. Besides asking the supposed author about their work could probably uncover whether or not they actually wrote it. If they worked on a big open source project, it'll probably be less likely that they were faking.


Creative idea. Also, if you complete the assignment in your spare time, it says something about your drive/motivation and discipline. These intangibles are hard to glean in an interview.


The benefits of a tech interview is that you have an opportunity to present a challenge to the candidate that contract work may not have. I increasingly use problems I have run into myself while working on the product we are hiring for. It's good to know how a candidate will solve these critical problems, because bad solutions can be really bad for your team and product. Contract work will also eat up time just getting the dev running the development environment and leak code/product secrets.


I do most the interviewing for our tech team. I will rarely even ask a technical question. I look for passion, confidence and that they can keep a dialog on the topic of tech going. If I cannot have a conversation with someone for 30 minutes, how would I work on a project with them for months? I personally loathe logic and algorithm questions. If I ever get asked them myself on an interview I will actually ask for a different set of questions. I dont think it adds any value.


I will not hire someone without seeing them code something... period. There are too many tricksters out there. I ask them to solve Fizzbuzz using any language they want, any editor, any question, any google search (including just looking up the problem and copying and pasting), and any amount of time. They get to do it on their own at a private workstation. Still 90% fail even after completely fleecing me in the "technical conversation" portion of the interview.


We're all wired differently. Some people just naturally have more anxiety than others. I think what's needed is a proper amount of empathy for people who may not be able to hold up to the nerve racking process of an interview. Given that developers are not always the most empathic towards emotional/psychological issues, I'm glad someone has voiced this and that its getting so high on hacker news.


I couldn't agree more with this. Most technical interviews are designed to make the interviewer feel smart.

I interviewed at a company that gave a software engineer's interview for a data scientist position. Because I'd actually worked as a data scientist, my software engineering was a little crusty. I failed the puzzles, and its really frustrating that way.

I've done the 'start as a contractor' thing twice and it works.


This is sort of like an internship, but for people no longer in school. I've interned three times (finishing my third now) and I think it's a great way for you to get to know a company and for a company to get to know you. That is, of course, assuming the company has a bite sized piece of work that allows you to show if you've failed or succeeded.


I'm pretty much at the same point of refusing to do any actual coding on an interview and for pretty much the same reasons. Really like the option of an offline code test followed by discussion of the solutions or a small contract. But it's pretty rare for companies to actually do this, since nearly everyone now follows Google's model.


I've almost always done really well at technical interviews.

But I support this because a lot of technical interviews are ripoffs of people's time. I've put a lot of effort into technical presentation, done well, and then been disqualified based on other criteria. That sucks and the companies have done it that way because it's easy for them.


Did I just read that employers read potential employee's tweeter accounts? This is odd. What does that have to do with coding? I hope they meant the employee's work related tweeter account, which they got from the employee.

Anyways, the article is good, but mostly for very experienced developers who can demand certain accommodations.


I've observed that there is at least a 10x, possibly greater, difference in the caliber and culture of various organizations. So if you failed interviews at organizations A, B, and C, but are doing OK in your job at D, it doesn't imply that you would have succeeded in A, B, or C, possibly due to differences alone.


I understand the sentiment, the traditional interviewing process doesn't seem like the best way to evaluate candidates. However, the proposal breaks down for the vast majority of good hires in that it is impractical to expect someone with a full-time position to quit in order to try out for a new team.


the point of technical interviews is to see how you think about problems, getting it correct isn't even that important. i can understand why people really hate this stuff if they did not come from a cs background, but it is a knowledge gap that they should look to bridge eventually...


>> to see how you think about problems .. That is the noble goal. Then it goes horribly wrong along the way because many (very many by this river of comments) don't think the same way during interviews as they did while doing amazing work just the very day before. It's gone too far and it's presently HR "conventional wisdom".

>> getting it correct isn't even that important .. Perfectly proving the point. Coding the day before, you're aggressively focused on getting it right and shipping a quality product. Suddenly you're in an interview and you're doing the opposite, coding just so much irrelevant nonsense that doesn't really matter and being judged out of context. Wasted time, effort, angst, in short a potentially bad start to what might be a great relationship.


I like oracle way of hiring. You got a degree from a decent college with decent GPA you are in. Very clear and straight forward. If you got in a decent college and graduated with a decent GPA - you are smart and somewhat hardworking, you should be doing well in your job.


Google recently revealed that going back over the data they kept about past hires demonstrated that an individual's GPA was completely independent of the quality of their future contributions to the company.

Why should Oracle be any different?


There is a diff between what the parent said and what you said. They aren't opposites, hence they can both can be true. IMHO.

What I understood from parent was: good college + good GPA => meets minimum hiring criteria, so make them an offer.

What you are saying is: (good college, good GPA) is not correlated with magnitude of performance among PEOPLE ALREADY HIRED INTO GOOGLE.


I bet height correlates very weakly with basketball ability among top NBA players, too.


I'm glad to know that somehow being at a good college makes learning about linked lists somehow more relevant to employers.


google are a notoriously selective employer, so it's hardly surprising that GPA has limited predictive power within the sample of people who were successful applicants.


Actually I really like the way Google gets their best employees -- they get them in acquisition after they've build something useful


That could go the other way too - if they don't hire people based on their GPA they might be weeding out bad developers even if they did well in school.


Have you considered that Google might be lying?

Many larger firms with technical employees are worried about their lack of diversity, and the relevant legal risks. They may have to bend their effective practices to mitigate this risk.

Beyond making this claim as an ulterior rationalization, mendaciously spreading it might help trip up competitors.


Correct me if I'm wrong, but considering the general make-up of Tech-employees in the Bay Area, by following your logic to conclusion leads me to think hiring outside of white males is a negative... if you think diversity = tripping up companies.


This is great. The best way to see if someone can do the job is to give them a job to do and pilot test. Introducing variables, like interviews, logic games, etc. reduces the likelihood that a potential employer can figure out whether or not you can actually do the job.


If you get nervous under the pressure of an interview - how will you react when $CriticalSystem breaks during $BusyPeriod?

Do I want to hire a person who is great when things are going well but who goes to pieces under pressure?

Learning how to be interviewed is as useful a skill as learning how to code.


There is a common theme but an interview and a crisis situation are not the same.

Its like attending an exam, its not the same getting work done in the real world.

>>Learning how to be interviewed is as useful a skill as learning how to code.

No, learning how to build is a useful skill. Learning how to be interviewed is mastering the art of being the best rat in the rat race.

The whole point is even if you win, you still remain a rat.


> Its like attending an exam, its not the same getting work done in the real world.

Of course it's not. Real world is much more stressful than an interview. During an interview you chat with another developer in a room with a whiteboard. In the real world you are woken up by a phone call at 4 AM to fix a critical system, knowing that if you screw up even slightly, you'll lose a very important customer. I've experienced both and I can confidently say that I prefer the former.


I disagree. I've been in those "4AM" situations before and handled them well.

I can't interview to save my life.

These are two completely different mindsets.


But you have much more background at 4am, you know the likely failure modes, you aren't dealing with a black box. An interview is often a black box you do not even know what you are trying to optimise for...


I agree 100% with this post. Any time it is feasible, the best way to know what it is like to work with someone is to work with them. Small contracts and transitions from contract-to-full time allow both parties to learn a bunch about each other with minimum risk.


I loaded the article and searched for "Github", "Bitbucket", "Mercurial" and "Git." I didn't find any. No tech interview and no carefully prepared resume of source with 3rd party annotations for a base level of veracity? No hire. Doesn't matter how neck your beard is.

And I am certainly not going to introduce a TON of overhead into our process bringing you up to speed just to assess this. You go from asking for 3-5 hours of my time to asking for over a week like that is reasonable. Like that is somehow a superior outcome for everyone? Here's a hint: it is not.

You live the life you wanna lead buddy, but I am not going to "trust" that you are a good developer without getting at least some indication that you are not a very convincing impostor. I have trouble with high-stress googletard interviews too (and I don't give them), but to ask for tech jobs without any real evidence of tech capability?

That's unreasonable.


I completely agree with this, to the extent that I enforce this in every place I plan to work with/in. Work in with a small contract, get to know the people/business. Keeps options open for both sides without losing out on time/momentum.


Seems like a reaction to yesterday's Google post.

Does anyone know how interviews at Apple and Facebook are like? There are often praises of Microsoft's interview procedures and bash on Google's on HN. Wondering what these two other companies are like.


While most of the comments are about the perspective of "Why does the applicant desire to not have a technical interview?", I'd rather talk about "Why does a company desire not to do a short contract?".


a contract in the evening is the best way to see how someone works and makes a lot more sense. A bad hire costs everybody a lot of money. I don't know why more firms don't embrace this method.


Giving paid assignments to see the candidate's job performance is not new. It has been used by a lot of companies. Even we hired our first guy using such a process. And it has worked.


Before I ask someone to come, I check his online stuff: github account, twitter, personal website, Linkedin. If with that I'm not enough sure I don't bother to interview anyone.


So you a priori don't believe what is stated in the resume. Why?


I read their cv's. In fact, Linkedin is a cv itself. But I like to inspect his/her code/design before taking a choice.


To put this post in perspective, I'm curious about:

  - How long have you been doing this career for?
  - How many jobs have you had?
  - How long you had those jobs?
  - How many technical interviews did you do?
  - Since when have you started practicing your new 'technique'?
  - Over which period have you effectively applied it?
Until similar numbers are available, I'll simply consider this article an anecdote that, if anything, suggests the OP is a job hoppers or has a hard time keeping a job.

In a non ad-hominem manner, I guess what I mean is: what useful data is this? Should people base their future behavior on your anecdotical reliable experiment/measurement?


very smart approach. it's never wrong to approach a job interview as a negotiation from the beginning. If you KNOW you don't do your best in a given situation, you get a chance to see if the company sucks by seeing how they respond to your questions. Employers who don't get this miss the point entirely. It's a two way street, especially when hiring quality developers.


Great post! Completely agree! While we still do traditional interviews at CoachUp, we favor the contract->perm model whenever possible.


I wish all interviews were done this way. It solves so many problems with the traditional coding interview process.


I couldn't agree more with this approach. I have a similar story that recently proved to be quite successful.

I was working on a project myself, that I kept getting stuck at a particular point. It could just have been that I was looking at it, by myself, too long and was too close to the problem that I couldn't solve it.

I was looking for Rails devs because 5KMVP started getting more requests for work.

I got a few recommendations and people reached out to me about that freelance Rails position. I whittled down the list to a few I was interested in and I decided to do exactly this.

I created a mini-spec of the problem I was trying to solve, pushed the codebase to a private bitbucket repo and added the guy I was evaluating.

Told him what I wanted completed, and told him I would pay him to complete that micro-job. If it works out, then we will move on to other projects.

Once he finished the project (in a few days) we both walked through his solution. That was such an insightful process for me, because I got an inside look into the way another developer thinks. I even learned from his approach, from his code style and was pleasantly surprised with the quality of the output.

Going through the 'post-code analysis' also allowed me to see how he communicates in the way that I will really communicate (which is via Email and Skype).

I have since hired him and I love working with him. We do have things to work out - specifically on the communication side, but I was pleasantly surprised at the outcome of the little experiment.

For a relatively small amount of money, I was able to a) Learn an interesting approach to solving that particular problem, b) learn new coding approaches, c) figure out how he communicates, d) see how we would work together - he didn't understand something, so he asked questions while he worked through it, e) he was able to do all of that at his leisure - not necessarily through a timed examination.

It's a wonderful screening tool - and while I am not sure how that will scale - that has been my experience with this approach too.

I will definitely continue hiring freelancers like this....by the way, I only did this after I looked through his Github account and checked out any projects and web properties he had online. That's the first line of screening from my perspective.

Edit 1: I thought I should add that I think that this worked so well for me, because this was a problem that I had been tackling for weeks and couldn't solve. So I was intimately familiar with the inner workings of the problem and so could fully appreciate the solution.


This is the one I got just recently. You have one min draw me Twitter architecture ... GO!


Job interview have to change because the jobs are changing, possible startup?


the other way is to build up a github and speaking portfolio. not only will this get you almost any job, but it makes it so obvious that you're good, that you get the upper hand in negotiating.


100% agree. most hires through the traditional process are bad hires.


I felt like I was reading something I wish I'd written, thanks.


This makes me feel so much better about myself.

I'm not alone.


Fish oil will help with anxiety issues.


I will. :)


The traditional recruiting/hiring pipeline in the software industry is clearly non-ideal. The current tradition favors superstitious meta indicators & ritual over realism, it often features under-qualified or too-young interviewers asking/doing stupid/irrelevant things, it favors unpaid unilaterally-imposed work and bureaucratic hoop-jumping (and mindless paperwork and not-work-related personal snooping), over professionally compensated mutual reciprocity, and, to make it even worse, it's biased to reaching false rejections (because they are so afraid of regrettable hires).

Let's do the opposite of all these things!

I've recently started writing down an attempt at providing a better replacement I hope to begin following and enforcing 100% without exception going forward. My own system has similarities to what the OA advocated. I call mine RYR, which stands for "Realistic, Yes-Finding and Reciprocal."


What you wrote above, I am signing it. I couldn't said it better.

On one hand, you are valuable developer, they went through a lot of trouble to find you. What you are faced in the interview is often far from ideal. I did ran into exceptions, but it is still more a standard then exception to encounter what you eloquently described.


I wrote about code tests and interviews a couple of months ago. (http://germanforblack.com/post/52224250893/the-perfect-code-...)

Heres a choice quote that I'm still happy with:

"Programming isn’t theatre or performance, “on demand” isn’t how your job works"


Hoop-jumping, including memorization-based education, just doesn't work as well as real-world scenario tests.

We forget this at our peril.

The real reason we indulge hoop-jumping is that it gives a veneer of equality to a process that (really) has more to do with natural gifts than certifications.


Having gone through a fair amount of tech interviews, I really understand the author's point. On another point, I just wish recruiters would put the salary in the job offers. It would save everyone a lot of time.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: