Hacker News new | comments | show | ask | jobs | submit login
Amazon software engineer interview (sobit.me)
241 points by sobit 527 days ago | hide | past | web | favorite | 180 comments



This article makes me sad. Interviewing in our industry is so broken. I have been out of school for a while and switch jobs every few years and this is the technique I use to beat the bullshit interview process

. Make a list of companies that I would apply to and sort them from most interesting to no-way-in-hell-i-am-working-here order

. spend a weak reviewing typical algo/data structure questions

. For the companies that I absolutely want to work for, I review every single glassdoor review and write down the interview questions. Remember, most companies have question banks and most interviewers have favorite questions which results in same questions being asked over an over again. You want to exploit that

. Then to get over my interviewing jitters, I interview at a few companies where I would absolutely not work at. This results in no pressure interview practise and you can literally laugh at their asinine interview questions and walk out

. Finally, for the companies i actually want to work at, I try my best to get rid of phone screen. This is usually accomplished by dazzling them with my decent size github profile, contributing some fixes to their OSS project or finding someone who already works there that is in my alumni network

. Then when you finally arrive for the interview, you have real world interview practise, they are already impressed with your github profile/references and biased toward you versus some random joe off the street and you have made sure you have a pretty high probability of getting a question that you have already seen or is similar to a question you already know.

This technique has helped me get Jobs at top 5 employers in the valley along with a few startups. The reason I am posting this here is to demonstrate how broken, unfair and easy to game this whole process is


Studying algo/data structure questions is not gaming the system. I'd far prefer to hire someone who did this over someone who didn't prepare and just tried to wing it, then complained about how unfair it is to ask such questions.


Why is that? Besides preparing for understanding the role, culture, etc why would you need someone to brush up on their algo knowledge for your job interview? Do you believe that algo prep would make them better at their job?


Perhaps the willingness to prepare indicates the candidate is motivated and the algorithmic knowledge they gain from it forms a solid basis and language in which it is possible to test their problem solving abilities?


Right. I figure also that a candidate who'll do the homework necessary to prepare for the interview rather than winging it will be more likely to do the homework necessary for the real problems he'll face at work.

(I've known many engineers who wing things at work rather than spend the time to research a correct solution, and not just in software.)


Hi Walter, nice to see you again; another (similar to last time) interview process, another discussion here :) Not sure which country you are from, assuming US here; seems your experiences, again, vary wildly from what I see here. The refusal to study this useless stuff upfront had absolutely no baring on their 'refusal of whatever' on the workfloor or 'winging things at work'; employees should refuse things that are a waste of time in my company and they should explain why. If they do that with this 'pre-interview studying', I like them more than the ones who cram all to please the interviewer and show their willingness to do whatever they are told. I think that might be Dutch attitude though so not saying right or wrong here. I think, considering your previous responses that you mean it more subtly as well though.


> absolutely no baring

That's not been my experience. I've seen a strong correlation.

> show their willingness to do whatever they are told

I don't think it's the same thing. I've told many of the people I've worked for that what they asked me to do was a waste of their resources. One told me "do it 'cuz I'm the boss and I say so" to which I replied "at the salary you're paying me, I feel obliged to tell you that what you're asking will never work". :-)

Nevertheless, if you know upfront that at a job interview you will be asked certain questions, and you choose to go to the job interview, it seems bizarre to not come prepared. Why bother?


> That's not been my experience. I've seen a strong correlation.

Like said, might be culture or maybe I have been lucky.

In my country (I haven't lived there for a while so might've changed but I don't think so) and my company we were not so salary obsessed, so 'at the salary you pay me' is a phrase used never in our office of few 100 colleagues. If you make 5 or 9 figures a year; if the boss tells me 'do it cuz i'm the boss' I'm not doing it if it's a stupid idea and I expect that from my colleagues even if I outrank them technically.

So still thinking it's culture as well; here you cannot fire people easily; you have to make a dossier (with obvious mistakes/flaws etc) and go to a judge and then pay them a few months. So there needs to be much more of a trust relation than master/slave relation imho. Note that we only needed that twice when the employees where watching/downloading pr0n all day. One was a junior designer and the other a phone support employee for our cms.

Edit: btw, i'm not saying I like that system per-se; in some countries (like Spain) it goes too far and you won't hire people because you can't fire them, but in NL I had no actively sabotaging people (you can't fire me so I do just enough); quite the opposite, while in Spain I meet too many of them.


I don't know if it's a culture thing or not, but if I'm paid low I expect I am being paid to do what I'm told, but if I'm paid high I expect that I am being paid for my expertise, and that includes advising the boss. (It's not about being obsessed with salary.)

None of this should be construed as a master/slave relationship.

For an analogy, if I go to McDonald's I am not interested in the opinions of the cashier, I just want to pay the money and get the burger. If I'm going to an expensive restaurant, I'm interested in the opinions of the waiter about what to order - that's part of what I'm paying for.


I'm not doing homework if I'm not getting paid overtime. XD


> why would you need someone to brush up on their algo knowledge for your job interview? Do you believe that algo prep would make them better at their job?

Ahem, Walter writes programing language compilers for industrial use. I strongly suspect that algo prep will make them better at their job if he was involved in the hiring :-)


Actually, if you asked me cold about various algorithms, I'd probably bomb the answer. But that isn't a problem, as when I need to know some detail it's trivial to look it up. But if I'm going on an interview for a job I cared about, and I expected algorithm questions, I'd consider trolling up on that stuff to be required homework.


That's an approach I don't understand. If you would "bomb the answer", it means you don't understand and don't feel the algorithm behind. Merely "looking up some detail" doesn't help with that.

It's not like one can look some detail up when he doesn't remember the detail was even there. Good software programmer needs a large working set of such details to sensibly function in a professional setting.


Being an educated person is not necessarily being a walking encyclopedia of detail. But it is knowing where to find the information needed at the moment. That's why there are reference books for professionals, like the CRC Handbook.

For another example, nobody knows every detail in the C++ Standard. But a professional is expected to know how to look up a detail in the Standard as required. That doesn't mean he doesn't understand the language.

Maybe you never need to look anything up. But I'm not that kind of person, and don't know anyone that is.


> Maybe you never need to look anything up.

It's not like that. I do need to check various things, and I daily run `man whatever' (I'm a sysadmin in large part). But even though I often don't remember what was the switch for e.g. `grep' or `find' or `awk', I wouldn't "bomb the question" about that. I would just substitute a sensibly sounding switch, explaining that I'm doing so (and why) and what the switch was supposed to do.

The same stands for algorithms, data structures, or program architecture (in other large part I'm a system programmer). I don't remember how AVL trees do inserts and deletes (frankly, I never learned that properly). I don't remember exactly how inserts and deletes work in B-trees. I never implemented my own hash table. But I still wouldn't "bomb the question" about any of those, because I understand how they work, and the details either can be worked out pretty quickly, or most often are not important for a particular question (unless, of course, the question was "how to insert an element into AVL tree"; then I can at least give high-level answer before calling for data structures handbook for lower-level work).

Heck, I don't even remember most of the cryptographic details. Every time I need to explain RSA or ElGamal encryption algorithms or Feistel net, I need to derive the formulas (I typically don't have any reference handy).


Not to mention the grandparent suggested showing them his GitHub profile and committing fixes to their open source repos. Uhh, yeah, I'd hire you too! Are we forgetting that most developers don't have GitHub profiles or aren't able to patch open source projects.


>>Then to get over my interviewing jitters, I interview at a few companies where I would absolutely not work at. This results in no pressure interview practise and you can literally laugh at their asinine interview questions and walk out

This sounds very unethical and dishonest. It's the equivalent of a company interviewing a candidate they have zero intention of hiring, ever. Why waste people's time?

edit: not sure why I'm being downvoted. Am I wrong? How would you feel if you spent time preparing for an interview, did the interview and then found out the company didn't intend to hire you in the first place?


You are right, this is not ideal - this is waste of time. Which is probably why the OP lead the comment with:

> This article makes me sad. Interviewing in our industry is so broken.

Yet:

> It's the equivalent of a company interviewing a candidate they have zero intention of hiring, ever.

If the company has one position to fill, and if they ever interview/contact more than one person for filling that position all the people who they contacted other than the person who got the job has wasted time, right?

In short, companies have only themselves to blame for this (sad) situation.


>>If the company has one position to fill, and if they ever interview/contact more than one person for filling that position all the people who they contacted other than the person who got the job has wasted time, right?

No, this is more like the company interviewing people when there are -- and will be -- no positions to fill. It's like a hiring manager going, "man, I really need some practice interviewing people, I should go post some jobs on job sites!"


Companies reject candidates (and thus waste their time) for extremely arbitrary reasons. I'd suspect you're being down-voted by those who feel they've suffered such.


Thats a great process. If you don't mind me asking, how do you get rid of the phone screen, even assuming you have some github and contacts? Just ask the recruiter?


the trick is not to go through the recruiter. Instead ask Committer on their OSS project or your internal contact to vouch for you to the hiring manager.


I have exactly the same experience. In my case I took first interviews where I actually wanted to work and didn't pass them. I did interviews where I didn't want to work later on and passed those. Then used my FB offer to bump up offer at the place that I chose among those where I passed.


Thank you for sharing your method with us. It worked for you and should work for others. I'd however like to point out, certain assumptions baked into this, before anyone starts to follow it:

>>. Make a list of companies that I would apply to and sort them from most interesting to no-way-in-hell-i-am-working-here order

This is easy to do if you're in the valley/NY. Outside of the valley, people often don't know many companies besides G and F. Making such a list is a valuable exercise, but quite hard for many people, simply because of lack of knowledge and credible sources. It'd be useful to mention something like Wealthfront list here.

>>. spend a weak reviewing typical algo/data structure questions

There are SO many resources online, that it's very easy to get lost in the search of what's typical, especially if one hasn't interviewed in a few years. It'd be useful to mention to follow some introductory book/resource here.

>> . For the companies that I absolutely want to work for, I review every single glassdoor review and write down the interview questions. Remember, most companies have question banks and most interviewers have favorite questions which results in same questions being asked over an over again. You want to exploit that

For companies with shorter history, this is doable. For companies with longer history of this kind of interviewing, browsing through Glassdoor is very similar to dumpster diving. It's doable, but it's super easy to get discouraged quickly. Not to mention very often people paste questions very vaguely e.g. "got asked a Graphs question", or they paste code which is a nightmare to follow, even if you trust that it's correct.

In other words, note that this phase can take a lot of time to do well.

>>. Then to get over my interviewing jitters, I interview at a few companies where I would absolutely not work at. This results in no pressure interview practise and you can literally laugh at their asinine interview questions and walk out

Again, how does one get interviews at even those companies where they don't want to work at? Getting interviews is as much of a problem, as clearing them. Added to that, there is always this anxiety about rejecting those offers, because there is no guarantee of getting thru the ones you want to work at.

Additionally, when picking practice companies, it's important to pick ones that have a process with similar intensity as your favorite ones. That knowledge is often not mainstream.

>>. Finally, for the companies i actually want to work at, I try my best to get rid of phone screen. This is usually accomplished by dazzling them with my decent size github profile, contributing some fixes to their OSS project or finding someone who already works there that is in my alumni network .

Internal referral is definitely the best way. But majority of people don't have internal warm referrals at most places. Additionally, unless your technical reputation precedes you, most good companies are unlikely to give you a free pass on phone screens. It's extremely rare to have a dazzling Github profile enough to skip a phone screen.

>> Then when you finally arrive for the interview, you have real world interview practise, they are already impressed with your github profile/references and biased toward you versus some random joe off the street and you have made sure you have a pretty high probability of getting a question that you have already seen or is similar to a question you already know.

This again, assumes that everyone in the panel knows about your preceding reputation. And that one doesn't mess up even a single interview.

Overall - please don't get me wrong - this is great advice and much better than getting frustrated without it. What I want to point out, that the inherent fragility of the entire process is so high, that one should be careful pinning one's confidence on any particular strategy. The only thing in your hand, as a candidate, is to prepare and prepare well.


I'm all for interview prep, but this sounds like a fairly standard tech company loop.

I usually take a few days to brush up on algorithms and structures for the first one I do in a batch, and have some canned answers for the personal questions, but otherwise go in with what I know. Some of that's experience now, but I don't remember any point in my career where I'd have done something this extensive. I hope the poster doesn't feel they need a month's prep every time they want to go test the waters on the job market!

I do agree with the frequent recommendations for Cracking the Coding Interview. As a lead who interviews frequently, my biggest tip is to be honest about what you do and don't know--take what you do know right to the limit then talk about how you'd figure out the rest given normal professional time and resources.

I'm not usually grading someone on whether they can solve my specific problem so much as whether I think they're someone I can work with while they do it. That said, if it's on your resume you'd better be able to talk intelligently about it to whatever level makes sense for your experience. I definitely probe around that stuff to figure out if I can trust the rest.


I had this view when I was interviewing for internships during this quarter. I have spent working and interviewing at a couple of places, before I came to pursue my masters and I believed people valued coming up with the solution on the spot.

I interviewed at atleast 10 places for internships and every single of them asked one of the questions from either leetcode or cracking the coding interview. I found none of them cared whether I am thinking on my feet for a solution or not. As long as you can reproduce the answers to the questions in a nice manner, you got selected. None of my interviewers were trying to understand / empathize how difficult it is to come up with a solution really quickly when you have not seen the problem before.

The thing I learnt through the ordeal is 1. Nobody cares whether you are thinking on your feet or not. 2. You need a month of preparation going into these sort of interviews.


>>I found none of them cared whether I am thinking on my feet for a solution or not.

There are section of people among programmers who give away tens of hours of time per week on sites of the likes you mentioned, these people have no other hobbies, hardly do any other productive or creative work, have no real social circle and generally spend all the time of their life in 'karma hunger' kind of a pursuit for points in solving some thousand people like themselves already solved.

Now they have to justify all mega massive wastage of time by at least making it look some kind of an intellectually superior activity which other people are incapable of. They might as well fail a few people in the interviews to get some consolation for that kind of wastage of time.

Everytime I see people spending scores of time on these leetcode kind of sites, I'm reminded of exams in India, where students just sit down and mind numbingly practice several years of question papers in hopes of finding similar questions or sometimes the same questions with minor modifications in exams. Finally you get students who barely know anything at all but pass the exams with high marks.


I've heard a school of thought that being good at those games is actually a yellow flag because you get conditioned to code fast, not well.

That said, I love those games, so screw that. I just don't confuse them for being a gauge of someone's professional value. They probably correlate some with intelligence, but that's only one piece of the puzzle and probably not the most important piece for the grand majority of hires. Communication, work ethic, and creativity are probably more what I'd look for there.

My guess is a team made up mostly of "just above average" people would probably coordinate and communicate better than a team of "genius programmers" anyway. So there's a bar, but from there it's not as simple as smarter is better.


I wish I could upvote this more than once!


> I believed people valued coming up with the solution on the spot.

So I 100% agree with this. Being intuitively clever and being able to apply what you know is intrinsically valuable:

Think of the extreme, imagine someone who is unable to apply something they've learnt unless it's exactly in the context they learnt it.

That said, I think it's often underestimated how valuable prep is. Some people even get a bit salty over it, people who are unwilling to "jump through the hoops".

As a teacher, I've seen all kinds of people, people who need absolutely nothing to figure out things on their own, whose limit is only their imagination. On the other hand, there are bright people who need a bit of guidance but are nonetheless otherwise very brilliant.

We are the sum of our experiences. How we've arrived at our present is completely unrelated to other people's. Some people have had parents who are scientific, other people were hacking consoles/linux/coding since they were 10. Other people got bored with their careers and decided to try something new in their late 20s.

Who's to say a month of prep is too much or too little to get ready for an interview.

Though, to the people who want to derive everything on the spot, I'd ask:

"how did you figure out how to start a fire?"

"when did you derive differential calculus?"

"how old were you when you solved the schrodinger equation?"

My point is, "solving something on the fly" is a misnomer. Without a doubt, it takes intelligence to apply a combination of tricks to a new problem in an unfamiliar context. But trying to come up with a solution when you've never seen the trick is a completely different ballgame, and its worth trying to see the picture from a different perspective.

Is the interview process flawed? Well that's an entirely different question ..


I am not talking about inventing data structures or an algorithm on the spot. It takes some amount of time to find the right data structure and the algorithm. I felt that the interviewers are not ready to give that time.

Say you have not seen a particular dynamic programming problem. It takes some time to get to the fact that there is a recursive solution to it, and then apply DP to it.

For a person who has seen that problem, it doesn't take a lot of time to write the code. While interviewing, you are compared to that person. Nobody takes that extra effort to actually appreciate somebody who thought about the problem and answered it.

For a tech industry that prides itself in hiring the best / most talented, this is ironic.


The thing is, that Amazon/Facebook/Google are in the unique position of having too many applicants, not too few.

This is by no means vindicating their process, merely shedding some light on it. A bit like case studies and consulting...

Edit: though on that note, a good case study will extract / give a candidate the opportunity the opportunity to demonstrate key competencies aligned with consulting, much as in the same way solving some algorithm on the spot is a reasonable proxy for being a good googler. The only problem is it has a high false negative rate...


They've got an absolute shit-ton of recruiters out there manufacturing those candidates. I've never done an on-site Google interview (never the right timing) but they hit me up once a year trying to drum up interest. And then every one of those drummed-up interview loops takes time from their engineers who could be working on stuff.

They could probably do better for themselves as businesses with an interview process that looked for skills that are necessary to get the job done (not white board big-o olympics) and sufficient to get the job done (not white board big-o olympics).


That's a shame. When someone sails through something I gave them, I usually kick myself for giving them a crappy or cliched problem and assume they've probably solved it previously. In that situation I absolutely am trying to figure out if they at least understand the answer so I'm looking for them to talk through, etc.

Coding on the board is a broken process anyway (just one I rarely have the influence to redefine wholly) but coding on the board as a "closed" interview question is downright stupid. You learn absolutely nothing relevant about the candidate, and they learn absolutely nothing about you. I'm sorry to find out that was the bulk of your experience.

FWIW, once you get enough experience to pick and choose, that would be a bad smell for me interviewing at a company. If I feel like there's no rapport and I'm just getting grilled in an interview past the initial tech screen, I will and have stopped the process myself. Life's too short to be a cog.


This was my experience for new grad roles. The "we're grading the person, not the answer" is normally bullshit.


Interesting and valid points. I have some things to add.

Disclaimer first: I'm a technical interview coach. We run http://InterviewKickstart.com, which provides structured and intense group programs for early and mid-career software engineers, with the sole purpose of preparing for technical interviews.

In an ideal world, brushing up is all what it should take before going into interviews. Practicing Software Engineers shouldn't need to spend months working through books and courses. Interviewers should be thoughtful enough to interview for the thought process and experience, more than DS and Algos.

Trouble is:

* Many interviewers are not that thoughtful. Even for the most well-meaning ones, it takes a few interviews to truly be good at judging someone in those 30 to 60 minutes. If a candidate is caught into the cross-hairs of an interviewer's learning curve, that candidate is not going to get a fair evaluation. Preparation helps in that situation.

* With the plethora of prep material available for past several years, the bar for interviewing has just moved higher and higher at good companies. If you look at G and F (and some others), there is no way you can get away with just knowing the basics of trees and binary searches. It just takes time.

e.g. If they ask you to merge sorted arrays and you don't know that Heap sort is the best way to do it, you've lost the interview no matter how clear your thought process is. Not because the interviewer is not watchful. But because your competition has solved it with Heap Sort. So even if both of you demonstrated a clear thought process, the other person gets the job, because s/he is more prepared.

* It takes a certain level of life-confidence to just go to an interview with what you know and take the rest head-on. Many people don't have that kind of confidence. Many many engineers are introverts, and to borrow an analogy from sales, they are artists, not hunters. They are equally ambitious as hunters, but their confidence comes from systematic, extensive, honest preparation, and not from experience thinking on the feet. That prep easily takes months, especially when they are doing it part-time.

* Most CS colleges do not actually prepare their students for interviews. Some top ones do, but a large majority of them are not calibrated to churning out students capable of handling interviews at top tech companies. If you went to one of those colleges, and want to try for better companies, you have to prepare explicitly and separately. You have to re-learn CS with a level of specificity, intensity and extensiveness that your school never provided. Yes, you only have to do it once, but that one time, it may take many months.


> e.g. If they ask you to merge sorted arrays and you don't know that Heap sort is the best way to do it, you've lost the interview no matter how clear your thought process is. Not because the interviewer is not watchful. But because your competition has solved it with Heap Sort. So even if both of you demonstrated a clear thought process, the other person gets the job, because s/he is more prepared.

Sadly, there's a ton of very qualified software engineers that make up this "competition" that you speak of, and still lose. Meanwhile, there's another group of people that realize how ridiculous proving yourself in that way every few years throughout the course of one's career is, become sales engineers, and make more money. They also don't have to have a whiteboard pissing contest anymore over such things.

I really wonder if lawyers who have been practicing for 7 years, or consultants from the Bain's and McKinseys of the world get asked questions about classes they took in junior year of undergrad when they interview.


Your frustration is justified. However, there is no flawless interview process. You could try and read this for more context: http://www.gayle.com/blog/2015/6/10/developer-interviews-are...

Having been on the other side for quite a long time, I can assure you that despite best efforts by some very well meaning and smart people, this is the only process that has stuck around (and is still growing). That's because it's the most convenient method to interview at scale.

When a company is very small and/or only hiring one or two engineers a quarter, choice of interviewing method doesn't really matter a whole lot. You will have enough time to interview people and any method you follow will give you a decent candidate.

But when you are a coveted company with a strong candidate pipeline and are tasked with hiring 25 engineers a quarter (which was the case with the leadership team I was a part of), or thousand at Google scale, you need a process that is fast, efficient and convenient. You don't necessarily need a process that's best for candidates; as long as the process filters in enough candidates, and doesn't waste much of your team's time, you're good.

There are some other reasons this process has stuck around, but that's one main reason. I don't see it going away any time soon.


This is a really awesome response, coming from an expert in the field.

It makes me a little sad to read some of this, since it runs a little counter to what I thought was becoming a more general understanding about how to and how not to interview candidates. I give search/social companies a pass because the algorithms and graph theory are core skills there, but in general it's well-known that any kind of closed question isn't all that valuable in an interview, tech or otherwise.

I don't see programming problems any differently. Looking for a "right" answer just means they know what you know and maybe think like you think. It's a very egocentric way to proceed, to be honest. I don't need a team of me!

But it does open my eyes a bit to the fact that new grads may have a pretty different experience than others. I'll try to keep that in mind in the future. I don't want to interview this way, but if I know someone has expected to interview this way it'll help me understand them better.


> e.g. If they ask you to merge sorted arrays and you don't know that Heap sort is the best way to do it

Sorry, I'm confused. I love heaps, but... what's wrong with this simple O(n+m) time and space solution, that I can easily prove is the theoretical limit (because the output size is O(n+m))?

    def merge_sorted(a, b):
        result = []
        la, lb = len(a), len(b)
        ia, ib = 0, 0
        while ia < la or ib < lb:
            if ib >= lb:
                result += a[ia:]
                break
            if ia >= la:
                result += b[ib:]
                break
            if a[ia] <= b[ib]:
                result.append(a[ia])
                ia += 1
            else:
                result.append(b[ib])
                ib += 1
        return result
    assert merge_sorted([], []) == []
    assert merge_sorted([1, 2, 3], []) == [1, 2, 3]
    assert merge_sorted([], [1, 2, 3]) == [1, 2, 3]
    assert merge_sorted([1, 3, 5], [2, 4]) == [1, 2, 3, 4, 5]
    assert merge_sorted([2, 4], [1, 3, 5]) == [1, 2, 3, 4, 5]
    assert merge_sorted([1, 2, 3], [1, 2, 3]) == [1, 1, 2, 2, 3, 3]


Ah, some googling got me here:

http://www.geeksforgeeks.org/merge-k-sorted-arrays/

Merge k sorted arrays. Obviously that's a job for a min heap (not heap sort though, just a heap to keep the values of the next item in each array).


Sorry I was not very precise there. Exact question is to merge K sorted arrays, size N each. A natural extension of that problem, is to have K streams.

First part can be solved with an extension of O(n+m) solution you proposed, but when it comes to streaming, Heap works better, with the same complexity, because you don't have to know the size of the arrays in advance: https://discuss.leetcode.com/topic/2780/a-java-solution-base...


> It takes a certain level of life-confidence to just go to an interview with what you know and take the rest head-on.

Apparently, I have that kind of confidence. In my experience, confidence is good for winging the personal questions and talking about my past projects, but at the end of the day technical interviews come down to being able to solve problems you'd never (or rarely) see on the job. If you walk in unprepared, you will fail. I usually fail the first 5-10 in my job search before I get a yes. Walking in unprepared is ridiculously suboptimal.

Just to clarify, I don't mean just the google style interviews where they ask you graduate level DS and algo questions. Thankfully, a lot of smaller companies are transitioning to asking questions about the tools, languages and techniques specific to the field. But, that still requires weeks of study because the level of detail most interviewers go into far exceeds what you see working on CRUD apps. Not to mention the difficulty of memorizing every CSS3 property available.


> With the plethora of prep material available for past several years, the bar for interviewing has just moved higher and higher at good companies. If you look at G and F (and some others), there is no way you can get away with just knowing the basics of trees and binary searches. It just takes time.

This is so idiotic. Asking about binary searches does not identify good candidates unless they're going to be doing a lot of binary searches.

If someone asks me stupid CS 101 questions in an interview it's a red flag to me.


I've been pretty seriously studying CS for a while, and there's a trillion things I don't know.

>If they ask you to merge sorted arrays and you don't know that Heap sort is the best way to do it, you've lost the interview no matter [...]

... no matter the fact that there are a hundred ways to sort an array, and you think you know the best one? Has it been proven the best, or is it just the best you know? How many ways do you actually know to sort an array? Has all research on array sorting ground to a halt because there's no better way to do it?

If someone asked me the best way to sort an array I'd say "probably radix sort." If you expected "merge sort," then you're the fool.

My point being, I study a lot, but that doesn't give you answers. I gives you a base from which further study can happen.


"Tell me more about the array you want me to sort" is the only valid initial response to "best way to sort an array." That said, the question posed had very little to do with sorting arrays and I'm not sure where your hostility came from.


My objections had nothing to do with the kind of question posed, only the expected response. Unless it's been proven that there can be no way to merge sorted arrays "better" than heap sort, it's flippant and erroneous to expect someone to give that answer. (And there are real reasons to not use heap sort for this.) Even if I don't know that this is the (supposedly) correct answer, they've learned little about my ability to actually merge sorted arrays, and even less about my general ability to solve problems.

Unless they're explicitly hiring me to merge sorted arrays, I'm not going to claim any expertise at at. There are probably hundreds of research papers on this topic, and I haven't read them all, and I know it. I understand that sorting is a big CS topic, but it's not the only CS topic, and I can go the rest of my carrier assuming someone else already solved it and never know how heap sort is implemented and still solve hard problems.

So they shouldn't ask that kind of question and expect such a casually incorrect answer. And they can't tell me "I've already lost the interview" if I don't see things this way, because then that might trigger some manner of hostility. I don't lose interviews when the interviewer expects careless and rote answers. The company loses.


His question was about merging pre-sorted arrays, not about sorting arrays. (Still, see my own disagreement in sibling)


what do i do if im a terrible person to work with? its something i really struggle with.


Assuming you're serious, there are a number of books out there about working with people with unfortunate personalities. I've generally found those kinds of books more instructive towards my own behavior than books that claim to fix your own personality. Sometimes you need perspective more than instructions.

My experience (both first and third-hand) is that being terrible to work/play/exist around often comes from not realizing what being around you feels like from the other side. Working with an asshole will go some ways towards fixing that. In the meantime, learning how to deal with them will make you recognize your own habits and maybe find ways to mitigate or fix them.

You can also find personality or career coaches, etc. They're just a bit pricy.


people don't have homogeneous personalities that allow them to neatly fit like bricks into office culture. the natural pressures of any business weed out the dissenters and those that can't quietly work with others or with the decisions being made or [... whatever your problems are ...]. Changing your 'unfortunate personality' (so condescending!) with a book is probably not the answer - you'll change naturally at your own pace in your own direction - but definitely consider going freelance or job-hop until you find somewhere you can tolerate working at. Not all people and organisations are shit, just most of them most of the time. You'll find your niche, my misanthropic comrade.


I'm sorry you found it condescending. I meant exactly what I said, because a personality is just a thing but some of them are unfortunate for the context in which you want to succeed. It truly is luck, and I called out it as such. Contrast with people who are deliberately hostile and deserve what they get.

We can debate neurodiversity and range of personality vs. dysfunction and "unfortunate," but the truth of the matter is some people do things that make them hard to work with and will make them hard to work with in any setting. Some examples might be as simple as interrupting and not letting anyone else speak, or always saying no, or never thanking people and always criticizing, and so forth. If you've never met one of these people then I'm happy for you, but they're not rare in tech. We're all a little mad here, as the old cliche almost goes.

I really have no idea what the OP's issues are that they were asking about--for all I know they think they're terrible to work with because of an inferiority or confidence issue. But my advice stands: get some perspective by reading about other people terrible to work with. Either you'll find out you're not so bad or you'll get the right input to tweak your own behavior.

I appreciate your advice too, but not everyone has to skills or opportunity to "freelance or job-hop" until they find something that works, and the idea that everyone needs to accommodate you while you find the right fit is laughable in the real world. We're not bricks but we're expected to supply our own glue code between us and everyone else, at least to the halfway point, and it's downright narcissistic to expect otherwise. And tight settings like Silicon Valley, you'd be surprised how easy it is to get a reputation as an asshole or team liability while you learn to do that if you're not crisp about it.

For 90% of the people out there, some small tweaks to behavior in order to learn to play the game is the right answer. I'm glad you've apparently found an alternate route to success, but I wouldn't dismiss the typical ways either.


Honestly, the old but still excellent "How to Win Friends and Influence People" by Dale Carnegie changed forever how I interact with people.

And, to answer a maybe obvious question, no the book isn't about manipulating people. It's more about dealing quirks of human nature and being excellent at negotiating and interacting with people. Can't recommend it enough if you're honestly looking to improve in that sphere.


I second this recommendation. I've also found "What Got You Here Won't Get You There" and "The No Asshole Rule" to be personally useful.


Contract or start your own business.


This. I'm pretty sure my Dad was a pill to work with, so it makes sense that he wound up quitting the corporate world and writing his own recordkeeping software that he sold to almost every county in California for over 20 years. Him dealing with Sheriffs would have been a great fly-on-the-wall moment.


You might be a more experienced person give you also regularly interview but for someone new I think 8 weeks is a good time to prepare.


This is totally crazy to me. Why should somebody lose about a month of his life to prepare for the interview? Why should the interview need preparation at all? The whole point of the interview is lost if you read books and prepare for that since you are not tested for your real on-the-work skills but you are tested for your interview-answering skills, memorizing trick questions and solving toy problems!

I think that this whole interview business is bad for both the candidate and the company (that would hire an interview cruncher instead of somebody who can produce work). Of course it is good for everybody else that promotes this kind of thinking (hr people, interview books, interview coaches, recruiters etc).

The whole process as described in this article is offensive to me. I don't want to prove myself by answering trick questions to people whose only skill is asking them! It's too bad we have dropped to that point.

(Please forgive my English - not my native language)


I didn't get the impression that the author took a month off work to do the interview prep; judging by the work load (3 exercises per chapter, a few STAR-format essays), it looks like the amount of time one would have after work and on weekends.

For someone working full-time it would be grueling, but no more grueling than the workload in an after-work Master's degree program.

I view the interview prep ritual as a necessary evil. Some companies prefer to give a take-home coding assignment. Amazon, Facebook, and the rest use this method to optimize for their interviewers' time. I think that "interview crunchers" DO correlate to developers who can produce work. I emphasize that many fantastic developers who produce great work perform badly in interviews. patio11 and tptacek address this with their recruiting startup, Starfighter.

Your English was flawless.


Thank you for your last comment :)

I'm not sure about how much time is lost for preparation to the interview in the general case (however I saw people recommending whole books in other comments) but the real issue is that even one day lost to preparing for something that you shouldn't prepare for is way too much!

I don't agree in comparing the interview preparation with the work for the Master's degree because, although both will lead somewhere if successful (to a Job offer or to a Master), for the Master you will learn something that is useful or you will advance as a human being (education) while, the preparation for the interview is just that: Preparing for an interview! Why should anybody waste his time like that?

I'm not really sure that people that are good at interviews are also good at producing work - this depends on various factors (i.e the interview process - I remember to my horror some legendary interview questions of the type "why is a manhole round"). I believe that such big companies could invent various other, much better methods to hire their stuff. For example after the candidate successfully passes a quick interview with some technical questions (but without any needed preparation) hire them temporarily for some months and evaluate them at the end.


I hear the temporary-work evaluation advocated on HN frequently, but this is a viewpoint almost exclusively held by junior developers. Those with families would find it difficult to accept the risk they may be terminated after the eval period. Senior developers aren't going to quit their job on the hope they won't be terminated at the end of the evaluation period. Job searching from scratch takes time and is stressful. Companies aren't going to spend half of the eval period training a new hire only to realize many of them aren't good enough (since they didn't screen them in a rigorous interview process). The risks don't align with anyone's incentives except for new grads, who have much less to lose.

I hear the argument, "if you know you're good, you'll make it," but if the hiring decision is pushed out to the end of an evaluation period, then the same arbitrary factors that lead interviewers to decline good candidates will also influence the long-eval period method as well. Case in point: Google Finance hires new grads almost exclusively from their pool of interns. Most don't make it, though many are talented. For a student, taking an internship is a no-risk move, since they will be returning to classes anyway. I can't a rational developer with a family accepting a similar arrangement: where the odds suggest she won't make it.


Agreed to your argument about the temporary-evaluation job being only possible for a junior developer and not to somebody that already has a job. However you should also add to them all the cases of senior developers without jobs (yes, such cases do exist) -- a temporary evaluation job is better than nothing.

Senior developers that have jobs won't take the risk of leaving their current job and going to an evaluating position. But these people also shouldn't be interviewed -- since they have already have jobs, a talk about their previous projects and work should be enough for anybody to decide if they are good enough.


Excellent point. Thanks for reminding me of this very important demographic.


> it looks like the amount of time one would have after work and on weekends.

If you're single with no children and no hobbies.


I agree with you on the idea that is definitely seems crazy to ask for this sort of prep from job seekers, and I also agree that such things do not do a great job of directly testing real world work skills.

However, I've worked for a couple of companies that had this sort of interview process, and I've worked for a couple of companies that did not, and I found that the quality of engineers working for the former is substantially higher than the quality of engineers working for the latter. Correlation, of course, is not causation, and there are many other reasons this could be the case. It could be that the sort of companies that tend to attract good engineers happen to all have a cargo cult-like obsession to this interview pattern, and good engineers actively seek it out. Or it could be that the sort of person who does well on these types of questions tend to also do well at programming by chance. Perhaps you could get nearly as good results by just asking candidates to, I dunno, build the tallest structure out of straws that they can manage in fifteen minutes.

Whatever the reason that it works, in my experience it definitely seems to. I'd love to hear suggestions for an alternative solution, though. Good ideas I've heard in the past involve things like pair programming on a real assignment for a day, although it's sometimes difficult to scale that to the number of interviews these companies need to conduct.


There are lots of companies that don't ask any technical questions in interviews - these will definitely make many bad hires, that's true - there are lots of "software engineers" that just can't program anything. I'm not against the idea of asking technical stuff in an interview or asking somebody to scratch you a small program. What I'm against is this whole business of needing to prepare for many hour/days just to go to an interview.

For the good-engineer going to companies with rigorous interview process argument, a really good engineer with high confidence then definitely wouldn't start reading books about how to answer interview questions and tricks but go to the interview without any preparation. However I'm not sure if he'd be better than a worse engineer that took the time to prepare for the interview...


Here's what they're testing with all the abstract/book knowledge - whether you can properly grow and understand the tradeoffs of common lower level patterns. Having no knowledge as to why say a hash table would be preferred over a binary search tree will lead to a person using one thing without understanding why. Yes, in general you'll be using the same few heuristics probably 90-95% of the time in real programming. In the cases in which you really need to optimize for max performance (because its company $$ on the line) or max consistency in performance (because its company/service reputation on the line) its worth it to find people who can do that. The cost savings of running just a few servers vs many is large, or the product could not be viable if it doesn't perform to a users expectations (see: anything in gaming).

For your average application development shop using tools provided, you can do very well by just applying heuristic techniques towards your domain. If you want to get a real competitive advantage in technology, you need to be able to develop systems that are optimized to a point. Granted, in Jr. or normal dev roles you will not be making many of these decisions - often a more senior or prinicple engineer will be working on the mission critical stuff.


Between bad interviews I've been in or read about and spending the past 6+ months working on our hiring process I've become very opinionated about hiring.

The process Amazon and many other tech companies use is fucking terrible. Algorithm tests and surprise CS 101 questions do not identify good employees. They're biased towards recent grads, do not address most real world situations, can be gamed through studying, and do not identify people who can actually think. You should not be testing for people who interview well, you should be testing for people who will make good employees.

You need to test real world scenarios. If they're going to be re-implementing bubble sort and doing binary math then fine, use HackerRank. Otherwise you need to have candidates work on a project based on what they'll actually be doing. Will they be working on APIs? Have them build or integrate with an API. Mapping in an iOS app? Have them do that.

Do not drop big surprises on candidates. Respect them and they will respect you. Tell them what to expect up front. The first email we send includes an outline of our entire hiring process with a list of each step. I've lost track of how many people have thanked me for this. Going through an interview blind is extremely stressful and increases the likelihood of losing good candidates.

My goal is to set people up for success. If their skills match what we're looking for I want them to succeed. I don't want them to fail because they are bad negotiators, didn't have time to study CS questions, or don't fit the typical stereotypes of a programmer.


Can you post an example of what a typical outline would look like?

As someone who interviews a lot, I'm quite interested in implementing a no-surprise interview process for the place I'm currently at as I too have been at the other end of a lot of bad interviews.


Here's an excerpt of what we send:

Before you make your decision, please read the following:

The OwnLocal Engineering team is transparent. We want to make sure you have clear expectations about our hiring process, so we've outlined for you. If you are unable or unwilling to complete our entire process, that's okay! The last thing we want to do is waste your time, so please let us know.

Our hiring process consists of six steps: application, phone interview, project, meet and greet, on-site technical & culture fit interviews, and finally an offer.

Phone Interview

The phone interviewer will ask about your background, recent projects, and ask questions related to the skills we look for. We’ll give you time to ask questions too.

Project

The project is a small application related to what we do at OwnLocal. You’ll work with mocked or anonymized data in the same format as our real data.

Meet and Greet

The meet and greet is not a formal interview, it’s a chance for our team and you to get to know each other. We hang out for an hour, ask each other questions, and discuss our interests.

If you’re not local we’ll do a video call instead with 3-4 people.

On-site Technical & Culture Fit Interviews

The formal interview is two parts. The first is adding an additional feature to your project with one of our engineers. This allows us to evaluate how you work with our team. The second part is contingent on the results of your technical interview. If you pass the technical portion, we'll ask you to stay for culture fit interviews with people from different teams.


Thanks for sharing. I wish more companies would do this as it alleviates some of the interview pressure from the candidate.


One more thing to add.

We've very picky. This year we've hired 1.3% of people who applied. It's not like our process is easier than the pointless ones others use. I'm sure we lose some good people along the way but at least we're not filtering for irrelevant criteria.


This is awesome. What company is this?


> Director of Engineering at Ownlocal (YC W10).

https://news.ycombinator.com/user?id=driverdan



In total I had a little less than one month to prepare for the interview.

I can't help but to wonder if it was really worth it. Surely, his prep helped him get the job, but the entire prep stage he describes seems like a very high up-front cost.

I've always felt that if I can't get through an interview with a little prep and my existing skills, I don't belong.

You should know exactly why you want to work for Amazon.

It would be interesting to know more about his desire to work for Amazon that badly.


> I've always felt that if I can't get through an interview with a little prep and my existing skills, I don't belong.

I have this feeling too, but I am not sure if it is warranted.

Let's do a thought experiment: grab an engineer at random, don't tell the interviewers that they are already a colleague, and subject to the same interview process as everyone else. Now, is this engineer going to pass the interview? Maybe, but I would not be surprised if most failed.

It's very rare that the interview process will actually test anything that's used on the job.


We've talked about doing that. My fear was always that I'd fail and they'd reconsider my own employment :)


The idea was to reconsider the interview process. But, in the corporate world, you never know.


Most will fail. Amazon actually has an internal hiring standard that the candidate should be better than 50% of their peer employees in the position they're interviewing for. This goals helps Amazon strive to always hire more talented employees..


I know that Google's recruiters have told me that they often end up hiring candidates on their second or third interview attempts; even at a company with a fairly standardized interview format, they get a ton of what they consider "false negatives". It seems like a related phenomenon.


I believe that's intentional - they prefer false negatives over false positives.


> Maybe, but I would not be surprised if most failed.

I used to work at a place where this was an actual goal: "we should always be raising the bar." Needless to say, that particular unicorn ended up shedding people pretty quick.


> It would be interesting to know more about his desire to work for Amazon that badly.

Amazon is basically the company I really, really, really want to work for, and the only reason I don't apply is that I have a small kid and a wife already working there, and I know how chaotic life would be if I did it now. So I'm waiting for the kid to grow a little more.

Now, the reason I want to work there so much is that I see them as the only big tech company providing actual value to society at large these days. Other companies have done it in the past, but it seems that now they only iterate on their old things or put out shiny but useless tech. Amazon on the other hand seems to be always coming up with new ways to innovate in ways that make people's lives more practical in a more real sense. I also admire them for basically having started the whole IaaS thing.

Another reason I want to work there is to learn. Few companies run large systems at the scale they do. From the outside (and from a little perspective I get from my wife, but she takes the whole "don't talk about what we do here" very seriously), they seem to have an awesome engineering culture - I was thrilled when I read the paper about them using formal methods to prove correctness of a number of AWS services. Working there must be a tremendous learning experience.


Your kid must be really smart :-) I actually admire Amazon from the outside for the same reasons you do but I'm not too keen on working there because of stories it's rough for employees. Does your wife like it? Is she a developer?


