Other than that the question is stupid, and most companies have a policy that forbids such questions. Same goes for "piano tuners in Manhattan" and "why are manholes round".

1. To see what your thought process would be in figuring out the answer. 2. To judge your reaction to such a nonsensical question. 3. To show off (either the interviewer is showing off or the company is showing off).

That said, they have some value depending on the position your being interviewed for.

I imagine that's a bit like asking how can you completely clean malware off a computer without reformatting. The answer is roughly the same: In the general case it's impossible, because once arbitrary code has been executed on your machine, nothing can be trusted.

Every time I think about applying to, e.g. Google, and start looking at how I need to prepare, I realize it's going to take around 40hrs of algorithm prep followed by a gruelling interview process. And at the end, I may fail due to interview nerves or whatever. It's hard to justify so much time. Then again, maybe working at these big companies is really worth it (many people seem to think so!).

Nowadays, I won't put up with more than a couple hours of interview. 1 hour I think is a good amount. Granted I work on contract and this is how things tend to be done in London. For a permanent role, my limit would probably be 4 hours on site + 3-4 hours off site (like a coding test).

I would definitely recommend applying to these companies just so you can say "Hey, I tried and did it" (did it = applied, not necessarily got hired). The getting hired part is just a secondary thing, it's a personal accomplishment that may come or not, but it shouldn't necessarily be your end goal.

At least this is how I feel and how I felt after interviewing at Google.

Full disclosure: I am currently an intern at Google after having failed the full-time interview process and decided to get a Master's degree, which found me back at Google as an intern.

I keep my data structures and algorithms book on the shelf - it was printed 15 years ago and uses Java, but it's easy enough to implement in something else. I used to restudy it every few years, for interviews. You need to be ready to do tree traversal, detect cycles in lists, sort and search, create a hash, find shortest paths in graphs.

I go back and forth on whether I'd do this again. I can't say never, because a good enough job might be worth the effort and risk, but I'm hesitant. How many times in life do you want to retake your undergraduate data structures and algorithms exam? I would outright refuse to do a lengthy "homework assignment". I've done that once (7-8 hours recommended time), sent it in, crickets chirping, and a one line brush off from a recruiter a full month later. I'm actually embarrassed to admit I even did this once.

As an aside, while I generally take a dim view of professional licensing, I wouldn't mind taking a "bar exam" for software development if (big if) it were well designed and administered, and perhaps voluntary to avoid regulatory capture. The reason is, I wouldn't mind studying a hundred hours or more for this test if it was widely respected and meant I wouldn't have to keep re-taking it every time I interview.

Maybe it's because my focus is web, but I have never had to do any of these. My eyes typically glaze over any time someone mentions algorithms. Not because of lack of interest, but because I'm self-taught, have only had one or two academic CS classes, and have never taken a course on algorithms.

When we're hiring developers we do have a "take-home" test of sorts but you can do it in an hour or less. This is prior to our in-person general job/fit interview (my boss) and the technical interview/review (me).

I dropped out of a masters degree to join a startup as a .NET developer, but kept in touch with a few guys finishing there. One of them now works for Google. He was always great in the algorithm classes, and he knew his theory reasonably well, but he'd constantly struggle with writing the code and REALLY grasping OO. I'd help him structure his Java code, and he'd help me grasp data structures.

He's been there a good four years now, so he's clearly doing something right, but I was initially shocked that he was able to get in when things like static classes confused him.

Just because somebody had a hard time grasping Object Oriented Programming (which, really, is not as useful anymore. Plenty of brilliant developers moved past it) in school does not mean that he'd not be a good fit for a demanding company a few years later.

This is true for everybody, by the way, just because you feel like you're struggling on some concepts, don't dismiss yourselves. Try applying at some companies that might be 'out of your league' and you will realize that maybe some of them actually aren't that out there after all.

There's no sure-fire way to know exactly who you're hiring unless you know the person (and even then!).

But: many of these companies are using the wrong criteria, out of bad habit or sheer laziness. You get "brain teaser" questions ("how would you tell which light bulb had been on in the past 10 minutes?"), coding tests, even demands to know which lsof flag does foobar (but that's why God invented man pages!). In my estimation, the only real way to get inside someone's head is to get them talking about what they've worked on, hear their war stories, and talk in depth about how they've solved problems and built things.

Or maybe he works on making a set of algorithms 5% faster.

Making a sorting algorithm just 1% faster for the most used cases will probably save a company like Google vast amounts of electricity.

I guess there are plenty people who understand both algorithms and programming language features well. But if you want someone who is awesome in algorithms you might not care if they couldn't grasp the simplest programming language feature like a for-each loop, or a static variable.

They couldn't complete a single practical lab exercise without help from peers or lecturers throughout the entire time I knew them.

They didn't make it past their trial period.

It makes me wonder whether these hiring processes are built for people leaving university, and not necessarily for those that have spent a number of years as software developers. It's a good way to get those that "know" their theory, but it sounds like a terrible way to hire someone who is expected to be not just a competent developer, but talented.

From my experience, it's less the on-command hypothetical coding exercises (which you will get, and they will be challenging), but more so if you pick up an unfortunate draw of one of your anti-loopers (see famous Steve Yegge post).

I ultimately interviewed in early January with a team that really wanted me, but was rejected at a late stage executive committee review (surprising even my potential hiring manager and the recruiter). While I can't say for certain the precise factors that impacted my candidacy, I'm reasonably sure a significant component was one particular on-site interview that was almost a year ago. That particular interview was awkward right from the opening non-technical questions. Not sure if my interviewer was having a bad day. I'm not sure how I was scored, but I feel it was a "B" performance for me, the others felt like "As". I will say that its sometimes hard to gauge one's on performance as the interviewers were all nice and innately would not display much signs of frustration or dissatisfaction for a candidate to get the feedback signals that might be noticeable at other job interviews.

In the end, they seem to require near unanimous consent to complete the hiring process.

For those reluctant to try, I'd strongly recommend making an initial attempt at a Google job. You'll meet some remarkably nice, smart people and have some great discussions. While I can't be certain (as I didn't succeed), you don't need to be 100% perfect on your interviews. Quick, insightful and on the right track are important though. You do need to be smart, know what you are doing, and practice a bit on programming brain teasers (which should be fun for the right person).

IMHO, its worth the initial attempt, but if things don't work out the in first round of on-site interviews, it may be impossible to overcome that in later rounds, much to my dismay. The only downside is that you might convince yourself that you really want to work there and you'll have to face reality again if things don't work out. Don't be afraid to try.

I tend to err on the side of "I suck" when an interview doesn't go my way. Some people err on the side where everyone else is the problem. Different ways to deal with butt hurt.

Disclaimer: I have interviewed at Google and other hard places with mixed results.

I'm fairly certain I could study for a few weeks and ace the tests. I'm unfortunately also very resistant to doing useless work.

When the first interaction with a company involves requiring me to do useless work to prove my commitment (and everyone in the company has passed that hurdle) I very much doubt that I would be... how shall I put it... a good 'culture fit.'

Better to study a new language or statistics / big data. Rather, the most important skill you have day to day is your ability to concentrate & get stuff done. & the ability to take a big problem and turn it into manageable smaller tasks.

I think the focus on algorithms can be an underhanded way to prefer young, fresh out of school applicants. Those with good academic track records and with fresh mitochondria that can be utilized for great coding results.

This is exactly the thought that came to mind when I started reading this chain, and I'm happy you hit on it. This is definitely part of that elusive ageism that we keep hearing about in SV.

I was one of them; I participated in my school's ACM ICPC [0] teams. Just knowing the algorithms wasn't enough; we had to know what problems they applied to and how to quickly and effectively code them, often with a translation layer for the required inputs and outputs. This was hours of practice every week, and I suspect the top teams are a combination of natural talent and even more practice than I put in.

Even just four years later, I would read through the packet of problems for the year and feel out of practice. I would read problems and recognize that, once I could have coded it within a half hour, but not anymore. I have traded having deep knowledge of problems with the daily practice of "engineering in the real world", and I would not even want to have it another way.

[0] http://icpc.baylor.edu/

I have never had to implement a linked list in my career. I am a much better software engineer now, writing modular, maintainable applications, but they want to see what obscure algorithm I can implement in an hour and a half? Whats the point in that?

(I had a skype interview with Google before. Messed up the algorithm question, then half an hour after the interview was finished a good solution came into my head).

Maybe I should have recognized they were impossible and addressed the interviewer. They were usually very number-theory heavy problems. After a bit of research, I determined that it wasn't really answerable, and people have done PHD work at MIT, CMU, etc.. to investigate the question I was given 30 minutes to work on.

I don't lie about my qualifications. I'm not a PHD student, there is nothing on my resume or CV that would imply I'd be aware of some obscure (not something I'd consider important to comp sci like crypto) area of research... but still, asked these really oddball questions.

I was a bit non-plussed at that one. Still don’t know what he was really trying to get at.

1. You either know immediately that it is impossible and you say so, which means you've encountered the problem and its related research before.

2. You are a savant, like Kim Peek, and work out the solution to a PHd level research problem in your head in a few minutes, giving the answer that it is impossible.

3. Pretend to be (2) by already knowing (1), but having a good poker face and then faking an "Ah ha!" moment

4. Sit there, unsure, feeling stupid, wondering if you're supposed to know the answer to this already or if you're supposed to be smart enough to figure it out.

I'm having a lot of trouble figuring out how any of these outcomes are in any way beneficial to the interview process.

(1-3). Know the solution already or be a genius and find the solution surprisingly fast.

4. Sit there feeling stupid.

The idea is to give you an extraordinarily hard problem without the expectation that you'll solve it. The reasoning of the employer is the following:

I. You fall into the options (1-3) and you are either a genius or the question was too easy. Either way its not bad for you.

II. You don't have enough knowledge at hand to approach the problem. Then you do either what described in option 4. xor you accept and be honest when you don't know something and you know what to do next; identify information you are missing and how you can get it.

Since the case I. is rare and the case II. gives the employer a good picture of you it's a good question for an interview.

I did hit walls, understandably, which ultimately ended the interview with a lot of "hmmm, not really sure. Maybe this? No? Oh... Hm... [..]"

They didn't move forward. Oh well!

There's a number of folks who are philosophically at the extreme opposite of what Apple stands for, too, and who won't even think about applying there for that particular reason.

On the contrary, I've been in a position that I have to decide for applicants ( by doing technical interview ) if they could do the work or can not do it. It was a pleasant job when I can see some sparks of commitment and joy of doing the work. But talking more with the candidates it looked like they had a really hard time, being screened by the HR team, since they didn't have proper profile indicators, like "keywords in the CV", "past experience", "good university degree", "recommendations" and so on.

Does it lead to overall better hires than a less grueling process? I have no idea. But they must think it does.

The main issue for me is that I find it ridiculous to go to N teleconference interviews and then get turned down in person. I'm sure it's for some stupid reason like "all of our team like sports and you don't seem quite enthusiastic about it"

They push for you to "be honest" but that's only an excuse for turning you down. Give them the answers they want to hear and you'll be fine. Also the pressure of the moment is important.

(Also I would like to see their faces when my MBP's Facetime wouldn't connect - talk about a reliable software... not)

The real task is to figure out what you're really like after the interview facade goes down, and being able to envision you as part of the team.

It's a reason there's so much thought and discussion these days on ways to effectively anonymize people during job searches and interviews, I think. An interviewer / hiring manager needs to be very aware of their own feelings and mindset when making a decision to ensure the "seeing you" part of the decision process is done consciously and purposefully.

And if you are not willing to spend a month on learning, then don't expect to be hireable.