I despise interviewing for software positions. Engineers love to treat interviews like some kind of hazing. They're gonna make you quiver and sweat and if you can still solve their stupid brainteaser maybe they'll give you the honor of working with them. Problem being, this has basically nothing to do with how good you'll be at the job. I spend 0% of a normal day with someone I don't know staring me down and judging every line of code I write in realtime.

I much prefer medium sized offline coding challenges, both for myself and for hiring my team. You give a good engineer a small project to work on, an he should crush it. Because that actually has something to do with what engineers do on a day to day basis. Personally, I get the job pretty much every time if I am told to build a small project, and I crash and burn almost every time if I get the SWAT team of surly technical interviewers.

It's worked fine for me because the small companies I like to work for are more apt to give out the projects, but still I could do without some of the awkward interviews I've gone through with companies who use the Google-like process.

I think there is a lot of negative bias here, because people who do badly in algorithms and data structure questions, or dislike them for some other reason, are more likely to speak on the issue.

I think that these questions are good because they are difficult, and a smarter more capable person is much more likely to get them right. Notice that big tech companies have stopped with the "brainteaser" style questions like how many potholes in Manhatten, but there is no move away from algorithms and data structures questions. And I don't consider the format to be high pressure. Apart from the pressure inherent in having to answer the question on the spot, I never felt any pressure from the interviewer, they tended to be very polite and mild mannered. At worst they didn't understand or agree with my solution.

Telling people that these interview questions suck and they should look for jobs where they don't have to answer them, is really bad advice. Some of the best jobs (for most people) require them. If you face such an interview, the very best thing you can do is study. I probably did 100 interview questions in preparation for my job interviews.

I personally would quite like an interview where I work with the interviewer to solve a problem or puzzle that he himself has not solved--as opposed to the traditional setup where the interviewer acts as the all-knowing oracle who happens to withhold the solution to this one problem. This could be difficult to set up on a regular basis, though.

I actually had an interview somewhat like that recently. The team was about to start working on a new feature for their software. We had a sort of round table discussion of the feature and how to go about it. They actually didn't have me write any code at all. We just discussed approaches to the problem, algorithms, architecture design, potential problems, etc.

Another place had a pretty cool interview process. They were going to give me a take-home project with a week to work on it and pay me market rate for it (in the form of an Amazon gift card for a few hundred bucks). I didn't end up doing it, though, as I took another offer right before they gave me the project, so I voluntarily withdrew. Still, I think it was an interesting and worthwhile idea.

Well written piece that shows what to me is the SV recruiting paradox: there is a massive demand for programmers, yet companies make it really, really hard to get a job. It's easier to start your own company without the interview hassle and condescending attitude of some HR managers.

I might be out on a limb here, but it seems it's almost easier to raise money for your startup than to get a job. Of course it gets a lot easier once you have established a network of people so you can bypass the whole recruitment process.

I am in grad school and live with roommates in the SV. Amongst the six of us, we have interviewed at a cumulative of 20 big SV names in the last month and of course we discuss the interviews frequently with one another.

Companies like Broadcom, Cisco, Juniper, Anritsu, Apple etc. solely rely on the programming problems the OP talked about.

HP focuses on riddles and puzzles to a point where it is ridiculous and mind-numbing (1 hours interview, two interviewers, about 15 riddles :-/)

There is however a marked difference in the way companies in SoMA, SF interview you -- conceptual discussions, chatting about previous projects, finding out about your open source contributions, asking you about what you like about a certain language, talk about editors a little, etc. And I'm also including companies like SCEA, who although a part of larger companies, behave in this way.

Unfortunately none of us interviewed at Google or Facebook, so I have no comments there.

P.S. Most of us have accepted offers at smaller companies in SoMA, SF.

The urgency to interview, followed by the abrupt halt in communication isn't something that is unique to Silicon Valley or engineering positions. I had it a lot in London a couple of months ago for mostly product jobs.

It's incredibly unprofessional / downright rude - especially when so much pressure is put on to get you through the interview process quickly. It also means that I now have a negative opinion of a number of companies - and advise friends against applying or interviewing there if approached.

I've been in a position of hiring before, and while it's not nice to tell someone that they haven't got the job, it's the polite thing to do. Most people are reasonable, and it increases the chances of them recommending your company to others.

This echoes my experiences about a year ago almost exactly (although I was looking in London). The obscure programming problems are largely a waste of time, but fairly non-threatening and generally ok (there were a few companies that did group problem solving exercises instead which really impressed me).

The biggest issue that I found by far was communication. Especially in the Silicon Valley based companies that were looking to hire in London at the time. Communication times of a few weeks seemed fairly commonplace (with contact still extremely positive after such a long wait). One company (I suspect the same as the non-profit mentioned in TFA) took more than a month to get to my second interview, during which time one interview was cancelled about an hour before it was due, and one interviewer simply failed to turn up with no explanation.

My limited experience is obviously no indicator of any wider issue, but if that's generally how companies interview, then I'm really not surprised at all that they find it difficult to hire talent.

> [ Lots of coding puzzles and vague about that "very difficult problem" they're working on that requires expertise in 20 different technologies ]

I get it now. Silicon Valley job interviewing is white-collar gang initiation: you have to show you can bear the pain and humiliation of getting metaphorically beaten up and humiliated. It's not about getting the questions right anymore than taking a fist in the face qualifies you to be an expert Crip, it's about impressing someone of rank by the way you bleed.

  > I emailed them back asking if they had any feedback from
  > my interviews, but I’ve failed to receive a response.

I've been bothered by this as well, because we want to improve ourselves, and the best way to do so is through feedback. At the same time, you have to understand that not everybody is like us, and enough people that where given that feedback in the past have used that opportunity to "argue" that they really should have been hired or argue that the feedback was wrong. Between helping a stranger improve and avoiding a potential headache for themselves, as much as I would like to have had feedback on some interviews, I can't blame anyone for avoiding the issue altogether.

  > Almost all interview questions I take a long time with. I 
  > probably have a 85–95% rate of solving puzzles—using almost 
  > all of the allotted time—on my own, and the rest I’ve needed 
  > a very small hint to get me in the right direction to begin 
  > with. I can’t think of an instance where I’ve been given the 
  > answer because of being unable to solve the problem.

Well, that's one problem right there. The kind of companies that ask you the kind of questions that you say are beyond Fizz-Buzz, are usually just starters, to get the ball rolling, give you confidence and keep iterating after the first solution is reached if it isn't perfect, or by adding new constraints to make it so you have to keep thinking.

The interviewer most likely has allotted time for 2-5 of these questions in his interview, if you are taking all this time on the first one, then most likely you are not going to be highly regarded, as the interviewer hasn't got enough information to say wether the one question you answered is representative of your skills.

  > Is a total of eight cumulative hours of interviewing with 
  > around seven different people not enough to get a good 
  > signal? What does this say about the interviewing process?

It says that they want to make sure they hire somebody who's "a good fit" and the hiring pool is high enough that they can get away with false negatives.

  > Don’t sell me your product, sell me your challenges

The fact that they talk about the business instead of the tech, at least gives you some confidence the company will not go belly up because they are selling cuecats. Of course it's not the best way to entice a developer, but it's not as much of a red flag to me as you make it out to be.

The whole interviewing process is ass-backwards for smart people.

I have little interest in working for a company where I'm going to struggle to do the job. I'm not going to apply for a job where I'd be out of my depth for any more than a month or so, because that sort of "if I don't get better at this soon I'm going to be fired" sort of stress is horrible. I want to find a job where I can succeed right off the bat, learn new things and get better over time, and where I can see myself staying for several years at least. No one wants to be a job hopper; it's a symptom of poor interviewing on the interviewee's part.

From my point of view then, I know before I even get to the interview that I'm perfectly well suited for the company and can do the job - if I wasn't, I wouldn't have applied. So I approach interviews in reverse: I'm going to grill you, your team, the baristas in the nearest coffee shop, and anyone I can find on LinkedIn who's recently left. If you ask me stupid puzzle questions that have little to do with what I've come to understand the job entails, I'm going to take that as a sign that your company is less than functional in the interviewing arena, and I know from experience that that extends to the actual engineering too.

Interviewers seem to treat these types of questions as shit filters. I do exactly the same. If you ask them, that's a smell.

I personally have had a better experience working with companies outside of SV. Better pay, hours, and less stress. Plus gasp!, actual profits (which are important for long term contracts and or employment).

I've been interviewing a lot of candidates over the last couple of months and I also despise trivia question interviews. The approach I've been taking is using a FizzBuzz type of question, but a bit more complex. I couldn't believe the number of candidates that have trouble with things like manipulating two arrays, which I feel is a basic level of expectation for a programmer. If I spend all hour on this relatively simple question, they are a "no" from me. About 10% of the interviewers pass this problem quickly enough to warrant the second question I ask. Frankly, I'm shocked at how under-prepared people are for whiteboard questions, regardless of how stupid it is. You would expect that by now, people would know to expect them.

The second question is something that is hard, but I tell them upfront that I don't know the answer to the question, to put them at ease, and that I want to work with them together on the question. I also ask for pseudo-code, I don't care about syntax. I think this usually gives me a lot of insight into how good the candidate is. I had one recent candidate that wasn't a spectacular coder (he had bugs in his code and he couldn't see them until I almost had to point it out to him), but he had this intuitive ability to zero-in on the most efficient algorithm for both questions that I asked. I felt he was good enough to be hired.

However, some other members of the team, while agreeing with my technical assessment, rejected him because of culture fit. He was a bit aloof and kind of weird. Some of the team felt like he might not be pleasant to work with, so they thought it was better to be safe than sorry. So sure, technical chops matter, but so does personality.

Let me posit a couple things to my fellow interviewing engineers here:

1) I like to ask questions during interviews. I hate the whole "I'm a brilliant guy charade." I'm not. You're not. Einstein was. Deal with it.

2) And I especially don't have a care for rote memorization bullshit for things I can look up in less time than it would take me to remember. I'm a thinker, not a fucking textbook.

So, if you said to me "do whatever using x algorithm", and I said to you, "I don't know x algorithm by heart; could you tell me what it is, and I'll implement it in one of the languages I'm proficient in?" would that just completely turn you off to me as a candidate?

Followup: (I can't edit my old post anymore), it's informative to actually read lots and lots of after-interview writeups where the candidate had an overall negative experience. Consistent problems emerge:

Glassdoor is awesome for this:

Some SV-companies with higher than average negative experience ratings:

http://www.glassdoor.com/Interview/Zynga-Interview-Questions...

Lots of "after the interview I appeared to have been dropped into a black hole since nobody's told me if I've moved on or not".

http://www.glassdoor.com/Interview/Palantir-Technologies-Int...

Unbelievably disorganized hiring process by the sounds of it. Numerous, detailed reviews of interviewers simply not showing up, poor communication with the recruiting staff, etc. Weird cult-like experiences. It sounds like a cattle call. I actually couldn't find a company with a higher negative experience score.

http://www.glassdoor.com/Interview/eBay-Interview-Questions-...

Unbelievably poor communication. Amateurish interviews. No follow up from the recruiters, candidates are simply left in limbo.

There's a fair number of obviously bad candidates who were miffed. But there's tons and tons of people who were probably good candidates, but were simply jerked around for weeks on end. In some cases, the company's own internal processes are so broken they couldn't even conduct the interviews correctly.

Some with more positive ratings:

http://www.glassdoor.com/Interview/Facebook-Interview-Questi...

http://www.glassdoor.com/Interview/Google-Interview-Question...

http://www.glassdoor.com/Interview/Amazon-com-Interview-Ques...

http://www.glassdoor.com/Interview/Microsoft-Interview-Quest...

See the difference in the candidate responses? You're doing something right if people get rejected but say they had a positive interview experience.

> I am especially bewildered by the fact hard CS questions are given to prospective interviewers who will only be doing boilerplate PHP development for the actual job.

I agree. I think it's fun to solve these puzzles, but often they're of no relevance to the actual job. Better if they asked me questions from their domain or about the technology they're using.

I've long since abandoned trying to do programming tests when interviewing coders. Instead, I work through a problem with them in a sort of socratic method; I play devil's advocate to them while they flesh out how they'd approach the problem.

It's far more illuminating, and a far better reflection of their worth as a candidate, than their ability to go off into a room somewhere and work through a problem alone. I'm much more interested in someone who thinks well than who codes well (since the latter can easily be trained).

Here's the lesson: Don't play the game.

Don't spend all of your time studying coding puzzles to answer questions correctly to people who are unlikely to hire you anyway. It's just a ridiculous waste of an intelligent mind. Spend your time building something interesting that actually helps the world. Build fun and interesting projects with this time. These projects might give you a career or a job that is smart enough to realize that you don't need to be given the fizzbuzz test.

> In most interviews I’ve had, engineers and recruiters I speak to spend a great deal of time gloating about their product, almost as if they are trying to sell me their product. The fact of the matter is, I am not interested in being spoken to as if I would be a potential consumer of your product. I want to be spoken to as if I would be a potential employee working on your product.

Spot on!

From reading the post, my takeaway is a guy who's probably going to struggle for awhile to find a position. When an engineer says that they only care about the technology and not the product, that would set off my red flags immediately. Frankly, in 99% of the cases, it's the product that pays the bills including the salaries of the team. If I had interviewed him, I probably would have suggested he look for a position in a R&D group in a large company with the funds to do that sort of software engineering.

I find many of the interview puzzles that people have posted on the Web that they've encountered at the Big Name companies as often a bit silly. Having said that, asking software developers to implement a solution to a common programming problem - "navigating a tree using recursion", etc. is perfectly reasonable. I've found more than a few software devs who have great looking resumes but who have no idea what recursion is, what a tree is used for as a data structure, etc. And I consider this the basic, easy, 1st year undergrad type stuff.

If there's an undercurrent to all of the comments here, it's that we still don't really have a good way to sift through the good from the really-not-so-good developers quickly. The programming tests and puzzles are a proxy for this and they only work so far - some people like to think through issues more before coding, or tend to freeze under this on-the-spot pressure. Doesn't mean that they aren't a good, competent developer you'd want on your team; my experience is that the guys who blurt out very quick answers can sometimes write the worst code.

I've seen so many posts about interview rants, including one I wrote myself, that I feel like the problem lies in the higher demand than supply of positions, and that interviews, not matter what bad feedback they seem to give, aren't that poorly designed.

I agree with this article that communication with companies is getting absurdly poor. With all these communications channels available, why is it so hard to send a quick email? Don't have time because of too many candidates? Maybe you shouldn't have more candidates than you have time to handle.

I've reached a point in my career where I'm not interested in engineering positions anymore (a great motivator has been to avoid the absurd SV-style interview). SV-style companies don't know what to do in these situations, they have an open position, I have the experience and skill set, let's have a conversation about the work I've done and what your needs are.

Problem is, nobody in the company knows how to hire for these positions and they seem to be done based on word of mouth or through the networks of the investors or other seniors in the company. In a couple of interviews at these companies, they plan for the usual all-day interview, and then I sit there in front of an interviewer who is simply at a loss for what to ask me.

On occasion they haul out a brain teaser, but I usually stop that with a "you do realize the position that you are hiring for is not one where solving brain teasers will be a reflection of the kind of work I'll be doing". This rings some alarm bells as some of the larger SV companies have found themselves on the business end of a law suit for this. Asking prospective project managers nonsense questions during an interview offers no information to the hiring committee about the suitability of a candidate. This can create a legal liability for the company if the unhired candidates feel they've been discriminated against -- especially if the company just hires somebody they know anyway -- proving that the position wasn't filled on a level playing field for all the candidates.

One other problem I've faced, I simply make too much money these days. In an interview with a now very large company that exactly matches the format in this article, I made it through the interview gauntlets and finally got to the compensation round:

"So what kind of compensation are you looking for?"

"Well, I made this much last year, I'd like to make at least that much this year and going forward."

blank stare of shock "y-y-you made how much?"

"Well, it was a mix of sources, my base was this, I made this much in bonuses and additional grants, and I was helpful in a few sales and earned this much commission. I don't expect that this job is commissionable, but I'm open to alternate mixes of compensation so long as my base stays about the same."

"y-y-you realize not even the CEO is pulling down that much base?"

"I'm afraid I'm not privy to your company's compensation packages, but I know that the CEO reported a few tens of millions in stock grants last year, I'm not expecting that much, but if you feel the need to offer a lower base, I'd like to expedite the vesting schedule by a year then"

"I-I-I.....I'll see what I can do."

And that ended that job right there. I received a very nice call with a rejection a week later.

Another anecdote, a friend of mine interviewed for a VP position with another major SV company, he got through the initial rounds based on his education (Ivy-League) and other credentials. During the interview they decided to do the equivalent of an engineering-style interview...the recruiting team had clearly dug deep into the bowels of some undergrad finance textbooks, and asked him to derive a number of finance formulae he hadn't seen or cared about in 20 years. It was utterly random and doomed to failure. He went on to other companies where we was quite successful, while that position remained open for the better part of two years before finally being filled with a friend of one of the investors.

The best places I've worked (as an engineer and otherwise) have been the ones that don't engage in this nonsense. I can see a simple fizzbuzz test being a prescreen as being useful, but just sitting down with a candidate and having a conversation about their resume seems to work best. Bonus, it's respectful of the candidate. Unlike a great many companies, you've actually taken the time to look at their resume. If you recognize something on the resume, ask them some penetrating questions and dig into what they know. If you don't recognize something, engage them to teach you about it. Competent people are competent at talking about their job. Ask them things like "can you give me examples of where you applied algorithm design or at least some complexity theory in a job?" If they give an example, probe deeper, have them talk in depth about the algorithm, see what they remember from their undergrad about big-O. Or "what was the most difficult integration you've ever faced?" followed with a "why?". Dig in, make it a conversation. Let them become a teacher during the interview, where they teach you about what they know and about their life. Ask questions like a student would. It's respectful, humble and draws unbelievable amounts of information from a candidate.

You'll quickly learn what kinds of things they know, what they don't know and what they're weak at. You'll also learn about their soft skills, like communication. Instead of playing an insipid game of cat and mouse, you'll learn about the person you're hiring. Ain't that what YC looks for?

I wonder what would happen if perspective job seekers just say that they won't do coding questions in interviews? Moreover, if they insist that interviews can't be longer than 1 hour total, with a maximum of 1 phone screen. Oh .. to top that off, candidates insist they get told their fate within a week or less by email. If only ...

"Don’t sell me your product, sell me your challenges"

I actually care about the product equally if not more than the engineering challenges. I write code to build products and businesses, not for the sake of engineering. I'm a bit different though :)

>>Almost always, communication is done over email with a recruiter, and the average response time is several hours to a day.

How about trying a different method? Instead of emailing a recruiter (or the company), try calling. This is signaling that you're more serious than someone who's just following up with an email (think of the volume of the candidate pool you're in) and distinguishes yourself. Even better, at the end of the interview you could plant the seed for a follow up, like "It's been great meeting you, blah, blah, blah…I'd like to check in with with you next Tuesday (or whatever) at 10am with a brief phone call, as I've got other positions to consider and I know you've got other candidates…"

>>They then emailed me asking if I’d like to stop by their office for a few hours for an on-site interview. I responded after a couple days…

then later the OP says

>>larger companies, such as Facebook, Amazon, or Apple, are very expedient with scheduling and setting things up, and keeping the loop. This is extremely to their advantage.

Time is of the essence, but I understand you might have been busy. Probably not too busy for a quick follow up email to set up the interview. And, if you don't hear back anyway, be tenacious and call them.

>>A friend told me that I should take the strategy of sending email after email until they give me some sort of response. (“Stop sending us damn emails. We don’t want you.”) I’ve not really done this, but I’ve done more than what I think I am responsible for doing…

Responsible for doing? A different way of thinking about it would be to think about being responsible to yourself, not them. You want the job; are you doing everything you can to get this job? See stuff by Ramit Sethi for interview tips.

I have also encountered this while interviewing for the couple of jobs. I thought I did not study well and that's why could not solve the problems in front of the interviewer! In fact, when I am able to solve bigger problems while developing live projects. Nice post and it echoes something which has happened to all of us at some point in time.

Normally you know someone in the company and ask that person for information on how your interviews went, how your application is being handled, etc.

I don't think I'd want to work anywhere where I didn't have at least some loose connection to an investor or employee.

If you think "Explain design decisions and trade-offs of different techniques." is a 'puzzle'... Perhaps that explains a lot.

And then they claim they can't find anyone and push for H-1B visa...