Haha, I should have proof read that, what a terrible sentence I wrote there :)

My wife's an engineer there and enjoys her work. Her team seems to be a smart and fun bunch to work with, and the hours are pretty ok. The only times I've seen her working extra were because she wanted to, not because she had to.


It's interesting to see how "whiteboard interview" prep mirrors standardized test prep.

What is frustrating is that the prep month (?! a month is an eternity) could have been used to contribute to an personal project of choice, which would have said a lot more about the author's ability to program.


>which would have said a lot more about the author's ability to program

It's my understanding that such a portfolio would increase your chances of entering an interview pipeline (just as work sample tests are sometimes used as further prerequisites to get into the pipeline), but a company's actual determination of how good you are is always based on the whiteboard, with few if any exceptions.


Oh, absolutely. I'm not questioning the author's decision to study rather than build something. The author's goal was to get a job, and he did the thing you do if you want a job. I've worked as an SDE at Amazon; it was a good experience and I wish the author the best. I just don't believe that the whiteboarding the author did to get the job was a good predictor of engineering ability. I think the wrong actions are being perversely incentivized, and I think that makes us weaker and worse-off as a community of engineers.


Spot on. I have an open source portfolio but am always judged instead on my performance during the interview.


Contribute to a personal project, socialize, learn a new language or framework, read books, etc. Amazing how many things you can miss out on with a month of "code" prep. And yeah, this definitely reminds me of high school a bit too much.


I used to believe this. As a masters student who is going to graduate soon, I have to put in months of preparation for the interviews. Nobody believes in your ability to write code even after having close to 100+ commits to a popular open source project. People expect you to come to the correct solution after 5 minutes of them asking the question.


IME the interview you have depends a lot on org size and how close the interviewer is to the money. A technical founder will tend to interview with an eye towards product and marketing and sitting down in a real environment to do sample code. As you go down the line and interview at bigger orgs with more departments, it becomes more specialized, the culture overwhelms the business, and you get more of the "idealized CS graduate" syndrome.


Meh, I never prepared for any interviews and I'm gainfully employed. Granted, I don't apply to companies who are known to give whiteboard challenges I have to prep for.


Yeah the world is full of idiots in charge. If someone is "in charge" then they are most likely idiots. It's the statistical truth. Look at the world today? Who can claim thag over population and a melting planet is progress? The world is run by idiots. Did I stress that enough? :)

The very idea of trying to control quality of anything complex (work, life, relationships, economy, etc) via some extremely shallow and arbitrary test is the most idiotic idea ever yet it is practiced on such a wide scale. The world is run by idiots.


This theory is called the Peter Principle [1], which posits that "in time, every post tends to be occupied by an employee who is incompetent to carry out its duties" and "work is accomplished by those employees who have not yet reached their level of incompetence".

[1] https://en.wikipedia.org/wiki/Peter_principle


> It's the statistical truth.

I don't think claiming something is a statistical truth without showing the statistics will fly on HN.


There's good arguments for their point. For instance:

"When something goes wrong in a restaurant kitchen, and the boss appears to size things up, he is unlikely to pay much attention to a collection of workers all scrambling to explain their version of the story. Likely as not he’ll tell them all to shut up and just arbitrarily decide what he thinks is likely to have happened: “you’re the new guy, you must have messed up — if you do it again, you’re fired.” It’s those who do not have the power to fire arbitrarily who have to do the work of figuring out what actually happened. ..."

"True, bureaucratic procedure operates as if it were a form of stupidity, in that it invariably means ignoring all the subtleties of real human existence and reducing everything to simple pre-established mechanical or statistical formulae. Whether it’s a matter of forms, rules, statistics, or questionnaires, bureaucracy is always about simplification. Ultimately the effect is not so different than the boss who walks in to make an arbitrary snap decision as to what went wrong: it’s a matter of applying very simple schemas to complex, ambiguous situations." (https://theanarchistlibrary.org/library/david-graeber-revolu...)

However downvoted the parent post is, it's nevertheless one of the saner observations coming from a species destroying itself.


Love it. Thank you.


So... be the change you wish to see? :) (Sure the world sucks, so there's constructive ways of tackling it and...)

Personally, I've found that a lot of stupid things are there because of downside protection or effort-minimization aka laziness from the primary stakeholders...


I tend to agree. In my opinion, if a job interview required me to brush up that much on a topic it either means:

a) the company is putting to much emphasis on "non-google" programming, which doesn't match reality (real software engineering isn't a closed book test).

b) I don't know the subject matter well enough and it would be a bad fit anyways.


> the company is putting to much emphasis on "non-google" programming, which doesn't match reality (real software engineering isn't a closed book test)

Maybe if you work on gluing together APIs then the googling aspect is more important...? In this case I find the term "software engineering" to be a stretch...


You would span that prep over more than one month if you're still in college. Then if you get to do some other interview later in your career, going over those same materials won't take you as long. so the up-front cost is paid only "once".

>I've always felt that if I can't get through an interview with a little prep and my existing skills, I don't belong.

The problem here is that your existing day-to-day skills are very different from what is being asked at the interview. See every Hacker news discussions about how broken interviews are. The author's job at Amazon is not going to be "how would you find the common ancestor of these 2 nodes in a toy struct Node{ int value; Node* left; Node* right ; }; binary tree"

For the brushup on algorithms and data structures I would add this one, missing from many books: Implement a simple queue based BFS/DFS algorithm on a toy graph (struct Vertex{ T data; std::vector<Vertex*> neighbors; }; use of basic data structures like std::queue and std::unordered_map/set allowed). Being able to code a sssp on an unweighted graph should be a doable objective.

PS: Another resource I enjoy that the author didn't mention : https://www.amazon.com/Programming-Interviews-Exposed-Secret...


Agreed. If I have to prepare for an interview, that means that the interview isn't testing what I use every day in my work, which makes it a bad interview process. I could do something more useful with that time, and I no longer feel like investing time jumping through artificial hoops like I did in school and college.


> I can't help but to wonder if it was really worth it.

It sounds like the kind of thing I might enjoy doing for fun, anyhow. It's my goal not to jump between employers. If I wasn't trying to find somewhere to stay for 5 or more years, then I'd be complaining about the up-front cost too.

> I've always felt that if I can't get through an interview with a little prep and my existing skills, I don't belong.

Ridiculous as it is, they're testing for things that your existing skills may not cover well, and that you may not have practiced in the last...well, since you learned it in school. You're trying to get a job doing things matching your skills, but the interview tests for something different (and arguably only loosely related). Still, that's the bar for getting the job.

> It would be interesting to know more about his desire to work for Amazon that badly.

For me, they've got local offices, so I wouldn't have to sell my home or leave the area my family lives in. They're a well-known company, and their engineering teams have a reputation for being picky. They also engineer for a scale that's hard to find in most other companies. If/when I decide to leave them, there would be the nice line on my resume where I can say I worked for them for x years. Of course, all of those apply for a couple other companies in my area as well, but they're still valid reasons to want to work there.


> You should know exactly why you want to work for Amazon.

Never understood this company pride thing i like to work on interesting problems and if your company sells shoes or chewing gum so be it. Your problem space should attract programmers not who you are.


> I've always felt that if I can't get through an interview with a little prep and my existing skills, I don't belong.

The other possibility is that it means the interviews aren't an accurate representation of the work.


If you feel a great sense of accomplishment from being hired at Amazon, that's fine. If you believe that you are a superior engineer on the basis that you were hired by Amazon (or Google, Facebook, Microsoft, etc.), you are making a very bad assumption. Some current engineers and alumni believe this fallacy because it supports their beliefs about themselves. It's a trap that stifles their growth. It's as if people aren't aware that these companies desperately need engineers.


The people I know that work at Google, Facebook, Microsoft, Apple, don't feel that way.

They don't simply because superior engineers abound; it's what's making working at these places something that's not "stifl[ing] their growth".

Also, with the referrals we're continually asked to provide we are well aware how desperate the need is.


I actually think you have it backwards. A lot of those engineers probably feel the opposite because those companies have some amount of truly amazing engineers that those other employees get to work with. For instance I'm like 4 day old garbage compared next to the technical leaders / senior engineers at these companies.

One of my friends used to work right next to some of the engineers that initially created EC2. I'd be feeling more like I'm not worthy because I haven't created anything as cool or worth near as much.


> compared next to the technical leaders / senior engineers at these companies.

You feel that way because you actually didn't do anything you consider cool or you didn't do anything others consider cool? I did a lot of cool stuff; not really interested if others find that cool or not and certainly, without meeting the perceived 10x engineers you are referring to, I am not going to blindly say I would somehow rank lower as an engineer because I don't work in one of those companies or because I was not in the startup phase of one of those companies (you know, at the time when you didn't have to do those silly tests and the bar or entry to jump to the top rank was lower because it was a startup).


There is an amount of Social Engineering here embedded in the process. You have to be cool to be part of our club (Amazon|Google|<your startup>....). It's not the pay, its some other form of darwinian merit system. If you want to be that fit person branded by us for life, jump these hoops. Take a month and deal with it. It's a lifelong gold star in your resume. These hoops are designed to select people who can do these tasks without asking too many questions or claiming ownership of your inventions if any. Like Army expects soldiers to just do it and be loyal. Just build this spec using the hammer we chose for you. It's a system of hiring and retaining that works and scales very well. The computer science algorithms and data structures are a fit function and this method is widely deployed and tested and its almost an Industry standard. It may be too late to find an alternative.

Startups and incubators like YC are also competing for the same talent. They are defining a new fit function to identify people who can find problems in their surroundings and want to solve them with the tools available to them. The startup founders are also writing blogs about how they got funded, my series A looks better than your series B etc. They are unable to leverage social engineering as much as these enterprise crowd. Many of the graduates still come out of universities and aim to get a job in a respectable company than I will do a startup mostly because the startup based social engineering is weak.

/end rant


This whole prep for interview testing seems very unpleasant and of questionable value to me. Are these interviews in any way representative of day to day operations in the job you are applying for?

I worked as an independent software developer while doing my undergraduate in CS and was very successful just by using fundamentals I learned in courses and then reading and supplementing new things. I then transitioned into a PhD student role in robotics, where I regularly need to come up to speed on topics from all fields of engineering and implement solutions. I love learning and solving problems, but the types of coding interviews discussed seem so far from evaluating that. I produce reliable and novel things I am proud of that take a lot of work, but that would not be enough to pass these interviews.

I know employers need proof of a good fit and competence, but I just dread the day I have to go through one of these things.


Don't worry too much about it. I had the same feeling, since I read HN a lot. Now I'm going through the interview process with several companies and have had a great experience with all of them. Not at all what I expected, based on HN interview threads.

I don't have a CS degree and don't have a clue when it comes to the "rebalance a red-black tree" stuff. In all of my interviews, this hasn't been an issue -- I can think intelligently about problems and solve them, ask questions, and show correct, well-documented, maintainable code that I've written in the past. I'm good with people and with translating between biz problems and tech solutions.

Even in a large tech city (Boston) with lots of well-funded tech companies, my experience has been FAR from the hell you'd imagine from reading HN. I think a lot of this just comes from the SV bubble overrepresented here. And maybe from the huge crowd of people here who, for various reasons, desperately want to get into one of the big 4.

Those few enormous advertising companies (G, F, A, etc.) represent such a small fraction of the actual work out there, and make so much of the noise, that it's hard to keep an accurate perspective.

Anyway, don't worry about it. It sounds like you'll have an easier time than me, and I've had it surprisingly easy during this whole process.


Amen to that. :)


Mine was more fun (I shared this before, so sorry if you have to read it again):

Didn't call on the agreed date for phone interview. Then when visiting on-site, future manager, probably the main person I should have been talking to, wasn't there. Quickly assembled together an interview schedule in 20 min with people who , except maybe two, seemed distracted and just wanted to go do something else. Forgot about me during lunch. So was left sitting in an office for an hour without anyone checking on me (eventually got up and started wondering the hallways hoping someone would stop me and ask me -- "Hey I don't think you belong here" and I was hoping to reply with a silly joke about trying to steal AWS's root CA private keys). Then of course they promised to call back with a decision in 2 days, which was more like 2 weeks. Didn't get an offer, no surprise (I did get snarky about the "leadership principles", they probably didn't appreciate that), but it did make a good story I like to tell every time interviews come up.


If he signed an NDA, I probably wouldn't write a blog post about the interview process, that's a good way of getting fired for cause, since the late 1990s.


I don't think you need to treat an NDA as a blanket 'you can say absolutely nothing'. The post is 90% about his own preparation process, and 10% about the day-of schedule for interviews. The schedule of the day-of process is not exactly a secret, everyone that has interviewed at Amazon went through something like it. The recruiters should be telling you what to expect before you even get there. It's not like he gave a hint as to what the questions were.

Here's the thing, posts like this are just making searchable what many people already know. The difference is that the tribal knowledge of how to get through interviews is one of the reasons why our profession has a diversity problem. If you don't know that you should read those books and plan for those questions, how well do you think you will do? Plenty of this wisdom travels over beers among the circles of friends in the industry, but putting it on the internet democratizes the knowledge for everyone.


Yeah, there really wasn't anything surprising in the blog post. The prep work was somewhat interesting. But all the info looks like stuff easily available elsewhere. And I didn't really learn anything unexpected about Amazon's process. Besides I think NDA's for tech interviews generally just cover specific questions.


Most companies voluntarily send interview preparation tips. Recruiters want to get people recruited to get their commission.


He has a footnote that the blog post was discussed. I'm sure nothing important was revealed. Frankly, there wasn't a whole lot to the article that I haven't read elsewhere anyway. No trade secrets there. Amazon wants people who, unlike me, don't find data structures and algorithms to be boring and sleep-inducing. That's about it.


I wouldn't say that's what Amazon "wants", and often the interviews have little correlation with the actual job.

We all know the interview process (across many companies) is a difficult / broken process. I think it gets even more difficult with scale the size of Google, Amazon, etc. How do you offer a consistent candidate experience and stable hiring bar without severely limiting the number of candidates processed or eating up too much developer time?

I'm sure we could find a dozen threads already discussing this on HN though.


None of the people he mentions are from Amazon, I don't think.


I've never signed one, but I'm imagining that the NDA would probably cover any upcoming technologies or products that might come up during an interview, not an NDA about the interview process itself. The latter seems kinda silly IMO


I've signed a few, and they usually explicitly cover the details of the questions themselves. In other words, you can say you had to solve an algorithmic problem, but you can't mention the specific details or wording of that problem.

This is primarily so their questions don't end up on LeetCode or other practice websites; they always end up there anyway, so it really just slows down that process and prevents them from having to think up new questions quite as often.


I've signed Amazon's. If I remember correctly, it says not to talk about any workings of Amazon internals that you might learn during the interview, and not to talk about specifics of the questions. Things like the standard interview schedule, the focus on the Amazon leadership principles, etc are pretty well-known already, and I don't think talking about them will reveal anything that hasn't been revealed to the public.


I thought the same before reading the post, but I must admit that the author of the post is very careful not to reveal any concrete details, so this may be more like subtle trolling of people who check enforcement of interview NDAs.


I interviewed at about a dozen companies two years ago and published every single question. NDAs don't cover interview questions. I asked the employers. Still got offered and nobody sued.


It still seems silly that a working software engineer would need to take time out to practice stuff they don't generally use in their actual work (which they will probably continue doing when hired).

Knowledge of algorithms and datastructures is useful, perhaps essential in some fields but definitely not all - or even most. Even then just understanding the tradeoffs is probably enough.

Unless I'm interviewing someone for something like a database product I am not going to drill them on LSM trees/B+ trees/Fractal trees.

I'm not going to bust a dudes balls over not knowing what a priority heap is if after I explain it he can have a decent conversation about where it might be useful.

These sorts of interviews are dumb and I have never accepted a job where I have been subjected to them and probably never will.


I don't understand why to have all these tests for an applicant? Why not integrate an applicant into a team for a day and have pair programming sessions?

I found, that nothing else works.


> Why not integrate an applicant into a team for a day and have pair programming sessions?

I'm not sure what you think you'll learn in one day like this. You're throwing someone into a high-pressure peer-programming session with someone they don't know and a codebase they've never seen. In order to get them to complete anything you're probably going to have to stage a bunch of stuff and basically give them a fake assignment anyway ("fill in the body of this 'findUserByOrderNumber()' method for us") which has turned it into the equivalent a whiteboard coding question anyway. If you give them a single pair-programming partner, you only get one hiring opinion which is a pretty bad idea, and if you give them multiple pair-programming partners the work will have to be even more trivial.

I don't think a one-day trial like this will tell you more than a standard interview loop. Some people might do better with it, others will do worse.

I also don't think you should expect to get real work out of someone before you hire them, either. If you want me to spend 8 hours building you a feature, I expect to get paid. And the overhead of paying me for 8 hours of work is probably not worth it to your company, because it's a ridiculous amount of paperwork. (And not even possible for people who need visa sponsoring.)


> I also don't think you should expect to get real work out of someone before you hire them, either.

This has grown on me. It's a lot of time invested per company, but it's still a hell of a lot less time than the interview prep mentioned in the article. It's also more pleasant, since I'm programming something real instead of the fibonacci sequence.


I don't honestly think you're going to get much more than Fibonacci in a one day pair programming session on an unknown codebase. It's just too much to learn before you can really accomplish anything. Beyond one or maybe two days it just becomes an unreasonable request, regardless of whether they pay you.


Oh, I think I misunderstood what you meant by "get real work" out of somebody. IMHO, pair programming isn't getting real work out of somebody. I'm with tptacek on this one: take home programming tests. Specifically, tests where they give you specs for something and you build it however you like.


I'm ok with something like that if it's a reasonable amount of work, and if it's not going to be followed up with the standard interview loop. Extremely long take home work is unreasonable to me. Studying for interviews is at least applicable to many companies. A take home is just for the one. And if it's followed up with a normal interview loop, then it's just more but not better.


Amazon is a huge company I'm sure they have a lot of different interview types


Its pretty standardized actually. In this case it looks like he was a part of a "blitz" which often happens for remote locations. A normal interview process is very similar but usually has no hackerrank first, the phone screen is by an engineer and the interview loop may be more like 5-6 people with a lunch break.


Amazon does this for some college hires.


It was never communicated which languages the coding test would be limited to before I started it.

Brilliant. They expect near-flawless execution (under tight time constraints) on these algorithm quizzes -- but can't manage to communicate up front which languages you'll be actually be allowed to code in.


"It was never communicated which languages the coding test would be limited to before I started it. Those I could choose from were C, C++, Java and a couple of others, which ruined my plans to use Go or PHP - the languages I was the most proficient in. So I ended up choosing Java."

Similar thing happened to me. I was never told or asked which programming language I would prefer. I click the link, filled some info and I landed on programming question with only two choices C or C++. I was like wait?! Though, I tried to solve the problem, but couldn't finish on time. I contacted the recruiter about this and I never heard anything back. All I got was email, Sorry you didn't qualify. I really liked the Hackerrank interface, but I was disappointed in lack of language options I was given.


Gross...but that's just me. I know some people really do thrive on this kind of technical rigor and hard-nosed meritocracy type of culture...but if that's the price of progress I'd rather go back to the caves and tepees.


> It was never communicated which languages the coding test would be limited to before I started it. Those I could choose from were C, C++, Java and a couple of others, which ruined my plans to use Go or PHP - the languages I was the most proficient in. So I ended up choosing Java.

I never get this. The first thing that should be understood by the combination of the resume and the phone screen is the candidate's preferred language.


This seems like a very standard process, but personally the best interview I have done was a take-home exercise involving a real world problem. It took me a whole day to do it, but I only had to do exactly what I do best: write code, silently, "in the zone".

No interview environment will ever simulate "the zone", and there is no way to truly test a programmer out of it.


I can't help but feel that there is too much focus on data structures and algorithms. My kids have Amazon Fire Kid tablets and Amazon's software is, to put it mildly, unreliable. I'm sure the data structures and algorithms are probably fine, they're mostly shipped with the plethora of open source that most software is now built from anyway.


All of that looks really painful.. And surprisingly reminds me of pains of dating. (although I seriously dated only once in my life looong time ago)

In dating people trying to find right fit for look, in tech interviews - right answers for arbitrary tech problems.

Nor look not answers to these tech problems is not predictor of success, yet this is what everybody are still using...


How unfair that you're expected to sign an NDA on the spot. I'm sure that Amazon and other software companies have spent tens/hundreds of thousands of dollars to protect their IP, yet you don't even get the most basic legal counsel. Why couldn't they mail it out after the phone screening? This almost feels like duress.


You aren't being coerced, so it isn't duress.

You want to interview? Sign an NDA. Otherwise, Amazon is under no obligation whatsoever to offer you an interview. Nothing is being taken from you, because you are not entitled to receive a job interview.


I have interviewed with Amazon somewhat recently.

The NDA was very short (I'm not a lawyer, but it didn't seem nearly complicated enough to warrant needing a lawyer to read it) and the recruiters gave us time to look over it. There was nothing ridiculous in it and it was only to cover the interview process.

As far as I remember it was just stuff like "don't share details about what goes on in our interviews with others" which is pretty reasonable.


When I interviewed for Amazon for a Java position, they had a C guy give the interview. When he asked me to implement atoi() on Java, Integer.parseInt() was the not correct way to do things at Amazon. After that it was all sys admin questions about the version of Linux they use.

Somehow I managed to pass to the next level. I told them no thanks.


When he asked me to implement atoi() on Java, Integer.parseInt() was the not correct way to do things at Amazon.

I have to agree with them here. If you're being asked to implement a function for parsing integers, they're clearly not looking for an answer of "I call a function which parses integers".


I had the same problem with Microsoft (atoi), and the same issue with the interviewer (being a C guy)...the issue there was that he thought (stringInstance).length() was an O(n) op, so the fact I was calling it in my loop meant my algorithm was O(n^2). My explaining that, no, Java stores the length as part of the object...kinda tanked the interview.


You describe the "interview anti-loop," a term coined by Steve Yegge, a prolific blogger who wrote about the Google interview process. Better luck next time. I've come across it a few times myself. Also I've legitimately bombed interviews, sending apology emails to the recruiter immediately after leaving.


Oh, there won't be a next time. A bit of sour grapes, but I also legitimately don't want to work for Microsoft. Even then it was more exploring my options; that interview tanking was more cynically amusing than it was disheartening.


Had a similar argument about forgetting the null terminator.


I don't know how to get straight ascii out of a java string off of the top of my head. I guess in this situation i'd start with a little discussion of unicode, then just start with something like

    byte[] ascii; 
    ...


one question.

i'm a total noob in my 3rd year CS undergrad.

I've just started prep to crack companies like Amazon.

Any pointers or tips to get started?


Former Amazon employee, ironically. I suggest this for an overview: https://www.reddit.com/r/learnprogramming/comments/3gpvyx/al... and this for a huge list of problems (these exact problems have come up in my interviews with Google and Amazon): http://www.programcreek.com/2012/11/top-10-algorithms-for-co...

I thought Cracking the Coding interview was a bit underwhelming. Just study theory, know how to code and be able to answer generic interview type questions then you'll do great. Best of luck.


Get the book, "Cracking The Coding Interview." It was the most valuable resource for me in preparing for technical interviews near the end of my time in undergrad.


Yes, I bought it last week. But, couldn't answer through the questions because I didn't know the concepts and DS's. Could you answer these 2 questions?

1. Where did you learn how to implement the Data Structures and Algorithms?

2. Also, I'm in a dilemma between using Python and C/C++. Which one would you suggest?


I'd be more worried that in 3rd year of a CS undergrad you don't know how to implement data structures and algorithms.

1. There's lots of great books out there, and resources online. Learn what the interface of a given data structure is, and then go and try to implement it yourself in any way possible, then look up solutions for how it's typically done. Just code a lot! And learn what Big-O Notation is about, analyze your own solutions.

2. Both. It doesn't matter. Java is popular at Amazon, if that's your goal. Look, there's learning a programming language and there's learning to program, and these are different skills that complement each other. You will need to learn a new language a dozen times in your career, so just learn a few different ones right now and then focus on being a good programmer instead of a good C++ programmer.


Not the person you're asking but I previously passed the interview at Amazon.

If you don't know the concepts/data structures, just read more about them, either on the internet or from a book. The internet is usually sufficient for most things but if you want to go more in depth, CLRS is the book that most people recommend. I haven't read it personally. Don't feel bad if you can't answer the questions, a lot of it is practice, and if you don't know the concepts beforehand it's better that you just read the solutions.

1.) I learned in school 2.) It doesn't really matter, just use the one you're more comfortable with. If you're equally comfortable, I'd recommend Python because you're going to be writing on the whiteboard and I imagine C/C++ is more verbose, so you'll waste more time writing. Your hand might also get tired.

You can also go on careercup.com to get more questions after you're finished with the book so you can practice.


>CLRS is the book that most people recommend.

CLRS is a good reference if you want to look up some canonical algorithm and read the accompanying discussion. It is a terrible way to learn if you're not combining it with something more explanatory, like a professor. It's an extremely dense wall of pseudocode and proofs.

Kleinberg and Tardos is a little handwavy with its mathematical proofs, but does an excellent job of motivating the examples, holding your hand and explaining why the next step is next, etc.

It is not, however, a survey of the canonical algorithms and data structures. You will not learn how to balance or invert a binary tree. (My algorithms class was based on K&T, and while I learned a ton, I don't feel I learned how to pass a whiteboard interview). More of an introduction to algorithmic thought, with algorithms selected for their pedagogical value.


CLRS is a huge tome. I have no idea why it's always recommended as an introduction to algorithms. It seems like it has the breadth, if not the depth, of TAOCP in terms of being a perennially recommended work that no one actually reads all of the way through.


1. Freshman year there was a data structures and algorithms course. These remained important through my university career.

You sound unlucky, so here's what you do: implement each one you are unfamiliar with in your favorite language and analyze the complexity of them. Start with linked list algorithms, then stacks/queues, then maybe heapsort and trees then implement Dijkstra's graph algorithm and BFS / DFS.


1. If you're a third-year CS student, you should already be getting lots of practice in implementing data structures. If you're not, complain to your professors. They're giving you a terrible education.

If you're not getting practice enough, pick up a good textbook on data structures and algorithms that does contains only pseudocode (or that's in a language you don't use), and try writing their algorithms in a language that you know.

2. Both Python and C/C++ are good languages, but for very different things.

Python is superb for glue code: bringing together modules from multiple sources.

C/C++ is superb for writing individual components that need to work as quickly as possible.

I'd recommend that you learn Python first, then C/C++.

Good luck!


Late reply from me, but:

1. Introduction to Algorithms/CLRS (~The~ algorithms book) https://mitpress.mit.edu/books/introduction-algorithms

Also, Skiena's "Algorithm Design Manual" for something a bit lighter.

2. I chose to use Python when possible for technical interviews, as it allowed me to focus more on the algorithms/solution, rather than boilerplate. I rarely use Python in my actual job, but I still prefer it for interviews.


> 1. Where did you learn how to implement the Data Structures and Algorithms?

Typically CS degrees would offer a course on this to give a starting point as well as the books and vocabulary to learn further.


> 1. Where did you learn how to implement the Data Structures and Algorithms?

Mostly? 1st year undergrad.

> 2. Also, I'm in a dilemma between using Python and C/C++. Which one would you suggest?

I like Python as a quick-to-write language (whiteboard friendly), but in my most recent interview, some of the questions were phrased to make them easier to implement in C (i.e. more natural to write in terms of pointer access, IMO). I think the answer really depends on the company and what they usually work in.


> Mostly? 1st year undergrad.

How common is this? I did my (EE) undergrad I Florida, which has pretty extensive Gen Ed requirements. Almost nobody takes major courses in their first year.


We had flexibility in our schedules (CA state school). I mixed major and GE courses throughout my years in college. CS courses rarely had GE requirements, unless you count math.


You probably should have learned basic ds+algo stuff in your first or second year of school tbh


There is a book by tamassia on this subject that I quite like, there are specific versions for Java, Python, and (I think) c++ also. The less experienced you, the more I would recommend Python over c++.


Recently I interviewed at AWS at amazon for a SDE position and got an offer too. I used Python for all my DS and Algo problems. It purely depends on your comfort level with the language.


The best prep you can do for getting a job at Amazon is to read up on what it's like to be an employee of Amazon.


I've got a good friend working at Amazon now, and I've spoken with about 5 other Amazon employees. None of them has ever seen the kinds of abuse identified in the New York Times article from last year. So like anything else: take it with a grain of salt.


> Recruiters usually cannot dive deeply into technical topics, but she was very open to discussing the reasons I used to name them differently.

I could be wrong, but based on what you are saying here, I'm pretty sure you were being interviewed by a software engineer and not a recruiter.


> I only had two days so I brushed up on the essentials in algorithms and data structures. Specifically, I focused on the following: [list follows]

No graph problems? Seems like a possible hole, I got graph problems in interviews for Amazon.

Edit: Nevermind, I realized this was your phone screen prep.


I have always wondered if I were to ask an interviewer to do some white board coding exercise for me would they take the challenge?


Wait, is it normal for a recruiter todo a tech interview? I never heard of such a thing.


Very helpful write up, thanks.




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

Search: