Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Stories and Tips: Interviews with Facebook, Twitter, Amazon and Others (robertelder.org)
219 points by robertelder on Aug 15, 2016 | hide | past | favorite | 85 comments


Interviews suck specially for senior developers. Why should I have to prove myself over and over again by doing idiotic basic algorithm type of questions on the whiteboard? After having worked for over 25 years as developer in major companies, shouldn't interviews be about a conversation? - can you imagine interviewing medical doctors the same way we interview in the tech industry? DR. Smith, please show me how you do open heart surgery in this dummy here... (because most interviews happen at the whiteboard)...


I'm a pretty senior developer. I really don't mind doing coding questions. after all, thats what we do, isn't it? As someone mentioned there are plenty of people that are good at projecting experience without actually being very effective at their jobs.

Whats annoying and disappointing is if the questions are at such a low level that there is little room to shine. You leave after your day not feeling as if the employer gained any understanding about you, and you certainly weren't able to get a read on your prospective peers.

The purely conversational interviews almost invariably lead to disappointment for me. The company is so desperate to fill a slot that they ask you probing questions about your work style. They spin grand portraits of exciting collaborations, novel development techniques, fundamental problems of concurrency and consistency. In the end they just want someone to respond to minor bug reports in their massive taped together codebase and make sure the servers stay up.


The part that I fear is the seemingly cookie cutter questions for CS grads, not for developers for that position. I've been doing software dev for almost 3 years. Never had to implement a red black tree. Nor could I, since I never took CS at school.

I'm very good at my job but would bomb the technical part of many of the traditional interviews.


I'm not the biggest fan of the algorithm-theory centric hiring regime, but "implement a red black tree" is a straw man. Even the most CSy interviews are at the level of contiguous vs. linked data structures, binary trees, and recursion, not at the level of very specific algorithms with intricate details like red black trees.


> I'm not the biggest fan of the algorithm-theory centric hiring regime, but "implement a red black tree" is a straw man.

I think it comes from the "Get that job at Google" blog post[1] by Steve Yegge. It is not clear what Steve means here, but he wrote:

  You should be familiar with at least one flavor of balanced 
  binary tree, whether it's a red/black tree, a splay tree or 
  an AVL tree. You should actually know how it's implemented.
I understand the gist of a R-B tree, I can probably write the immutable one on a whiteboard, but I don't think I will ever be able to implement the mutable insert/delete methods on a whiteboard. I have never been asked it in an interview yet, though.

[1]: http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...


That question is a filter for "recent graduate" i.e. young, without setting off any HR alarm bells.


you know. thats legit. some people will respect that and find other questions to ask that will convince them that you'll help them out alot.

and some people will be disgusted, and they probably aren't that great to work with. it would be sad if you couldn't find a job, but i doubt thats the case :)


I bet you do mind, specially if they ask you to do these on the whiteboard. What we do has nothing to do with basic CS questions... unless you have a very unique job. It can be done conversational if you know how to conduct an interview. Unfortunately, this is a skill that most programmers lack. best way is to pair program on a real world problem. Get your candidate to pair on fixing a bug on your system.


>shouldn't interviews be about a conversation?

sounds wrong to hire the best conversationalist. I know many people who are all talk and no substance.

>an you imagine interviewing medical doctors the same way we interview in the tech industry

they are already certified by the boards. Computer science degree is not equivalent to medical board certificate.


> sounds wrong to hire the best conversationalist. I know many people who are all talk and no substance.

Talk only goes so far. It isn't hard to make a poseur look like an idiot if you know what you are doing. A "Five Whys"-style line of questions, for example, will blow up most fakers in a few minutes. After all, how do you know these people are all talk? Is their talk really convincing to a technologist or does it just dazzle non-technical people?

> they are already certified by the boards. Computer science degree is not equivalent to medical board certificate.

People like to overstate the power and effectiveness of medical licensing boards. Very few doctors have to prove anything after their residency. All they need to do is complete continuing education requirements (which, in many cases, are pretty fluffy). That's for the most regulated of the regulated professions, too. Lawyers, accountants, engineers, and others have basically one major hurdle to jump, after which it's easy to remain current by the letter of the law.


Of course it would start with a conversation and then move on to the implementation where the ones with knowledge would shine through. Having the same start line as someone fresh out of college does not give an experienced person, the chance to demonstrate his abilities. And also after some time it can become boring to brush up the same old algorithm style questions in my opinion.


They have certification. Imagine if they had to distinguish themselves from an army of mouth-breathers with just enough coaching to know which end of a scalpel is pointy.


It's the shiny end, right?


If the questions are relevant to the job, it shouldn't matter if the candidate has 0 or 25 years of experience, because longer experience doesn't necessarily imply greater skill. That being said, it's legitimate to ask whether all those algo questions are actually relevant to begin with.


your willingness to be condescended to by someone with approx 10-15% your years of experience is a litmus test as to whether you will be a good 'culture fit'. age won't count against you as long as you're willing to put in the hours, eat dinners at work, put up with scrum management, etc etc.


On the flip side, I just interviewed two candidates claiming 10 and 16 years of experience for a "Senior DevOps" position. Neither of them could tell me what a default route was - one of them spewed some nonsense buzzwords and the other one thought it might have something to do with DNS.


DevOps is a culture not a job.

Most good candidates know this, and will actively avoid "DevOps" roles.

Now someone claiming 10 - 16 years experience as a DevOp, is : A: Lying. The term is 6-7 years old B: If they have even been using / administering computers for that long should know what a default route is.

Could they have misinterpreted the question? I know the even at a senior level, interviewees can get flustered and confuse themselves.


I didn't write the job title/posting, but the description makes it clear that strong linux and programming skills are required. These folks have 10+ years of "software engineer" and "systems administrator" jobs on their resumes, they're not claiming specific "devops" experience. I just talked to two more similar folks and I'm starting to despair at the state of the industry.

What job title would you suggest to find people with a working knowledge of programming, config management, and infrastructure/systems internals? If all you can do is copy-paste jenkins tutorials off of the internet, you're not a "senior" anything.


DevOps doesn't imply network knowledge. It can include CI/CD, dev tooling, automation, containers, cloud engineering etc.

Just saying in case you and your candidates have a different idea of the role you are hiring for.


I'd say that network knowledge is a key part of the Ops part of DevOps (especially when talking about cloud engineering).

But that is what you get with great buzzwords like DevOps.


I'm not saying I agree with the interview process of developers however it's much harder to become a doctor than a developer. Not to mention faking it and hoping you make it is very common in the software IMO.


Totally understand your viewpoint, with your level of experience it's borderline offensive to ask you to jump through similar hoops as a recent graduate. Arguments of standardization/filtering and homogeneity of candidates aside, let's be a little contrarian.

You've been doing a job for x years. There's been some personal development and it's been challenging (maybe you're now managing 10 developers and are having to write proposals, for example) but ultimately you've not had to prove yourself in the way you do in an interview in over a decade. What's to say you haven't allowed other aspects of your skillset that you've acquired over the years? If you're reviewing 20 peoples' code per week, when would you have had time to code out your algorithms? Using your own example, it's not at all unusual for senior doctors to lose their skills at suturing or putting in IVs. That's not to say that they've not acquired other valuable skills but there's also something to be said about keeping your fundamentals sharp.

Now maybe I've been drinking the kool-aid, but my understanding is that at your Googs and FBs they have open remits and expect their staff to be dynamic and quick to learn. One of the most valuable skills in that case is sharp fundamentals.

Losing that familiarity with the nitty gritty is a perfectly human thing, I saw it happen with professors being "outsmarted" by undergrads while at uni and early into my professional dev career I am already feeling certain aspects of my skill base deteriorating, I can only imagine what it'll be like in a couple of decades.

With all that, it's not hard to imagine why your big 5 do have such rigorous hiring loops, especially when they're already oversubscribed...


> If you're reviewing 20 peoples' code per week, when would you have had time to code out your algorithms?

You work on system design, databases, high availability and making sure large clusters don't fall and are able to talk to each other. None of the above require "algorithms". Also, it's hilarious how every company are asking the Google and FB questions now. And, you rarely get a SQL or database questions. I've had to work with colleagues who think they know everything just because they answer the algorithm question and can't do a simple "group by".


I see your point. However, a shitty surgeon would likely kill someone which would terminate his/her practice. A shitty programmer would keep making shitty software until the day he/she retires. Having said that I do agree that a simple technical conversation works well. The trick is weeding out the talkers which is fairly easy to do once you get to the nitty-gritty stuff and their wheels fall off.


Surgeons can sometimes get away with doing shitty work for a long time: "Paterson is charged with 21 counts of unlawfully and maliciously wounding 11 patients between 1997 and 2011." [0]

[0] http://www.birminghammail.co.uk/news/midlands-news/ian-pater...


Oh so you get interviews? I get asked to do 2 - 4 hours of unpaid dev work on my weekends in order to get a phone screening or an onsite... maybe.

So far that's pretty much been a deal breaker because I have other things I'd like to put my energy in, but eventually I'll just implement a generic rest api that handles common interview cases in languages I want to interview in, and use that, and adapt it as needed.


The medical profession has AMA that does a pretty good job of protecting their members. Maybe we need a Software association.


> If you spent one day working at Google, in the worst case you can now be called a "former Google employee". Next time you hand out resumes, you can just hand out a blank sheet of paper that says "I worked at Google" scribbled in crayon and you'll still get interviews.

Pretty funny and also sadly true. The author is the same person that is currently building a C compiler for the one page CPU: http://recc.robertelder.org/. Suffice it to say this person should just be hired on the spot. Any interviewing is a waste of time for both parties.


Sure, definitely. If the employer can afford them and wants what they are willing to work on, and either is ok with that person working on their own or is confident they can fit well with the team. But yeah, otherwise, all unthinking praise be to the rockstar programmer.


No. You know, this is important stuff. I'm going to say something serious.

I worked on Wallstreet for 5 years and this is the exact same attitude reserved for Goldman Sachs types, and that pervades Wallstreet in general.

But do you know how most people get into GS? Because GS says, "I like the school on your resume and the friends you keep."

But do you know how most people get to go to that school and make those friends? Their parents. Their parents move to Westchester, living next to other well-to-dos, and then send their kids off to exclusive colleges and grad, very often on the basis of letters of recommendation from neighbors.

Yes, many of these students will be smart and well educated. But they have almost without exception bought into and willing, consciously or not, to perpetuate the system that provided them their privileged place in our society.

This the polar opposite of what Silicone Valley was supposed to be. But it's not turning out that way. Sadly.


Having gone through similar experiences as an fellow undergrad @ waterloo ('14), I wish I had read this back when I was in first year.

"During your interview, your interviewer is likely to be testing the limits of your ability, and not just whether you meet a certain bar. Naturally, they will pick a problem that they think they know better than you do. If they stump you, or point your mistakes, the way you react is likely more important than the fact that you made a mistake. "

I couldn't have said it better.


My last interview at Google .. the interviewer behaved like a prick. His attitude was .. oh .. u have a PhD ... let me show you how much smarter I am than you. This was very clear from the first 2 minutes of the interview. What is funny is that the area I was interviewing for is my forte and Google isn't leading there. Anyways .. it pissed me off so bad that I am saying no to future interviews. Life is too short.


I've been interviewed by "bar raisers" who apparently have the goal of insulting you.

One kept asking me the question incorrectly. Mostly because I was baffled, afterwards I googled the question. Ah, correct answer was "Naive Bayesian Classifier", like used for spam filters. Of course. Nothing about the job or my resume was related to spam filters.

After much grilling, another ultimately told me that my extensible grammar that handles many dialects of SQL was trivial, because ANTLR did all the work. Unfortunately, I shot back "Ya, and my C compiler writes all my code for me."


> the interviewer asked "What is your favourite language?". My head wasn't in the right place at the time, and I said "Latin", and I went on to describe why I think Latin is such an interesting language.

Hire this man. Stat.


This is the only correct answer if you wanted to work as a programmer at the British Civil Service. This is why GCHQ can never hire anyone.


I might have responded the same way if I had to wake early. My Latin knowledge, unfortunately, has not landed me a decent developer job either.


Next interview question should be:

Write a simple calculator that uses Roman numerals as its only internal representation of a number


My recommendation for preparing for tech interviews at the big tech companies is to answer as many questions as you can from here:

http://www.programcreek.com/2012/11/top-10-algorithms-for-co...

Use coderpad.io to write code for practice passing the phone screen.


My recommendation is to write a polite reply saying why these are a waste of time and why you won't be doing it, and ask them if they are still interested in interviewing.


I actually did that a few times, most of them run away from me. I said I don't have patience to do linked lists, determine if 4 points form a square type of questions, etc, as that does not prove anything. It is easy to game the system to pass these questions, but then most people that passes writes the most horrible un-maintainable code.


My favorite is the ONANDA interview: the first time they ask about cycles in linked list and he tanks completely... then the next year he tries again, they ask the exact same question and he aces it.

So the trick to a good interview is... know the questions in advance so you can google them beforehand?


I'd say that this is kinda okay - if they'd asked him the same question, and he hadn't improved, it would've shown that he doesn't have much in the way of curiosity / doesn't want to improve.


But they've just wasted 1 year. They should have tried to figure out if he has the required curiosity in the first interview itself.


Wow. That seems like a lot of work to get a software job. This guy seems pretty knowledgeable too. Has it always been this hard to get a job as a programmer, or is this just a symptom of the times?


No, the process is horrendous, especially for the competitive companies. Just look at Google's process: talk with recruiter, 1-2 phone screens, 5 on-site interviews, and then a couple phone calls with teams. All before you get an offer. Absolute nonsense.


A friend of mine interviewed with Google up here in Boston. Got flown out 4 times because of blizzards closing the office before they just flew her out to Mountain View all before telling her that they weren't going to give her an offer because none of the teams had space.


I think that's the worst part about Google's hiring practices. You nail the 5 interviews, pass the hiring committee, the executive committee, talk to teams and then someone finally tells you "we don't have any position for you, sorry". A very standardized process isn't always a good thing, not everyone is an interchangeable cog, fresh out of college.


I think this is unusual for Google though. I'm not saying it can't happen but I don't think this is the common case.


True, their hiring process is data driven (like everything else) so it must be rare.

But it's not the first time I hear such story and I'm sure it must leave a pretty bad taste in your mouth. Nothing similar happens in Amazon, Microsoft, Facebook, Apple... AFAIK.


Happened to me as well; also in Boston.


That wasn't the real reason. They would have offered other teams she could have joined.


They flew her out 4 times because of blizzards? That doesn't make much sense. Do you mean her flight got cancelled 4 times because of blizzards. That would not be Google's fault.


I've been introduced to this recently as I had not lived in bay area before. Apparently when one of BigCo's recruiters contact you saying they really like your experience and it would be a good fit for X, what they really mean is "Please jump in our interviewee grinder because we aren't getting enough volunteers." They just dump you into the usual pipeline without any discussion on salary range or an attempt at selling the company/role. I get hit up by multiple recruiters every week day; I don't have the time to entertain this bull or do full-day marathon interviews with zero sense of mutual interest. Luckily I only wasted an hour with one of the BigCo's before I caught on; if they get back to me I'll have to politely extricate myself because I will not be taking off time to go in for full day interview sessions.


I got this from Amazon, we really like the look of you, now do a two hour coding challenge without knowing anything else. Sorry I have 14 years experience on my CV and better things to do with my time.


Then do it 2-3 times because their amazing process tends to get it wrong.


That doesn't sound like an amazing process.


This is also a way many companies prevent their engineers from leaving.

The act of switching a job is PAINFUL. Most people stick to their jobs for as long as they can just to avoid the pain, pressure and stress.


All my interviews in my past few months have been in this format.

1. Talking to recruiter ( 0-1/2 hr)

2. InterviewStreet coding challenge ( 2 hrs)

3. Phone Screen - 1 hr

4. Take home coding exercise - 4 hrs

So you are spending 8 hrs just to get your resume looked at. Then comes onsite interview which is another day ( assuming you are not flying out).

All this is not counting prep time to brush up on bigo/algorithm stuff. I was speaking to a fellow interviewee at google and he apparently spent over 4 months of everyday practice for the interview. So no way you could compete with without serious dedication.


I truly don't understand the point of having both (2) and (4). Could someone here who runs a process like this comment on what signal they're picking up from (4) that they aren't getting from (2), or vice-versa? If the InterviewStreet stuff isn't good enough to demonstrate at-home coding skills, then why not just do the take-home exercise? If it is good enough, then why not skip the take-home exercise?


i think 2 is coding/problem solving test and 4 is design/software engineering test.


Getting usual software job is not so hard. I think he was not after "usual software job", but after one that is hard to get (job at Google, Facebook etc). I find what he wrote very valuable, being a person that has similar aspirations (Google is my holy grail) that was very helpful.


Why is working at Google your holy grail? I'm genuinely curious, I don't have a problem with your goals.


I am interested in ML lately so i like and understand their current approach to solving problems with it. I think that they are leader in "AI race" at the moment seeing how DeepMind is evolving and how they use ML in their products and optimizing their own infrastructure with it. I think I could learn a lot there. I always liked challenges and solving interesting problems and in my opinion Google is a good place to do that. I am not mentioning things like scale etc because that is common in other companies also.


I would disagree. Google has beyond genius PHD's working one those problems. A SE with a bachelor's would most likely be delegated menial tasks, definitely not be working on cutting edge research. I have many friends at Google and, unfortunately, it's scale would not allow one to work on the problems you stated with out significant leverage and movement internally.


I disagree. I also know someone that works in one of the ML teams and he has just a bachelor's and is not relegated to menial tasks and seems to be pretty happy with his level of responsibility.


Because google on your resume opens many doors. eg: vc funding.


Why is Google ( or any other employer ) your holy grail? Is getting hired at a big five employer seen like the Olympics of software development or something?

I'm genuinely curious.


Google is one the few employers that where if you perform well you can get to a 250k+ comp within 5 years. The pay difference between Google and most other companies is quite big after a couple years.

There are obviously other options but Google is one of the few employers where you can say "well if i hit expectations I will be making 250k".


I know of many jobs where you can get that high. Most of them are soul sucking jobs calculating mind numbing numbers for insurance companies.

Google is likely to have interesting jobs where you can get that high which would be big.


please, i'd love to know specific companies (seriously).


Hey, if you are still interested, I replied to RexM below, he asked similar question first.


Well I just reading about Jan Kuam and how he was rejected at Twitter and Facebook and then founded WhatsApp. And came over here to see interviews stories. I guess the process is not that great. I have interviewed with a few big companies myself including Microsoft, Google and Yahoo! and must say that sometimes the result of interview depends upon who is interviewing you. So I guess the lesson here is to keep giving interviews till you find(or make) the job that you want.


> I will claim that startups (say less than 20 employees) are more likely to be seeking talent

I've always had the impression that start ups are looking for skill because they can't afford to pay someone while he/she ramps up on the technologies used.


I am 42 years old and own and manage a successful bootstrapped online business. I "grew up" in an IBM community, going from IBMer, then the business partner community, and I haven't been on half this many interviews in my entire career.


I love the comment about being prepared for many types of interviewers.

I had an on-campus interview with Microsoft last year for a pm internship. The interviewer immediately said, "your resume says you know F#, implement xyz algorithm with this function signature." He had a thick Russian accent and a mean face. Normally I would have had no problem answering, but I was caught off guard and panicked. Its good to be prepared for that kind of unusual circumstance and I will be next time.

He ended the interview with 'Maybe try again next year.' Ouch.


The author brought up some very valuable points I thought which aren't often talked about. Namely whether the requirements are skill based vs talent based and the time horizon of the employment. They also have a good sense of humor. This was a good read.


As an incoming CS student who is terrified of interviewing this is an absolute treasure-trove. But this also makes me wonder--should I forego interviewing until after having taken an algorithms and data structures course?


A job in the IT department of a business that doesn't specialize in technology could be a good start. My company will hire interns who have completed only their freshman year of a CS or similar program and give opportunities for real work, but we are not nearly as rigorous with technical interviews. It may not be a good landing point for someone who only wants to be technical, but it's been great experience for many who have gone on to everywhere from Microsoft/Google to start-ups.

I work at a food company in the I.T. department in a development-centric role.


Yes. Do the course first.


Or read a book and implement and understand the basics. You don't necessarily need a course to learn algorithms.


Thousand times yes. Also it will make you a better developer. Increase the size of your toolbox and all that.


For the caliber of companies on this list, overall that's a really shitty experience.

The takeaway: treat interview prep as simply learning the realm of possible questions. (Sounds impossible, but not really.) Rote memorization FTW!


The author is a great writer and in addition to this article, I also enjoyed his biographical write up of his time at the University of Waterloo and his co-op terms:

http://www.robertelder.ca/my-uw-journey/

I like his anecdotal style, punctuated with his perspectives. He's quite humble, despite clearly being quite smart (in my estimation) and hard-working. I particularly liked his section on Interviews.


This is very well written. Thank you very nuch on this! I will read it few more times and write thinga down in my notebook as a reminder!


My own story of how I got hired at Amazon, back in 2008: http://brunozzi.com/2008/05/22/how-i-got-hired-by-amazoncom/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: