Amazon software engineer interview
sobit.me
sobit.me
. 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
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?
> 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.
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!"
(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.)
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?
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.
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.
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 :-)
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.
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.
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).
>>. 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 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 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.
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.
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.
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.
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 ..
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.
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 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).
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.
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.
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.
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.
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.
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.
>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.
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.
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]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).
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...
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.
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 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 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)
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.
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 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.
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.
If you're single with no children and no hobbies.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
I don't think claiming something is a statistical truth without showing the statistics will fly on HN.
"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.
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...
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.
>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...
The other possibility is that it means the interviews aren't an accurate representation of the work.
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.
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.
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.
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.
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.
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.
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).
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
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.
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.
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.
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.
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.
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.
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 found, that nothing else works.
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.)
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.
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.
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.
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.
No interview environment will ever simulate "the zone", and there is no way to truly test a programmer out of it.
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...
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.
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.
Somehow I managed to pass to the next level. I told them no thanks.
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".
byte[] ascii;
...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?
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?
Typically CS degrees would offer a course on this to give a starting point as well as the books and vocabulary to learn further.
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 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.
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.
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.
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!
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.
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.
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.
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.
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.
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.