How to get into Microsoft, Amazon or Twitter without a prestigious college diploma
This article is for those who are preparing to look for a job and may be worried that you will not break into top companies without a diploma from Stanford University in computer science. You were probably told that no one will take you on Facebook or Microsoft. But I want to tell you that it is quite possible. Here is my story about how I managed to get my dream job on Twitter.
What you will find in this article:
I did not graduate from Ivy League universities. I spent two years at a community college in Idaho, then I transferred to a small Catholic university and graduated there with a degree in Computer Science.
')
I started 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 the Chinese counterfeit under the Nintendo console, and she sighing, it was enough to insert a cartridge into it.
In order to provide myself until I get an education, I took several part-time jobs at once - washing the floors, selling food in cinemas. After graduation, I had no work in mind. I sent a resume to all major IT companies as I could, and even, by luck, received several invitations for telephone interviews.
At that time, I didn’t even imagine about what it really was - 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, I was eliminated at all these interviews.
Then I did not think too much about whether my level was good. I knew I was quickly grabbing. All I needed was an opportunity to express myself.
As popular wisdom says, the network needs to be thrown away and wider. So I did.
For what I did in the next stage, I am particularly proud. I wrote a simple Python script that collected jobs from Craigslist, selected posts with certain keywords, and entered the email addresses specified there into the table. Not the most ingenious solution, but the people who post vacancies on Craigslist, surprisingly accurately call posts.
On Craigslist, however, they are not too fond of when someone tries to upload their data. To get around the restrictions, I ran the script through a VPN and set a timer that paused the process every few minutes. Not perfect, but this scheme worked.
Ultimately, I collected about 500 addresses of organizations located in San Francisco, Portland, Spokone and Seattle. I filtered the results by relevance and date and continued to optimize the issue, adding more and more parameters.
As it turned out, there were already a few bots on the market that collected data from Craigslist and automatically sent emails. 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 topic contained relevant keywords. Then I added some more details based on the text of the vacancy, so that the proposal looked customized for specific requirements. Judging by the fast A / B test that I conducted, the percentage of responses after this increased significantly - from 2-3% to 10%.
About 500 replies came to my 500 letters; with a small percentage of these 50, I managed to negotiate 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.
By luck, I got a job in a startup from Seattle, in the position of a junior developer. Their office was then located in Kirkland, so I had to take a 45-minute bus ride 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-support code, talk about design correctly 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 they gave me. I am convinced that this turned out to be a huge influence on my career.
In a startup, I, with rare exceptions, worked only on a backend with rare forays into DevOps. First, I wrote functions to add or modify features, usually not too large-scale. But it was a great opportunity to get acquainted with the code base and go through the code verification procedure.
A year later, whole fragments of the code base began to trust me, and then they commissioned me to make a service out of a set of functions. The startup just started to move to a service-oriented architecture. We began to turn various components of the site into services, and in between times I learned a lot about RESTful, authentication, AWS, 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'm like this: well, let's understand!
More than once or twice I fell into analytical paralysis - a state where excessively detailed analysis impeded progress in resolving the problem. It was during these difficult moments that the most opportunities for development arose. I improved on defining the scope of functions, negotiating, monitoring, setting alerts, and writing documentation. At each step of this process, new concepts were discovered that I needed to master. During these two or three years I grew more than ever in terms of programming skills and in terms of human qualities.
After my torment at the first round of job search, I promised myself that next time I would be well prepared for interviews.
I started the training by writing what I have, how I am strong, what is weak, and what would be good to pull up. All the skills I have divided into three categories: data structures, algorithms and system design.
In the professional field, I worked mostly in PHP, and in college I wrote in C ++, so for the interview I decided to choose something simpler, not so massive.
Based on these criteria, I opted for Python. This is a great way to learn: easily digested, supports many data structures by default and allows you to quickly write code on the board. I have mastered Python tutorials on Youtube, 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 why I prefer Python is that it is very easy to read and compact to write. Here is a simple example to compare C ++ and Python.
The program for sorting in descending order in C ++:
Compare with the same Python program:
I heard from interviewers that, other things being equal, it’s better to lean toward brevity when choosing a language. The more time you spend from the 45 minutes you can spend on solving the task, the better.
Tip: choose languages ​​that aren't too bulky to write the code on the board faster.
For about a week I have been solving simple tasks on LeetCode, HackerRank and Project Euler, in order 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. I spent another week on design assignments, while trying to cover as wide a range as possible and dive as deep as possible.
It was very exciting: often I just took iOS apps and watched how they were made. Say, how to create Instagram from scratch (this is exactly the question I was asked on Facebook)?
My portfolio is working on an API and service-oriented architecture. Therefore, I willingly used this opportunity to tell you how I would design my own version of Instagram. Thanks to side projects, I also have some experience developing on iOS, so at the same time I screwed up a little about callback, pull technologies and long polls.
I started by listing the functionality that I would like to see in my own version of Instagram: likes, photo uploading and simple tape. Determining the range of functions allowed me to build a very good API, since all these scenarios are familiar to me.
Then I drew several high-level schemas 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: reasonable ) about what the requirements will be, and how this or that technology will fit in. And also, no less important, what technologies will not fit in any way.
For example: why Cassandra should be used to store a certain type of data instead of MySQL (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 not enough for all hour sessions. 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 brainstorm with a colleague, and strive for the widest possible approach and in-depth 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 favorable light. I watched this video from a former Facebook designer on how to approach design assignments; his recommendations helped me a lot in the interviews. Two main thoughts that I brought out of it, sound like this: ask the direction of the conversation about the design yourself and show what you can do.
So, I painted my skills with regard to 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 the situation was worst, and began to work on it. It turned out to be algorithms.
Algorithms have never been my forte. A lot of water has already flowed from college, and in my work I didn’t often have to do a binary search. I had a general idea of ​​how each algorithm works and in which scenarios to use them. But I was not one hundred percent sure of my ability to register a 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 from Amazon - they write great. I don’t know, maybe it’s just me, but for some reason the markers in the offices are always exhausted. I usually only do two or three minutes that I go over the markers in search of the normal, and this is not the situation when you can waste time like this. And another thing: if you take thin markers, you can fit on a standard board by 5-8 lines of code more than usual ones.
Tip: get your own set of markers.
I bought a $ 50 plank at Costco, scored books on Amazon (they are listed in the recommendations section at the end of the article) and started practicing. I tried especially to press on binary search, recursion, dynamic programming, search in width and in depth. Many of the questions at the interviews relate specifically to recursion and binary search, or some kind of variation.
The very best tasks that I have met have many different decisions, this circumstance should also be taken into account in the preparation process.
One question I was asked on Google was about file system directories and how to traverse them (hint: recursion). I quickly presented the solution, and the interviewer asked how to determine what file was missing in the folder. It was a more difficult question, but I managed. After that, we started talking about how to re-link, serialize or deserialize the catalog and have been discussing how the catalogs work under the hood for a long time. I got great pleasure from this session.
The experience, to put it mildly, is exciting. Those are still roller coasters.
I allocated my time like this: 20% for resumes, 20% for acquaintance with companies, 60% for preparing for an interview.
20% of the time I spent on updating the information in the resume, which did not touch more than three years. I carefully looked at everything I did in the past and selected those projects that I conducted from beginning to end, regardless of the level of complexity.
I had two reasons for this. First, the ability to bring the project to the end implies discipline and leadership qualities - that is, 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 meaningfully. This circumstance turned out to be critically important at my interview on Twitter, where I was interrogated with passion not only about various aspects of design, but also about why they were decided to implement this way.
Another 20% went to search for information. By this I mean that I paid due attention to companies and sent out requests for recommendations. Recommendations greatly increase the likelihood of being called back.
From my own experience: I sent out about 20 "cold" letters to start-ups and businesses of medium size, 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 to me during the week. This, of course, is only one specific case, but still he speaks about something.
I do not differ sociability and people who are able to recommend me to companies in which I was interested, did not know very much. To solve this problem, I went to LinkedIn. Using their search engine, I found my first and second level links. Second circle connections are those people who are only a step away from your social circle. In other words, you have mutual friends who can vouch for them.
This is extremely important because it is very, very difficult to get in for an interview in a “cold” way, especially in the realities of the modern market. People in such cases prefer to be careful. LinkedIn was very useful for the information gathering stage.
Looking back, here are my impressions of the companies in which I interviewed:
I would say that interviewing Twitter is difficult in many ways. 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. Then follow one or two technical phone interviews, the amount depends on your results. If everything is in order, they will invite you to fly to the office for the vacancy of which you have responded, in my case it was an office in Seattle. There you will have three sessions lasting one hour and fifteen minutes, each with two employees.
Two telephone interviews follow the usual pattern for technical positions: you solve tasks in the mode of co-editing code.
, , . , . , , . .
, , , ; , , .
Twitter Facebook Google . - - . , , , .
Facebook , . «» , .
Google , . . , . , , . — .
Pinterest . , , , . .
Pinterest , . . And that's why.
, , . API, , , , . . , !
.
, .
, . , .
, . , .
. 20 , 80 , .
, , , . , , . IT-, , , . , , .
: , .
: , , . , .
Elements of Programming Interviews —
Cracking The Coding Interview — CS
OneNote —
Evernote — —
CodeRunner — Mac! / Python, .
Jobscan — . , .
Refdash — Google. — . , , Google , Google. .
CodePath — , IT-. — , . , - .
— , .
, Cracking The Coding Interview , : hash map, . Elements of Programming Interviews , . : - , , , Cracking The Coding Interview . Elements of Programming Interviews — .
What you will find in this article:
- Something from my biography
- A story about how I was invited to interview the top IT companies in the world: Facebook Google, Amazon, LinkedIn, Microsoft, Twitter, Pinterest, Snapchat and others
- A story about how I received several job offers for a programmer position
- Lessons learned from this experience
Curriculum Vitae
I did not graduate from Ivy League universities. I spent two years at a community college in Idaho, then I transferred to a small Catholic university and graduated there with a degree in Computer Science.
')
I started 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 the Chinese counterfeit under the Nintendo console, and she sighing, it was enough to insert a cartridge into it.
In order to provide myself until I get an education, I took several part-time jobs at once - washing the floors, selling food in cinemas. After graduation, I had no work in mind. I sent a resume to all major IT companies as I could, and even, by luck, received several invitations for telephone interviews.
At that time, I didn’t even imagine about what it really was - 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, I was eliminated at all these interviews.
Next step
Then I did not think too much about whether my level was good. I knew I was quickly grabbing. All I needed was an opportunity to express myself.
As popular wisdom says, the network needs to be thrown away and wider. So I did.
For what I did in the next stage, I am particularly proud. I wrote a simple Python script that collected jobs from Craigslist, selected posts with certain keywords, and entered the email addresses specified there into the table. Not the most ingenious solution, but the people who post vacancies on Craigslist, surprisingly accurately call posts.
On Craigslist, however, they are not too fond of when someone tries to upload their data. To get around the restrictions, I ran the script through a VPN and set a timer that paused the process every few minutes. Not perfect, but this scheme worked.
Ultimately, I collected about 500 addresses of organizations located in San Francisco, Portland, Spokone and Seattle. I filtered the results by relevance and date and continued to optimize the issue, adding more and more parameters.
As it turned out, there were already a few bots on the market that collected data from Craigslist and automatically sent emails. 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 topic contained relevant keywords. Then I added some more details based on the text of the vacancy, so that the proposal looked customized for specific requirements. Judging by the fast A / B test that I conducted, the percentage of responses after this increased significantly - from 2-3% to 10%.
About 500 replies came to my 500 letters; with a small percentage of these 50, I managed to negotiate 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.
By luck, I got a job in a startup from Seattle, in the position of a junior developer. Their office was then located in Kirkland, so I had to take a 45-minute bus ride 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-support code, talk about design correctly 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 they gave me. I am convinced that this turned out to be a huge influence on my career.
Work in a startup
In a startup, I, with rare exceptions, worked only on a backend with rare forays into DevOps. First, I wrote functions to add or modify features, usually not too large-scale. But it was a great opportunity to get acquainted with the code base and go through the code verification procedure.
A year later, whole fragments of the code base began to trust me, and then they commissioned me to make a service out of a set of functions. The startup just started to move to a service-oriented architecture. We began to turn various components of the site into services, and in between times I learned a lot about RESTful, authentication, AWS, 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'm like this: well, let's understand!
More than once or twice I fell into analytical paralysis - a state where excessively detailed analysis impeded progress in resolving the problem. It was during these difficult moments that the most opportunities for development arose. I improved on defining the scope of functions, negotiating, monitoring, setting alerts, and writing documentation. At each step of this process, new concepts were discovered that I needed to master. During these two or three years I grew more than ever in terms of programming skills and in terms of human qualities.
How I was preparing for the interviews
After my torment at the first round of job search, I promised myself that next time I would be well prepared for interviews.
I started the training by writing what I have, how I am strong, what is weak, and what would be good to pull up. All the skills I have divided into three categories: data structures, algorithms and system design.
In the professional field, I worked mostly in PHP, and in college I wrote in C ++, so for the interview I decided to choose something simpler, not so massive.
Based on these criteria, I opted for Python. This is a great way to learn: easily digested, supports many data structures by default and allows you to quickly write code on the board. I have mastered Python tutorials on Youtube, 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 why I prefer Python is that it is very easy to read and compact to write. Here is a simple example to compare C ++ and Python.
The program for sorting in descending order in C ++:
#include <bits/stdc++.h> using namespace std; int main() { int arr[] = {1,10,0,4,5} int n = size(arr)/sizeof(arr[0]); sort(arr, arr + n, greater<int>()); for (int i = 0; i < n; i++) { cout << arr[i] << " "; } return 0; } Compare with the same Python program:
a = [1,2,4,5,1000] a.sort(reverse=True) print a I heard from interviewers that, other things being equal, it’s better to lean toward brevity when choosing a language. The more time you spend from the 45 minutes you can spend on solving the task, the better.
Tip: choose languages ​​that aren't too bulky to write the code on the board faster.
In preparation mode
For about a week I have been solving simple tasks on LeetCode, HackerRank and Project Euler, in order 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. I spent another week on design assignments, while trying to cover as wide a range as possible and dive as deep as possible.
It was very exciting: often I just took iOS apps and watched how they were made. Say, how to create Instagram from scratch (this is exactly the question I was asked on Facebook)?
My portfolio is working on an API and service-oriented architecture. Therefore, I willingly used this opportunity to tell you how I would design my own version of Instagram. Thanks to side projects, I also have some experience developing on iOS, so at the same time I screwed up a little about callback, pull technologies and long polls.
I started by listing the functionality that I would like to see in my own version of Instagram: likes, photo uploading and simple tape. Determining the range of functions allowed me to build a very good API, since all these scenarios are familiar to me.
Then I drew several high-level schemas 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: reasonable ) about what the requirements will be, and how this or that technology will fit in. And also, no less important, what technologies will not fit in any way.
For example: why Cassandra should be used to store a certain type of data instead of MySQL (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 not enough for all hour sessions. 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 brainstorm with a colleague, and strive for the widest possible approach and in-depth 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 favorable light. I watched this video from a former Facebook designer on how to approach design assignments; his recommendations helped me a lot in the interviews. Two main thoughts that I brought out of it, sound like this: ask the direction of the conversation about the design yourself and show what you can do.
So, I painted my skills with regard to 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 the situation was worst, and began to work on it. It turned out to be algorithms.
Algorithms have never been my forte. A lot of water has already flowed from college, and in my work I didn’t often have to do a binary search. I had a general idea of ​​how each algorithm works and in which scenarios to use them. But I was not one hundred percent sure of my ability to register a 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 from Amazon - they write great. I don’t know, maybe it’s just me, but for some reason the markers in the offices are always exhausted. I usually only do two or three minutes that I go over the markers in search of the normal, and this is not the situation when you can waste time like this. And another thing: if you take thin markers, you can fit on a standard board by 5-8 lines of code more than usual ones.
Tip: get your own set of markers.
I bought a $ 50 plank at Costco, scored books on Amazon (they are listed in the recommendations section at the end of the article) and started practicing. I tried especially to press on binary search, recursion, dynamic programming, search in width and in depth. Many of the questions at the interviews relate specifically to recursion and binary search, or some kind of variation.
The very best tasks that I have met have many different decisions, this circumstance should also be taken into account in the preparation process.
One question I was asked on Google was about file system directories and how to traverse them (hint: recursion). I quickly presented the solution, and the interviewer asked how to determine what file was missing in the folder. It was a more difficult question, but I managed. After that, we started talking about how to re-link, serialize or deserialize the catalog and have been discussing how the catalogs work under the hood for a long time. I got great pleasure from this session.
Interviews in top companies
The experience, to put it mildly, is exciting. Those are still roller coasters.
I allocated my time like this: 20% for resumes, 20% for acquaintance with companies, 60% for preparing for an interview.
20% of the time I spent on updating the information in the resume, which did not touch more than three years. I carefully looked at everything I did in the past and selected those projects that I conducted from beginning to end, regardless of the level of complexity.
I had two reasons for this. First, the ability to bring the project to the end implies discipline and leadership qualities - that is, 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 meaningfully. This circumstance turned out to be critically important at my interview on Twitter, where I was interrogated with passion not only about various aspects of design, but also about why they were decided to implement this way.
Another 20% went to search for information. By this I mean that I paid due attention to companies and sent out requests for recommendations. Recommendations greatly increase the likelihood of being called back.
From my own experience: I sent out about 20 "cold" letters to start-ups and businesses of medium size, 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 to me during the week. This, of course, is only one specific case, but still he speaks about something.
I do not differ sociability and people who are able to recommend me to companies in which I was interested, did not know very much. To solve this problem, I went to LinkedIn. Using their search engine, I found my first and second level links. Second circle connections are those people who are only a step away from your social circle. In other words, you have mutual friends who can vouch for them.
This is extremely important because it is very, very difficult to get in for an interview in a “cold” way, especially in the realities of the modern market. People in such cases prefer to be careful. LinkedIn was very useful for the information gathering stage.
Looking back, here are my impressions of the companies in which I interviewed:
- Facebook / Google is all very mechanical. Interviews were held on a template, and I did not feel any personal connection.
- Pinterest is not the best experience in terms of interviewing, but the product and the company are great.
- Microsoft - I really liked the team, especially the manager and its manager. The questions were standard, but the approach is very personal. A serious competitor to the position of my favorite. You, however, may have a different 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 is very exciting and personalized. The interview went great, a lot of attention was paid to my previous experience and human qualities.
- Snapchat is a gorgeous office in Los Angeles and a large group of people who decide to join a startup. The feeling was like a veil of secrecy.
- Lyft - not far from my house, nice office, interview in the standard way. Did not leave a strong impression.
First about my favorite
I would say that interviewing Twitter is difficult in many ways. 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. Then follow one or two technical phone interviews, the amount depends on your results. If everything is in order, they will invite you to fly to the office for the vacancy of which you have responded, in my case it was an office in Seattle. There you will have three sessions lasting one hour and fifteen minutes, each with two employees.
Two telephone interviews follow the usual pattern for technical positions: you solve tasks in the mode of co-editing code.
, , . , . , , . .
, , , ; , , .
Twitter Facebook Google . - - . , , , .
Facebook , . «» , .
Google , . . , . , , . — .
Pinterest . , , , . .
Pinterest , . . And that's why.
, , . API, , , , . . , !
.
, .
, . , .
- . , , , . 100%, 10% .
- . IT- . , , , , - . , Jobscan , . , .
- , . , IT- . .
- . , , , . « , - » — . « » — , . - : « , X, Y. A, B, C, . Y, --». ( . : , , .)
, . , .
- . , , , , . , , . - .
- . , , . , . Evernote. , . , , .
- , . Evernote , OneNote . OneNote , , . Evernote . .
- , , , . , , , . , - , Evernote. . .
- . , . «» . , Refdash, . IT- Google, Facebook Microsoft. , , , .
- . . , . , . «», «» — . , . . , . , . : 10 , 10 . . , . , .
. 20 , 80 , .
, , , . , , . IT-, , , . , , .
: , .
: , , . , .
Elements of Programming Interviews —
Cracking The Coding Interview — CS
OneNote —
Evernote — —
CodeRunner — Mac! / Python, .
Jobscan — . , .
Refdash — Google. — . , , Google , Google. .
CodePath — , IT-. — , . , - .
— , .
, Cracking The Coding Interview , : hash map, . Elements of Programming Interviews , . : - , , , Cracking The Coding Interview . Elements of Programming Interviews — .
Source: https://habr.com/ru/post/353462/
All Articles