How to get to Microsoft, Amazon or Twitter without the diploma of the prestigious college

This article is for those who are preparing to look for work and, perhaps, are worried about the fact that you can not get through to top companies without a Stanford University diploma in computer science. You probably have been told that no one will take you to Facebook or Microsoft. But I want to tell you that it is quite possible. Here's my story about how I managed to get my dream job on Twitter.
How to get to Microsoft, Amazon or Twitter without the diploma of the prestigious college

What you will find in this article:
Something from my biography
A story about how I was invited to interview the top IT companies of the world: Facebook Google, Amazon, LinkedIn, Microsoft, Twitter, Pinterest, Snapchat and others
A story about how I received several job offers as a programmer
The lessons I learned from this experience
like this , and documentation. I personally prefer Python 2.x, but you can choose between Python 2.x and Python 3.
By the way, one of the reasons I chose Python is that it is very easy to read and compact to write. Here's a simple example to compare C ++ and Python.
Program for sorting in descending order on C ++:
using namespace std;
int main ()
int arr[]= {???.4.5}
int n = size (arr) /sizeof (arr[0]);
sort (arr, arr + n, greater
for (int i = 0; i < n; i++) {
cout arr""
return 0;
Compare with the same program in Python:
a =[1,2,4,5,1000]
a.sort (reverse = True)
print a

I heard from the experts conducting interviews that, other things being equal, it is better to lean towards concision when choosing a language. The more time from the 45 minutes allocated to you, you can spend on the solution of the task, the better.
Tip: choose not too bulky languages ​​to quickly write code on the board.

In the mode of preparation

Somewhere for a week I solved simple tasks on LeetCode, HackerRank and Project Euler to get acquainted with the interfaces of these sites and get used to writing in Python. During this time, I was able to better assess my level in some programming languages. Another week I took to the design tasks, while trying to cover as wide a spectrum as possible and to dive as deep as possible.
It was very exciting: often I just took iOS apps and watched how they were made. Let's say, how to create Instagram from scratch (this is the question I was asked in Facebook)?
I have a portfolio of API and service-oriented architecture work. Therefore, I willingly took this opportunity to tell you how I would project my version of Instagram. Thanks to side-projects, I also have some experience in developing on iOS, so at the same time I screwed up the word about callback, pull technologies and long polls.
I started with the fact that I listed the functional that I would like to see in my own version of Instagram: likes, photo upload and a simple ribbon. The definition of the range of functions allowed me to build a very robust API, because all of these scripts are familiar to me.
Then I drew a few high-level schemes showing how the user will interact with the backend and how the data will be stored there. I moved from the very low, gradually adding components as needed, and actively looking for bottlenecks. I made reasonable assumptions (I emphasize:

? grounded ) About what the requirements will be, and how this or that technology will fit there. And also, no less important, what technologies do not fit in any way.
For example: why use Cassandra instead of MySQL (hint: scale, development speed, schema reviews) to store a particular type of data than OAuth better than simple authentication, Redis vs. Memcached for data caching, streaming or batch processing, and so on.
Here you can explore different areas, usually for the entire hour of the session is not enough. To respond well to such questions, you need to thoroughly study the problem of trade-offs, the pros and cons of various technologies in the industry. For this I recommend sites like HighScalability .
Treat this as a normal brainstorming session with a colleague, and strive for the widest possible approach and deep study.
It is extremely important to realize that these design sessions are designed to reveal what you know and how well - and that this is your opportunity to show yourself in a profitable light. I looked at this video from a former Facebook designer about how to approach design assignments; his recommendations helped me very much at the interviews. The two main thoughts that I made out of it sound like this: ask the direction of the conversation about the design yourself and show what you know how.
So, I painted my skills in data structures (linked lists, hash maps, binary trees, binary search trees, heaps, arrays), algorithms (binary search, hashing, dynamic programming, sorting) and syntax and libraries of specific languages (lambda-functions for Python, append, index). Then I chose the area in which things were the worst, and began to work on it. It turned out to be algorithms.
Algorithms have never been my strong point. Since college, a lot of water has flowed, and for work I did not often have to engage in binary search densely. I had a general idea of ​​how each algorithm works and in what scenarios they are used. But I was not 100% sure of my ability to write binary search in less than ten minutes. On the desk. In the presence of the person conducting the interview.
At the same time, I bought a whole bunch of markers with Amazon - they write beautifully. I do not know, maybe it's just me, but the markers in the offices for some reason are always exhausted. I usually do two or three minutes only and do that I go through the markers in search of a normal one, and this is not the situation when you can throw your time like this. And more: if you take thin markers, you can fit on a standard board for 5-8 lines of code more compared to the usual ones.
Tip: Get your own set of markers.
I bought a $ 50 board at Costco, typed books on Amazon (they are listed in the section with recommendations at the end of the article) and began to practice. I tried especially to click on binary search, recursion, dynamic programming, search in width and in depth. Many questions in interviews concern exactly the recursion and binary search or some kind of its variation.
At the very best assignments that I met, there are many different solutions, this circumstance should also be taken into account in the preparation process.
One question that I was asked in Google concerned the file system directories and how to navigate their traverse (hint: recursion). I quickly presented the solution, and the interviewer asked how to determine that there was not enough file in the folder. It was a more difficult question, but I managed it. After that, we went on to talkru about how to re-build, serialize or deserialize the directory and for a long time discussed how the directories work under the hood. I received great pleasure from this session.
Interviews in top companies

Experience, to put it mildly, is exciting. Those are the roller coaster.
I distributed my time like this: 20% for CV, 20% for getting acquainted with companies, 60% for preparing for an interview.
20% of the time I spent on updating information in the resume, which did not touch more than three years. I carefully reviewed everything that I had done in the past, and selected the projects that led from beginning to end, regardless of the level of complexity.
On that I had two reasons. First, the ability to bring the project to the end implies discipline and leadership qualities - that is, exactly those features that I would like to associate with employers.
Secondly, such a degree of involvement in the project means that I can talk about it in great detail and informative. This circumstance turned out to be critically important in my interview on Twitter, where I was interrogated not only about different aspects of design, but also about why they decided to implement it that way.
Another 20% went to the search for information. By this I mean that I paid due attention to companies and sent out requests for recommendations. The recommendations greatly increase the likelihood that you will be called back.
From my own experience: I sent out about 20 "cold" letters to start-ups and medium-sized businesses, and only a few of them answered me. But from those companies where one of the employees put in a word for me, the overwhelming majority wrote off with me within a week. This, of course, is only one particular case, but still he says something.
I do not differ sociability and people who could recommend me to companies in which I was interested, knew not so much. To solve this problem, I went to LinkedIn. With the help of their search engine, I found my first and second level links. The connections of the second circle are those people who are only one step apart from your circle of contacts. In other words, you have common friends who can vouch for them for you.

This is extremely important, because it is very, very difficult to get into the interview in a "cold" way, especially in the realities of the modern market. People in such cases prefer to be cautious. LinkedIn was very useful for the information gathering stage.
Looking back, here are my impressions of the companies in which I was interviewed:
Facebook /Google - all very mechanically. Interviews took place on a pattern, and I did not feel any personal connection.
Pinterest - not the best experience in terms of interview, but the product itself and the company are cool.
Microsoft - I really liked the team, especially the manager and its leader. The questions were standard, but the approach is very personal. A serious competitor to the position of my favorite. However, you may get another impression: each team at Microsoft conducts an interview in its own way.
Amazon - everything is standard. Half of the applicants like this approach, the rest - no.
Twitter - very exciting and personalized. The interview was excellent, a lot of attention was paid to my previous experience and human qualities.
Snapchat - a chic office in Los Angeles and a big company of people who decided to join the start-up. The feeling was that there was a veil of secrecy in everything.
Lyft - Near my house, nice office, interview according to the standard scheme. Did not leave a strong impression.

First about my favorite

I would say that it is difficult to interview Twitter in many ways. But this experience was more individual and interesting than my meetings with other companies.
The first stage of the interview is a telephone conversation to get acquainted with the technical director. Then follows one or two technical interviews by phone, the number depends on your results. If everything is in order, they will invite you to fly to the office where you responded, in my case it was an office in Seattle. There you will pass three sessions of one hour and fifteen minutes each, with two staff members present.
Two telephone interviews take place on the usual for technical posts scheme: you solve tasks in the mode of joint code editing.
Sessions in the office, however, are much less formal and far less frightening. You will be thoroughly asked about previous projects and everything that you have been doing so far. If you state that you participated in a project, be prepared to talk about it in detail. Using them as a source of solutions or for breaking ideas is only encouraged.
I have never felt that they are pressing me, forcing me to magically create a ready-made, working solution; on the contrary, there was an impression that the employees are very loyal.

And now about all the other

Compared to Twitter, Facebook and Google interviews seemed more mechanical. They consisted of one or two telephone interviews and five to six sessions in the office. At each session it was necessary to prescribe the code on the board, and almost a perfect solution was required, however, and enough time was given.
Facebook had two programming sessions, one for design and one for assessing personal qualities. At the end of the day, I went through another "shadow" session, but the overall score did not affect her results.
Google had five sessions, all programming. By design, there was nothing at all and no one has ever talked about my past projects. I'm not saying that this is definitely bad. But it seems to me that this approach leaves the feeling of the pipeline and does not allow the developer to show in proper measure what he is capable of. To some, this format is suitable - it's like with students and exams.
Interview in Pinterest I did not like. The product itself seems interesting, and the team seems to be working on very entertaining problems . But my experience as an applicant was unambiguously negative.
Pinterest conducts three sessions on programming, one on design. Of these four I was disappointed by the latter. And that's why.
The employee who conducts the interview came late and for the first few minutes just read my resume. Then he drew an API on the board, briefly described what he should do, and asked how I would implement it. We discussed the functional and I began to prescribe a solution on the blackboard. After about five minutes I turned around and saw that he was dozing off!
Not cool.
I wrote about this in the questionnaire after the interview, but no one else contacted me.
I will not go into details about exactly what questions were asked to me at the interviews. Instead, I will list some useful conclusions and recommendations to which I came in the process of preparation.

What I learned from

Be honest when writing your resume. Most companies will ask questions about what is written there, and immediately understand if you start to invent. It is better to know one project 100% than to have 10% information about ten different projects.
One-page summaries are preferable. For IT-sphere this is especially important. According to the unspoken rule, those who have a scientific degree and many publications, or those who were really deeply involved in a large number of projects, can claim for two pages. By the way, one of my friends founded a company called Jobscan which analyzes the summary and suggests specific actions to improve them. Excellent service, you can try.
Communicate, make connections. Competition among programmers is very high, top IT companies handle thousands of resumes per day. The employee's recommendation will help you attract attention.
Know how to sell yourself. Any company interested in you wants to know why you are interested in it. "I need a job, I have to live for something" is a bad answer. "I was looking for options on the Internet and saw your site" - better, but still not very. A good answer sounds like this: "I heard that you have interesting X projects that can contribute to Y. In the course of working on past projects, I've mastered A, B, C, which can be applied in X. I have a lively interest to Y, because blah blah blah. " (Just do not use it as a template.) Here you just need to catch the pattern: gather information about the company, consult your biography and show why you fit each other.)

And a few more tips

Technical interviews are highly complex, their outcome is sometimes difficult to predict. However, the best opportunities are for those who come prepared.
Begin to prepare in advance and properly. Everyone knows that it is necessary to prepare for interviews, but not everyone knows how to do it right. As with any other worthwhile skill, to achieve a good result, you need to practice a well-thought-out scheme. A well thought out scheme requires some kind of system.
Create a system for improving technical skills. I started by assessing my skills in different areas on a ten-point scale and began to pull those who received the lowest scores. I spent for each type of task for several days, until I worked out every concept properly. Every day I took notes in Evernote. I had a special notebook dedicated to programming. There I brought tips and tricks, common mistakes and errors, algorithms for solving tasks of different types and much more.
Keep a record of what you have learned. I used for this purpose as Evernote , and OneNote . OneNote was intended for strictly technical things and code, I liked that there you can format the entries as you like. Evernote I used for reasoning and ideas. Above you can see my notes about the architecture and design of systems.
Fix everything that you can, even if it seems to you that this is hardly useful. I'm very forgetful, so I write down everything I've learned, including command-line commands. I also often read programmers blogs, and if something interesting comes up, I immediately put it in Evernote. At the end of each week or every month, I look through the records and put them in order. This habit was very useful for my career.
Arrange rehearsals. This is a very valuable experience, which I recommend to everyone. I asked my friends to play a "job interview" with me and tried to arrange such trainings as often as possible. If you have no one to turn to, I can advise Refdash, who provide services for organizing test interviews. They work specialists from major IT companies like Google, Facebook and Microsoft. These employees will assess your programming and design skills and, most importantly, present a final score and specific recommendations on what you need to work on.
In failures, there is nothing to worry about. In the process of finding work, I filled up a lot of interviews. Sometimes it happens that just a day is not yours. Even if it all ended in failure, it is not the end of the world. Companies are generally more inclined to say "no" than "yes" - less risk. In the long run, underestimating the candidate is not as unprofitable as overestimating. The first few failures were definitely the most painful. At the first attempts to get a job I was screened out at the stage of telephone interviews, and this undermined my faith in myself. I began to doubt my abilities and to be afraid that my skills are not in demand on the modern labor market. But I came up with a formula for myself: if I failed 10 times, make 10 more attempts. It is enough to achieve success only once. This way of thinking gave me confidence and strength to continue trying. When I finally got the first job offer, it all went much easier.

My Notes
I took about two months to think over the preparation for the interviews. I was engaged in 20 hours per week, that is 80 hours per month, in addition to the main work.
In order to make a good resume, it took me three and a half years of hard, thoughtful work. I deliberately jumped myself to work more difficult and more pitying to learn faster than everyone else. Suppose I did not have a diploma of a stellar university or work in a top IT company, I compensated for this with a clear, thorough understanding of the projects I worked on. And to achieve this understanding I was helped by my habit of recording everything that I learned and ordering information according to a certain system.
Remember: the strongest survive, the most hardy succeeds.
If to generalize: do not give up, look for opportunities, practice more and do not lose hope. Concentrate on the process and develop a thoughtful, disciplined approach to it.

Recommended tools

Elements of Programming Interviews - a good source with tasks of a high level of complexity
Cracking The Coding Interview - useful materials for mastering the basic CS
OneNote - I use it to store fragments of the code
Evernote - and its - for the rest of
CodeRunner - Great program for Mac! I often used it to work with specific scripts /functions in Python, it works just fine.
Jobscan - CompanyI'm my friend. I've heard a lot of good things about them, so contact them for a resume.
Refdash - the initiative of several former employees of Google. Their trial interviews are just fire for quality. The employee who interviewed me used to work in Google and told me a lot of useful information about what to pay special attention to and how I would be appreciated in Google. I highly recommend this company.
CodePath Is a non-profit organization that helps people build a career in the IT field. Nathan and Tim are fine people, I learned a lot from them. The community is very sympathetic, anyone is ready to help something.
These are the fine markers. - Excellent write, highly recommend.
If you choose between two books, Cracking The Coding Interview it is better suited to work out the basics: how the linked list or hash map is arranged, how to work with them, and so on. Elements of Programming Interviews suitable for those who need more difficult tasks. I would do it like this: I spent two or three weeks thinking about thoughtfully, from chapter to chapter. Cracking The Coding Interview and get comfortable with all the libraries of the language you need. All the rest of the time I would dedicate Elements of Programming Interviews and the tasks presented there - a complete understanding of the basic data structures would help me in their solution.
+ 0 -

Add comment