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

Original author: Zhia Hwa Chong
  • Transfer
This article is for those who are preparing to look for work and may be worried that you will not get into top companies without a Stanford University computer science diploma. They probably told you that nobody will take you to Facebook or Microsoft. But I want to tell you that this is entirely possible. Here is my story about how I managed to get my dream job on Twitter.

What you will find in this article:

  • Some of my biography
  • The story of how I was invited to interview top IT companies in the world: Facebook Google, Amazon, LinkedIn, Microsoft, Twitter, Pinterest, Snapchat and others
  • The story of how I received several job offers as a programmer
  • The lessons that I learned from this experience

Curriculum Vitae

I did not graduate from Ivy League universities. For two years I studied at a public college in Idaho, then transferred to a small Catholic university and graduated there in computer science.

I began to engage in programming in the first year, simply because it seemed to me that it would be interesting. All my experience with computers until that moment was exhausted by a Chinese fake for the Nintendo console, and even that one died, it only cost to insert a cartridge into it.

In order to provide for myself, until I get an education, I took several part-time jobs at once - washed the floors, sold food in movie theaters. After graduation, I had no job in mind. I sent out a resume to all the major IT companies that I could, and even with luck, I received several invitations to phone interviews.

At that time, I didn’t even imagine what it was like - an interview for a technical position, and even more so how to prepare for it. I came to the interview with the thought that they would ask me what a linked list or binary tree is.

Naturally, at all these interviews they dropped me out.

The next step

Then I did not think too much about whether I had a good level. I knew I was catching fast. All I needed was an opportunity to prove myself.

According to popular wisdom, the network needs to be thrown away and wider. So I did.

For what I did in the next step, I am especially proud. I wrote a simple Python script that collected vacancies from Craigslist, selecting posts with specific keywords, and entered the email addresses listed there in the table. Not the most ingenious decision, but the people who post jobs on Craigslist are surprisingly surely calling the posts.

Craigslist, however, is not too fond of someone trying to upload their data. To get around the restrictions, I ran the script through the VPN and set a timer that paused the process every few minutes. Not perfect, but such a scheme worked.

Ultimately, I collected about 500 addresses of organizations located in San Francisco, Portland, Spokon and Seattle. I filtered the results by relevance and date and continued to optimize the results by adding more and more parameters.

As it turned out, there were already several bots on the market that collected data from Craigslist and automatically sent letters. For the most part, these were offshore companies trying to break into the US market.

One of the tricks I resorted to was as follows: I composed the text of the letters so that the subject contained the relevant keywords. Then I added some more details based on the text of the vacancy, so that the offer looked sharpened to specific requirements. Judging by the quick A / B test that I conducted, the percentage of responses after that increased significantly - from 2-3% to 10%.

About 500 replies came to my sent 500 letters; with a small percentage of these 50, I managed to arrange a telephone interview. I stopped at 500 because time was running out - I needed to get somewhere already. The priority at that time was the result, not the breadth of coverage.

Luckily, I got a job in a startup from Seattle, as a junior developer. Their office was then located in Kirkland, so I had to take the bus for 45 minutes to catch an interview.

I worked there for the next three and a half years and learned a lot: Amazon AWS, EC2, DynamoDB, SQS and Docker. During this time I have grown a lot as a programmer. I learned how to write modular, easy-to-maintain code, reason correctly about design and solve problems when working with people.

I worked side by side with a group of knowledgeable people who came to us from Microsoft, Amazon and LinkedIn, and tried to play the role of a “sponge” among them. I absorbed absolutely everything that they gave me. I am convinced that this turned out to be a huge influence on my career.

Work in a startup

In startup, with rare exceptions, I only worked on a backend with rare attacks in DevOps. At first, I wrote functions to supplement or modify features, usually not too large. But it was a great opportunity to get acquainted with the code base and go through the code verification procedure.

After a year, they began to trust me in whole fragments of the code base, and then they instructed me to make a service out of a set of functions. The startup was just starting to switch to a service-oriented architecture. We began to turn the various components of the site into services, and in between I learned a lot about RESTful, authentication, AWS, the publisher-subscriber pattern, distributed systems, and so on.

What is most interesting: I did not learn anything from books or during a university course. It was just necessary to implement some functions or eliminate some bottlenecks. And I am like this: well, let's understand!

More than once or twice I fell into analytical paralysis - a state where an overly detailed analysis impeded progress in resolving the problem. It was in these difficult moments that the most opportunities for development arose. I improved in defining the scope of functions, negotiations, monitoring, setting up alerts and compiling documentation. At every step of this process, new concepts were discovered that I needed to master. Over these two or three years, I have grown more than ever in terms of programming skills, and in terms of human qualities.

How I Prepared for the Interviews

After my torment in the first round of a job search, I promised myself that the next time I would get ready for interviews.

I started the preparation by writing what I was strong at, what was weak and what it would be good to pull up. I divided all skills into three categories: data structures, algorithms, and system design.

In the professional field, I worked mainly in PHP, and in college I wrote in C ++, so I decided to pick up something simpler for an interview, not so massive.

Based on these criteria, I opted for Python. This is a great option to learn: easy to digest, supports many default data structures and allows you to quickly write code on the board. I mastered Python tutorials on Youtube, like this, and documentation. I personally like Python 2.x more, but you can choose between Python 2.x and Python 3.

By the way, one of the reasons I preferred Python is that it is very easy to read and compact in writing. Here is a simple example to compare C ++ and Python.

Program for sorting in descending order in C ++:

using namespace std; 
int main()
   int arr[] = {1,10,0,4,5}
   int n = size(arr)/sizeof(arr[0]);
   sort(arr, arr + n, greater());
   for (int i = 0; i < n; i++) { 
      cout << arr[i] << " ";
   return 0;

Compare with the same Python program:

a = [1,2,4,5,1000]
print a

I heard from experts conducting interviews that, other things being equal, it is better to lean toward conciseness when choosing a language. The more time out of the 45 minutes allotted to you that you can spend actually on solving the task, the better.

Tip: choose not too bulky languages ​​to write code on the board faster.

In training mode

About a week or so I worked through 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 design tasks, while trying to cover the widest possible range and dive as deep as possible.

It was very exciting: often I just took iOS applications and watched how they were made. Let's say how to create Instagram from scratch (this is exactly the question I was asked on Facebook)?

My portfolio has work on APIs and service-oriented architecture. Therefore, I willingly took this opportunity to tell how I would have designed my version of Instagram. Thanks to the side projects, I also have some experience developing on iOS, so at the same time I screwed up a word about callback, pull technologies and long polls.

I began by listing the features that I would like to see in my own version of Instagram: likes, uploading photos, and a simple feed. Defining the range of functions allowed me to build a very solid API, since all of these scenarios are familiar to me.

Then I drew a few high-level diagrams showing how the user will interact with the backend and how the data will be stored there. I moved from the very minimum, gradually adding components as needed, and actively searched for bottlenecks. I made reasonable assumptions (I emphasize: justified ) about what the requirements will be and how this or that technology will fit in there. And also, no less important, which technologies do not fit in any way.

For example: why is it worth using Cassandra instead of MySQL to store a certain type of data (hint: scale, development speed, schema reviews), than OAuth is better than simple authentication, Redis versus Memcached when caching data, streaming or batch processing, and so on.

Here you can explore different areas, usually the whole hourly session is not enough. To answer such questions well, you need to thoroughly study the problem of compromises, 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 broadest possible approach and deep study.

It is imperative to be aware that these design sessions are designed to bring out what you know and how well - and that this is your opportunity to show yourself in a good light. I watched this videofrom a former Facebook designer on how to approach design assignments; his recommendations helped me a lot during the interviews. The two main thoughts that I learned from it are: set the direction to the conversation about design yourself and show that you can.

So, I painted my skills in terms of data structures (linked lists, hash map, 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. These turned out to be algorithms.

Algorithms have never been my forte. A lot of water has already flowed from college, and for work I did not often have to deal closely with binary searches. I had a general idea of ​​how each algorithm works and in what scenarios to use them. But I was not one hundred percent confident in my ability to spell 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 great. I don’t know, maybe it's just me, but the markers in the offices for some reason are always exhausted. I usually only do two or three minutes that I sort through the markers in search of the normal, and this is not a situation where you can scatter time like this. And one more thing: if you take thin markers, you can fit on a standard board 5-8 lines of code more than usual ones.

Tip: Get your own set of markers.

I bought a board at Costco for $ 50, typed books on Amazon (they are listed in the recommendations section at the end of the article) and started to practice. I tried especially to click on binary search, recursion, dynamic programming, width and depth search. Many questions at the interviews concern recursion and binary search, or some variation of it.

The best tasks that I have met have many different decisions, this fact should also be taken into account in the preparation process.

One question I was asked at Google was about file system directories and how to traverse them (hint: recursion). I quickly introduced the solution, and the interviewer asked how to determine if the file was missing in the folder. It was a more complicated question, but I managed. After that, we went on to talk about how to recompile, serialize, or deserialize a directory and for a long time discussed how directories work under the hood. I really enjoyed this session.

Interviews at Top Companies

The experience is, to say the least, exciting. Those are still roller coasters.

I distributed my time like this: 20% for a resume, 20% for getting acquainted with companies, 60% for preparing for an interview.

I spent 20% of the time updating information in a resume that I didn’t touch for more than three years. I carefully looked at everything that I did in the past and selected those projects that I conducted from beginning to end, regardless of difficulty level.

I had two reasons for this. Firstly, the ability to bring the project to the end requires discipline and leadership qualities - that is, precisely those traits with which I would like to associate with employers.

Secondly, this degree of involvement in the project means that I can talk about it in great detail and informatively. This circumstance turned out to be critical at my interview on Twitter, where I was interrogated with bias not only about various aspects of design, but also about why they decided to implement it that way.

Another 20% went to search for information. By this I mean that I paid due attention to the companies and sent out requests for recommendations. Recommendations greatly increase the likelihood that you will be called back.

From my own experience: I sent out about 20 “cold” letters to medium-sized startups and businesses, and only a few of them answered me. But of those companies where one of the employees put in the word for me, the vast majority wrote to me within a week. This, of course, is only one specific case, but nevertheless he speaks of something.

I am not sociable and people who were able to recommend me to companies in which I was interested did not know much. To solve this problem, I headed to LinkedIn. With the help of their search engine, I found my connections of the first and second levels. The connections of the second circle are those people who are just one step away from your circle of friends. In other words, you have common friends who can vouch for them.

This is extremely important, because getting into an interview in a “cold” way is very, very difficult, especially in the realities of the modern market. People in such cases prefer to be careful. LinkedIn proved to be very useful for the information gathering phase.

Looking back, here are my impressions of the companies in which I was interviewed:

  • Facebook / Google is all very mechanical. The interviews took place according to the pattern, and I did not feel any personal connection.
  • Pinterest isn't the best interviewing experience, but the product itself and the company are awesome.
  • 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 have a different impression: each team at Microsoft conducts interviews in their own way.
  • Amazon - everything is standard. Half of the applicants like this approach, the rest do not.
  • Twitter is very entertaining and personalized. The interview went well, a lot of attention was paid to my previous experience and human qualities.
  • Snapchat is a posh Los Angeles office and a large company of people who decide to join a startup. The feeling was like a veil of secrecy.
  • Lyft - not far from my house, nice office, standard interview. They did not leave a strong impression.

First about my favorite

I would say that interviewing Twitter is in many ways difficult. But at the same time, 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 manager. This is followed by one or two technical interviews by phone, the amount depends on your results. If everything is in order, they will invite you to fly to the office for which you have applied for a job, in my case it was an office in Seattle. There you will pass three sessions lasting one hour and fifteen minutes, each attended by two employees.

Two telephone interviews take place according to the usual scheme for technical posts: you solve tasks in the joint code editing mode.

Sessions in the office, however, are far less formal and far less scary. You will be thoroughly questioned about previous projects and about everything that you have done so far. If you declare that you participated in a particular project, be prepared to talk in detail about it. Using them as a source of solutions or for testing ideas is only encouraged.

I have never felt that they are putting pressure on me, forcing me to magically create a ready-made, working solution; on the contrary, it seemed that the employees were very loyal.

And now about everyone else

Compared to Twitter, Facebook and Google interviews seemed more mechanical to me. They consisted of one to two telephone interviews and five to six sessions in the office. At each session, it was necessary to write the code on the board, and an almost perfect solution was required, however, and they gave enough time.

Facebook had two programming sessions, one for design and one for evaluating personal qualities. At the end of the day I went through an additional “shadow” session, but its results did not affect the overall score.

Google had five sessions, all for programming. There was nothing at all in design, and no one ever talked about my past projects. I am not saying that this is definitely bad. But it seems to me that this approach leaves a sense of conveyor belt and does not allow the developer to adequately show what he is capable of. For some, this format is suitable - it is like with students and exams.

I didn’t like the interview on Pinterest. The product itself seems interesting, and the team, apparently, is working on very interesting tasks . But my experience as an applicant was clearly negative.

Pinterest holds three programming sessions, one by design. Of the four, the last one disappointed me. And that's why.

The interviewer came late and just read my resume for the first few minutes. Then he drew an API on the board, briefly described what he should do, and asked how I would implement it. We discussed the functionality and I began to write a solution on the board. About five minutes later 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 I was asked at interviews. Instead, I will list some useful conclusions and recommendations that I came to in the process of preparation.

What i learned

  • Be honest when writing a 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% of information about ten different projects.
  • One-page resumes are preferable. For the IT sector, this is especially true. According to an unspoken rule, those who have a degree and many publications, or those who were truly deeply involved in a large number of projects, can apply for two pages. By the way, one of my friends founded a company called Jobscan , which analyzes resumes and offers concrete actions to improve them. Great service, you can try.
  • Communicate, make connections. The competition among programmers is very high, top IT companies process thousands of resumes per day. The recommendation of an employee 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 work, I have to live on something” is a bad answer. “I looked for options on the Internet and saw your site” - better, but still not very. A good answer sounds something like this: “I heard that you have interesting projects on X that can contribute to Y. In the course of work on past projects, I mastered A, B, C, which can be applied in X. I have a keen interest to Y because blah blah blah. " (Just don’t use it as a template. Here you just need to catch the pattern: collect information about the company, refer to your biography and show why you suit each other.)

And some more tips

Technical interviews are highly complex, sometimes their outcome is difficult to predict. However, the best opportunities are for those who come prepared.
  • Start preparing in advance and properly. Everyone knows that they need to prepare for interviews, but not everyone knows how to do it right. As with any other worthwhile skill, in order to achieve a good result, you need to practice according to 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 evaluating my skills in different areas on a ten-point scale and began to pull up those that got the lowest ratings. I spent several days on each type of assignment, until I worked out each concept as it should. Every day I took notes on Evernote. I had a special notebook for recording on the topic of programming. There I brought tips and tricks, common mistakes and misconceptions, algorithms for solving tasks of various types, and much more.
  • Keep notes of what you have learned. I used both Evernote and OneNote for this purpose . OneNote was intended for strictly technical things and code, I liked the fact that there you can format recordings as you like. I used Evernote for reasoning and ideas. Above, you can see my notes on architecture and system design.
  • Fix everything that is possible, even if it seems to you that this is hardly useful. I am very forgetful, so I write down everything I learned, including commands for the command line. Also, I often read the blogs of programmers, and if something interesting comes across, I immediately put it in Evernote. At the end of every week or every month, I look through the notes and put them in order. This habit has been very useful for my career.
  • Have rehearsals. This is a very valuable experience that I recommend to everyone. I asked friends to play an “interview” with me and tried to arrange such training sessions as often as possible. If you have no one to contact, I can advise Refdash, who provide services for organizing test interviews. They employ specialists from large IT companies like Google, Facebook and Microsoft. These employees will evaluate your programming and design skills and, most importantly, present a final score and specific recommendations on what needs to be worked on.
  • There is nothing wrong with failure.In the process of finding a job, I filled up a lot of interviews. Sometimes it happens that it's just not your day. Even if it all ended in failure, this is not the end of the world. Companies are generally more likely to say no than yes - less risk. In the long run, underestimating a 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 fear that my skills are not in demand in the modern labor market. But I came up with the following formula for myself: if you failed 10 times, make another 10 attempts. It is enough to achieve success only once. This way of thinking gave me confidence and strength to continue trying.

My notes

It took me about two months to carefully prepare for the interview. I did 20 hours a week, that is 80 hours a month, in addition to my main job.

It took me three and a half years of hard, thoughtful work to write a good resume. I deliberately jumped out a job harder and more pleasant to learn faster than everyone else. Although I didn’t have a star university diploma or a job in a top IT company, I compensated for this with a clear, thorough understanding of the projects I was working on. And my habit of recording everything that I learned and organizing information according to a specific system helped me to achieve this understanding.

Remember: the strongest survive, the most hardy succeed.

To summarize: do not give up, look for opportunities, practice more and do not lose hope. Focus on the process and work out a thoughtful, disciplined approach to it.

Featured Tools

Elements of Programming Interviews is a good source with high-level tasks
Cracking The Coding Interview is useful material for mastering the basic CS
OneNote - I use it to store fragments of
Evernote code- and it - for everything else
CodeRunner is an excellent Mac program! I often used it to work with specific scripts / functions in Python, it works just fine.
Jobscan is my friend's company. I heard a lot of good things about them, so turn to them for a resume.
RefdashIs an initiative of several former Google employees. Their test interviews are simply quality fire. The employee who interviewed me used to work for Google and told me a lot of useful things about what I need to pay special attention to and how I would be appreciated by Google. Highly recommend this company.
CodePath is a nonprofit organization that helps people build careers in the IT field. Nathan and Tim are wonderful people, I learned a lot from them. The community is very responsive, anyone is ready to help with anything.
These thin markers - they write great, I highly recommend it.

If you choose between two books, Cracking The Coding Interviewbetter suited to work out the basics: how a linked list or hash map works, how to work with them, and so on. Elements of Programming Interviews is suitable for those who need more difficult tasks. I would do this: I spent two or three weeks carefully, from chapter to chapter, studying Cracking The Coding Interview and getting used to all the libraries of the language you need. All the rest of the time I would devote Elements of Programming Interviews and the tasks presented there - a full understanding of the basic data structures would help me in solving them.

Also popular now: