<story><title>Amazon software engineer interview</title><url>http://sobit.me/2016/07/08/amazon-software-engineer-interview/</url></story><parent_chain><item><author>soham</author><text>Interesting and valid points. I have some things to add.&lt;p&gt;Disclaimer first: I&amp;#x27;m a technical interview coach. We run &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;InterviewKickstart.com&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;InterviewKickstart.com&lt;/a&gt;, which provides structured and intense group programs for early and mid-career software engineers, with the sole purpose of preparing for technical interviews.&lt;p&gt;In an ideal world, brushing up is all what it should take before going into interviews. Practicing Software Engineers shouldn&amp;#x27;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.&lt;p&gt;Trouble is:&lt;p&gt;* 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&amp;#x27;s learning curve, that candidate is not going to get a fair evaluation. Preparation helps in that situation.&lt;p&gt;* 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.&lt;p&gt;e.g. If they ask you to merge sorted arrays and you don&amp;#x27;t know that Heap sort is the best way to do it, you&amp;#x27;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&amp;#x2F;he is more prepared.&lt;p&gt;* 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&amp;#x27;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.&lt;p&gt;* 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.</text></item><item><author>geoelectric</author><text>I&amp;#x27;m all for interview prep, but this sounds like a fairly standard tech company loop.&lt;p&gt;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&amp;#x27;s experience now, but I don&amp;#x27;t remember any point in my career where I&amp;#x27;d have done something this extensive. I hope the poster doesn&amp;#x27;t feel they need a month&amp;#x27;s prep every time they want to go test the waters on the job market!&lt;p&gt;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&amp;#x27;t know--take what you do know right to the limit then talk about how you&amp;#x27;d figure out the rest given normal professional time and resources.&lt;p&gt;I&amp;#x27;m not usually grading someone on whether they can solve my specific problem so much as whether I think they&amp;#x27;re someone I can work with while they do it. That said, if it&amp;#x27;s on your resume you&amp;#x27;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.</text></item></parent_chain><comment><author>optimusclimb</author><text>&amp;gt; e.g. If they ask you to merge sorted arrays and you don&amp;#x27;t know that Heap sort is the best way to do it, you&amp;#x27;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&amp;#x2F;he is more prepared.&lt;p&gt;Sadly, there&amp;#x27;s a ton of very qualified software engineers that make up this &amp;quot;competition&amp;quot; that you speak of, and still lose. Meanwhile, there&amp;#x27;s another group of people that realize how ridiculous proving yourself in that way every few years throughout the course of one&amp;#x27;s career is, become sales engineers, and make more money. They also don&amp;#x27;t have to have a whiteboard pissing contest anymore over such things.&lt;p&gt;I really wonder if lawyers who have been practicing for 7 years, or consultants from the Bain&amp;#x27;s and McKinseys of the world get asked questions about classes they took in junior year of undergrad when they interview.</text></comment>
<story><title>Amazon software engineer interview</title><url>http://sobit.me/2016/07/08/amazon-software-engineer-interview/</url></story><parent_chain><item><author>soham</author><text>Interesting and valid points. I have some things to add.&lt;p&gt;Disclaimer first: I&amp;#x27;m a technical interview coach. We run &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;InterviewKickstart.com&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;InterviewKickstart.com&lt;/a&gt;, which provides structured and intense group programs for early and mid-career software engineers, with the sole purpose of preparing for technical interviews.&lt;p&gt;In an ideal world, brushing up is all what it should take before going into interviews. Practicing Software Engineers shouldn&amp;#x27;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.&lt;p&gt;Trouble is:&lt;p&gt;* 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&amp;#x27;s learning curve, that candidate is not going to get a fair evaluation. Preparation helps in that situation.&lt;p&gt;* 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.&lt;p&gt;e.g. If they ask you to merge sorted arrays and you don&amp;#x27;t know that Heap sort is the best way to do it, you&amp;#x27;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&amp;#x2F;he is more prepared.&lt;p&gt;* 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&amp;#x27;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.&lt;p&gt;* 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.</text></item><item><author>geoelectric</author><text>I&amp;#x27;m all for interview prep, but this sounds like a fairly standard tech company loop.&lt;p&gt;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&amp;#x27;s experience now, but I don&amp;#x27;t remember any point in my career where I&amp;#x27;d have done something this extensive. I hope the poster doesn&amp;#x27;t feel they need a month&amp;#x27;s prep every time they want to go test the waters on the job market!&lt;p&gt;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&amp;#x27;t know--take what you do know right to the limit then talk about how you&amp;#x27;d figure out the rest given normal professional time and resources.&lt;p&gt;I&amp;#x27;m not usually grading someone on whether they can solve my specific problem so much as whether I think they&amp;#x27;re someone I can work with while they do it. That said, if it&amp;#x27;s on your resume you&amp;#x27;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.</text></item></parent_chain><comment><author>SonOfLilit</author><text>&amp;gt; e.g. If they ask you to merge sorted arrays and you don&amp;#x27;t know that Heap sort is the best way to do it&lt;p&gt;Sorry, I&amp;#x27;m confused. I love heaps, but... what&amp;#x27;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))?&lt;p&gt;&lt;pre&gt;&lt;code&gt;    def merge_sorted(a, b):
        result = []
        la, lb = len(a), len(b)
        ia, ib = 0, 0
        while ia &amp;lt; la or ib &amp;lt; lb:
            if ib &amp;gt;= lb:
                result += a[ia:]
                break
            if ia &amp;gt;= la:
                result += b[ib:]
                break
            if a[ia] &amp;lt;= 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]&lt;/code&gt;&lt;/pre&gt;</text></comment>