Though this isn't as bad as many I've read, stories like this are the reason I have never applied to work at any of these large firms (Google, Apple, etc.). I have been a full-time developer for more than 20 years. I have 4 software patents to my name, one of which formed the basis of a startup that was acquired for $64 million. I know a few people at Facebook and Google (not at Apple), and I am definitely in the same league in terms of coding skills.
However, based on available information, I am 100% certain that I couldn't successfully complete the on-command hypothetical coding exercises with someone standing over my shoulder, along with the other mental and social gymnastics associated with applying at any of these companies. I wonder how many other well-qualified people are out there that will simply never apply because of the drawn-out, intimidating hiring process.
Sometimes it was not only intimidating. Several months ago I had interviews with apple for a devops position. While most interviewers were friendly, there was a very aggressive one. He started with "I am going to ask you some of my favorite questions", and the tone of the interview went sour. Most of the questions should be from the skill sets he was mostly proud in but remotely related to the requirements of the position. For questions that were relevant, he asked something like "how could you terminate a forkbomb without a reboot?" which I answered "practically it is impossible", he insisted there was a way which I did not know, and I felt insulted. While I guess he was expecting me to answer process group killing (which is still impossible when all resources are taken the computer is not responsive at all), it is just too damn wrong to make an interview a do-you-know-what-I-know showcase of the interviewer. Unfortunately, in big companies like Apple, ego-filled persons are not rare. If having to go through more than 5 rounds of interview, one have a good chance to encounter one.
There is a clever trick for that: a classic bash fork bomb will completely die once it gets impossible to spawn new processes. And an easy way to achieve this is to exhaust all PIDs, usually there are 32768 available. So starting enough `sleep` processes will do the job. That is of course if you still can run at least one shell command on the machine.
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".
From my experience there are three reasons these questions are asked:
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've interviewed at Amazon and Google. Amazon was just poorly structured overall. Google really tried hard to make the experience good, but my last interview was one of these where he had a particular very clever and very proprietary method to solve the question he asked and wanted to see if I could guess it. I could not. Though he ended up telling me about it and it was interesting, reflecting back on the experience I thought it was not very useful.
> "How could you terminate a forkbomb without a reboot?"
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).
The way it happened to me, it was just totally unexpected and I decided to go with it, no strings attached. Don't think too much about it, take it as an experience, you have nothing to lose after all (subjective, depends on how much you invest in prep time and if you lose work hours from your current job, so YMMV). I took it as a learning experience, I read books before interviews but did not go too 'serious' into anything, just the desire to learn and compare myself with my peers. I found the interviews to be really challenging (in the good way), questions were interesting and taught me a lot of things, both personally and in regards with peer interaction.
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.
> You need to be ready to do tree traversal, detect cycles in lists, sort and search, create a hash, find shortest paths in graphs.
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).
Doing the review was useful for me in prepping for an interview at Google. I really learned a bunch of stuff that I'd been just brushing over for years. If you are just doing it to interview, that's probably not using the opportunity well.
In a similar vein, I'd also like to know how many people manage to land jobs at the Google's and Facebook's of the world, and ultimately prove to be less-than-spectacular developers.
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.
A thing that we all have to consider is that we've all been beginners once, it really does not matter. Throughout my entire academic career (bachelor + master in CS) I've met my fair share of brilliant people that still struggled with concepts that to me looked very simple and straightforward, and I've also struggled with stuff that others find very easy and natural. It really does not matter, you always learn something new and the things that we didn't know yesterday can turn into the things we know best tomorrow simply because we keep evolving and bettering ourselves.
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.
ultimately prove to be less-than-spectacular developers
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.
Maybe he gets to work on difficult problems that can only be solved by a great algorithm.
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.
At such a big company, I doubt anyone could get a job just working on algorithms coming out of undergrad. Maybe if you had a PhD in a relevant field I could see it. I'd bet almost everyone at Google is extremely good with algorithms when compared to the whole population of developers so I really don't see them giving this kind of sought after position to someone so junior. There's just too much risk for the managers to give it to someone who's still unproven.
I went to University with someone who aced every written CS exam in 'software patterns', 'user experience', 'computer architecture' and the like who landed a job at Google as a software engineer straight out of uni.
They couldn't complete a single practical lab exercise without help from peers or lecturers throughout the entire time I knew them.
I used to be like the person you're describing.
I had such a hard time with actual software development, until a few years in, when all the theoretical knowledge "clicked".
Then I was able to always make consistent gains in dev skills from the os level to higher level software architecture.
I think it was because I could understand the core abstractions from the higher level ones. Though I also might be an outlier, because even out of school I study a few hours a night.
Sounds exactly like the guy I knew. In writing, he knew it all, but had no reference to actually apply it. It sounds like many CS graduates, myself included; without applying yourself in a non-academic setting it's quite hard to be a good developer, because the projects simply aren't big enough or haven't had the man-hours applied.
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.
Let's be honest, 99% of Google employees are not working on hard problems like self-driving cars, they're just finding new things to slap ads on. You might need to be impressive in a very narrow way to get in, but the work isn't going to be that challenging.
While that's most likely true, they all go through a fairly grueling interview process where their theoretical knowledge is really tested. It sounds a bit iffy to make someone with a decorated career or an advanced degree go through that, promise them the world, and have them answering support questions for Google+.
Google employs thousands of developers. They can't be that strict about who they hire as a 5-people startup. So they sure have lot of less-than-spectacular developers and they don't care. You need talented people as architects (or whatever), not your code monkeys.
This is definitely true of large firms, but it still surprises me that the likes of Google could have developers that could get through the Google interview process, but would probably struggle with a take-home test from a company looking for someone to demonstrate an ability to be able to build something.
I have similar work experience (though no patents or start-up success credentials). I did run the Google interview gauntlet (unsuccessfully - so far) over the last year.
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.
This is a pretty awful reason to not even try. From the outside seems like working at any of those listed would be awesome if not just compensation but ability to grow.
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.'
I doubt it would take just a few weeks b4 you could ace the test. They'll ask hard questions that prove a depth of knowledge. The only trouble is that in most day to day programming, you will very rarely require this depth of knowledge about algorithms. So then, if your aim isn't to get one of these jobs, this sort of knowledge is rather useless.
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.
> I think the focus on algorithms can be an underhanded way to prefer young, fresh out of school applicants.
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.
I used to be good at these tests when I first started out 14 years ago (fresh out of university).
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).
Not for Apple or Google, but I've literally been asked impossible questions during some interviews at other big-names.
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.
One of my Google interviewers asked me to implement the AdWords analysis backend from scratch: an online, high volume (high enough to need to partition the data across some kind of distributed storage) streaming dataset with a query load that the interviewer refused to define, even when pushed.
I was a bit non-plussed at that one. Still don’t know what he was really trying to get at.
Maybe they intentionally asked you an impossible question that is not obviously unsolveable to see how you react when given and how you approach hard problems.
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.
There are more option than the following scenarios:
(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 got decently far, I would say, all things considered. I was able to lay out the problem domain well - determine what the requirements were, all that - then start by breaking the problem down into bits.
I did hit walls, understandably, which ultimately ended the interview with a lot of "hmmm, not really sure. Maybe this? No? Oh... Hm... [..]"
You can add Microsoft to the list when it comes to on-command hypothetical coding exercises. Along with optimal solution, you are also expected to give it in a short duration.
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.
Whatever your judgments are about the ethics or efficacy of this process, I'm confident that your reaction, and the pool of people excluded because of similar reactions, is not something they are overlooking, but is a consciously designed effect of the process. Testing stress-tolerance is probably one of their specific goals.
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)
Every interviewer wants you to let the guard down and show them the real you. We know the version of you that comes to our interview will be copacetic, genial, nice, friendly, etc. by default. Our biggest task in most of these interviews isn't necessarily ascertaining whether you can develop software -- hopefully that's borne out of some pretty straightforward questioning.
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.
Yeah, however they probably overestimate their evaluation capability, the bias of the moment (candidate might be nervous, etc) and underestimate their capacity of letting the candidate go if it's not a good fit (especially in countries like the US)
Interviews weighted towards undergrad topics, are just a way to slip ageism past HR, who don't know that dicking around with linked lists and hand-coding sorts aren't what real actual working programmers do all day.
It would be one thing if the salary was substantially higher than what you can get elsewhere, but it's not. The other perks sound really nice, but not nice enough to deal with the headache of interviewing there.
I think you are rationalizing. These interviews are really not that difficult. Try going through "Cracking the coding interview", a month of practice should be enough.
I'm not an Apple fan, and wouldn't apply there myself, but this doesn't actually sound that bad. It moved along relatively quickly and he had a definitive answer in a fairly short time frame after his interview was done.
However, based on available information, I am 100% certain that I couldn't successfully complete the on-command hypothetical coding exercises with someone standing over my shoulder, along with the other mental and social gymnastics associated with applying at any of these companies. I wonder how many other well-qualified people are out there that will simply never apply because of the drawn-out, intimidating hiring process.