Як я отримував пропозиції від Microsoft, Amazon і Twitter без ступеня Ліги Плюща

Це для тих з вас, хто збирається розпочати пошук роботи, і хто може переживати, що ви не зможете отримати найвищу технічну роботу без ступеня CS в Стенфорді. Хтось сказав вам, що ви недостатньо хороші, щоб влаштуватися на роботу в Microsoft або Facebook.

Але я тут, щоб сказати вам, що ви можете отримати цю роботу. Ось як я отримав роботу, про яку мріяв у Twitter.

Детальніше про мої курси читайте тут, щоб дізнатись, як я готувався.

Ви можете прочитати про мій досвід після року в Twitter тут.

Що висвітлює ця стаття:

  • Моє походження
  • Як я брав інтерв’ю з провідними технологічними компаніями світу: Facebook Google, Amazon, LinkedIn, Microsoft, Twitter, Pinterest, Snapchat та іншими.
  • Як я отримав кілька пропозицій як штатний інженер-програміст
  • Уроки з мого досвіду співбесіди
  • Підпишіться тут, щоб отримувати від мене додаткові оновлення статей

Якщо ви віддаєте перевагу переглядати мою історію, я зробив тут відео:

Передумови

Я не закінчив школу ліги Плюща. Два роки я навчався в громадському коледжі в Айдахо, а потім закінчив ступінь CS в невеликому католицькому університеті.

Я почав вивчати інформатику ще на молодшому курсі коледжу, тому що це на той час для мене звучало весело. Єдине, що нагадувало комп’ютер, який я мав, - це китайська копія Nintendo SNES. Навіть тоді він ламався кожен раз, коли я вкладав у нього патрон.

Щоб підтримати себе в коледжі, я взяв кілька неповних робочих днів, таких як прибирання підлоги та роботи на поступки.

Коли я закінчив школу, у мене не було роботи в черзі. Я подав заявку у стільки великих технологічних компаній, скільки міг, і мав щастя взяти кілька телефонних інтерв’ю.

На даний момент я не мав жодного уявлення про те, яким буде технічний екран, а тим більше про те, як до нього підготуватися. Я взяв участь у цих інтерв'ю, думаючи, що інтерв'юер запитає мене, що таке пов'язаний список або двійкове дерево.

Я не пройшов жодного з цих співбесід.

Рухатися вперед

Я не надто вникав у те, чи хороший я. Я знав, що можу швидко навчитися. Мені просто потрібна була можливість.

Як говориться, киньте свою мережу далеко і широко. Отже, це я зробив.

Те, що я зробив далі, - те, чим я особливо пишаюся. Я написав простий сценарій Python, який викреслював списки вакансій у Craigslist із заголовками, що містять ключові слова зі списку, та збирав електронні листи в електронну таблицю. З фактичною історією війни ви можете прочитати статтю тут.

Це не було найрозумнішим рішенням, але люди, які розміщують публікації у Craigslist, напрочуд точні зі своїми назвами.

Craigslist, однак, не любив, як люди скребують їх веб-сайт. Щоб обійти це, я провів свій сценарій через VPN і мав таймер, який робив сценарій на паузі кожні кілька хвилин або близько того. Це не було ідеально, але працювало досить добре.

Врешті-решт я зібрав близько 500 листів із Сан-Франциско, Портленда, Спокейна та Сіетла. Я відфільтрував результати, наскільки конкретні та нещодавні вони були, і продовжував вдосконалювати їх, додаючи все більше і більше функцій.

Як виявилося, на ринку вже було кілька ботів, які сканували Craigslist і розсилали автоматизовані електронні листи. В основному це були офшорні компанії, які прагнули вивести свою компанію на ринок США.

Одним із моїх обхідних шляхів було те, що я створив електронні листи, у яких використовувались ключові слова зі списків у заголовку моїх електронних листів. Потім я додав більше деталей, використовуючи тіло публікацій, щоб зробити його більш привабливим. Я зробив швидкий A / B тест, і відповіді, які я отримав, зросли трохи з приблизно 2-3% до 10%.

З 500 або близько того електронних листів я отримав близько 50 відповідей і приземлився на екрани телефонів з невеликим відсотком тих. Я зупинився на 500, тому що мені бракувало часу і мені потрібно було якомога швидше завершити роботу. Я оптимізував для результатів, а не досягав на той момент.

На щастя, нарешті я влаштувався на роботу в стартапі в Сіетлі молодшим інженером-програмістом. Тоді стартап знаходився в Кіркленді, тому мені довелося їхати на автобусі 45 хв, щоб встигнути до співбесіди.

Потім я пробув там протягом наступних 3,5 років, де дізнався багато нового, як Amazon AWS, EC2, DynamoDB, SQS та Docker. Я багато виріс за цей період. Я навчився писати модульний код, який можна обслуговувати. Я навчився міркувати про дизайн програмного забезпечення. І я навчився вирішувати проблеми людей.

Я працював поруч із групою розумних людей, які працювали в Microsoft, Amazon та LinkedIn, і я намагався бути “губкою” в групі. Я поглинув усе і все, що вони мені кинули. Я вважаю, що це справило величезний вплив на мою кар'єру.

Дні запуску

Під час перебування у стартапі я працював майже виключно над розробкою серверних систем, з деякими розробками між ними. Я почав писати деякі функції для додавання / модифікації функції, які в основному були невеликими за обсягом. Але це була чудова можливість зрозуміти кодову базу та отримати деякі огляди коду.

Через рік я почав володіти частинами кодової бази, а потім мені було доручено перетворити набір функцій у службу. Це був початок фази SOA для запуску. Ми почали перетворювати різні компоненти сайту на сервіси, і ось так я почав більше дізнаватися про послуги RESTful, аутентифікацію, послуги AWS, pub-sub, розподілені системи тощо.

Цікавим тут є те, що я ні про що з них не дізнався за допомогою книг чи формальної освіти. Швидше, мені потрібно було виконати цей набір функцій, і там були вузькі місця.

Тож я подумав, підемо це вирішувати!

Було багато разів, коли я застряг у паралічі аналізу - стан, коли я надмірно аналізував сценарії і в кінцевому підсумку не міг досягти прогресу.

Ті випробувальні часи були найбільшими можливостями для навчання. Я почав вивчати масштаб функцій, переговори, моніторинг, попередження та документацію. Кожен крок процесу відкривав більше речей, які мені потрібно було навчитися. Я зростав найбільше за ці 2–3 роки, як особисто, так і як інженер програмного забезпечення.

Як я готувався до своїх співбесід

Переживши перший пошук роботи, я сказав собі, що повинен бути готовим до майбутніх співбесід.

Я почав готуватися до співбесід, склавши загальний огляд того, у чому я був хороший, поганий і де міг би покращитися. Я розбив його на три категорії: структури даних, алгоритми та дизайн системи.

Більшу частину своєї професійної кар'єри я працював у PHP, а в коледжі - C ++, і я хотів спробувати щось простіше і менш багатослівне для співбесіди.

For this reason, I picked Python. It is a great language to learn, easy to pick up, supports many data structures out of the box, and can be written quickly on the whiteboard. I learned Python by going through YouTube tutorials like these, and also reading their documentation. I prefer Python 2.x, but you can go for either 2.x or 3.

Also, another reason why I picked Python is that it’s highly readable and easy to write on a whiteboard. Here’s a trivial comparison between C++ and Python.

A C++ program to sort in descending order:

#include  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 that with Python’s version:

a = [1,2,4,5,1000] a.sort(reverse=True) print a 

I’ve received feedback from interviewers to err on the side of brevity in an interview. In a 45-minute interview, you want to use most of your time solving the actual problem.

Pro tip: pick a language that’s less verbose so that you can write the code more quickly on the whiteboard.

Preparation mode

I spent about a week going through simple challenges on LeetCode, HackerRank, and Project Euler to familiarize myself with their interfaces, and to get used to writing code in Python.

The first week gave me insights into my competence level at certain programming languages. I spent another week going through some design challenges like “design X” and went as wide and deep as I could.

This was a lot of fun for me, because I often looked at iOS apps and tried to figure out how they did it. For example, how would you build Instagram from scratch? (I was asked this at Facebook.)

My background is in API designs and service-oriented architecture, so I took this opportunity to show how I would design my own version of Instagram. And because I have some iOS programming experience from my side-projects, I could talk a little bit about callbacks and push/long-polls here.

I started the conversation with some features I’d like to have on my own version of Instagram: likes, upload a photo, and a simple timeline. Feature scoping enabled me to build a very solid API because I know these scenarios well.

I then drew some pictures of a high-level design, of how the client would interact with the backend, and of how the backend would store the data.

I started small, and then added more components where needed and proactively sought where the bottlenecks were. I made educated guesses (read educated, not blind guesses) on what the requirements would be, and how each technology would fit in well. And also equally important, what technologies would not fit well.

For example, why would you use Cassandra over MySQL to store certain information (hint: scale, speed of development, schema reviews), why use OAuth over simple authentication, Redis vs Memcached for caching data, streaming vs batch processing, and so on.

There are many areas you can explore here, so typically a one-hour session is not enough. To do well on these questions, you have to read and learn about trade-offs. Pros and cons of technologies in the industry. For this, I recommend a site like HighScalability.

Take it like a typical brainstorming session with a coworker, so explore as widely and as deeply as you can.

It’s crucial to know that these design interviews are meant to explore how much you know and how well you know it, and it’s an opportunity for you to shine. I watched this YouTube video from an ex-Facebook engineer about how to solve design problems, and it gave me insights that helped me tremendously with my design interviews. My two main lessons from it: drive the design conversation, and show what you know.

I listed out my competency level for: data structures (linked list, hash map, binary tree, binary search tree, heap, array), algorithms (binary search, hashing, dynamic programming, sorting), and language-specific syntax and libraries (like sort, lambda for Python, appending, indexing).

I picked the area I was worst at, and started working on it: algorithms.

Algorithms have never been my forte. It’s been a while since my college days, and I didn’t spend much time doing binary search in my day-to-day career. I had an inkling of how each algorithm would perform, and in what scenarios to use them. But I wasn’t 100% comfortable with writing a binary search in under 10 mins. On a whiteboard. In front of an interviewer.

I also picked up a bunch of fine-point markers from Amazon, which work amazingly well. Perhaps it’s just me, but the fine-point markers in interviewing rooms usually don’t work at all. I’d usually scramble for 2–3 mins looking for a working pen, and that’s 2–3 mins you can’t afford to waste. Plus, fine-point markers allow you to write 5–8 more lines of code on a typical whiteboard vs. thicker ones. :)

Pro tip: Get your own set of fine-point markers.

I got a whiteboard from Costco for $50, some books from Amazon (listed in the tools I recommend section below), and started practicing. I made sure I ramped up on binary search, recursion, dynamic programming, BFS and DFS. A lot of interviewing questions revolved around recursion and binary search or some variations of it.

The best interviewing questions I’ve seen had many different solutions to them, and there’s an additional layer added on top as you progress through.

One Google question I had was related to file-system directories, and how to traverse them (hint: recursion). I solved that relatively quickly, and the interviewer asked how to identify a missing file in that directory. That was a little more difficult, but I got through it. And we then moved into how to rebuild the directory, how to serialize/deserialize it, and we spent a good chunk of time debating how file directories work underneath the hood. It was a very enjoyable session for me.

Interviewing at top-tier companies

It was a nerve-wracking experience, to say the least, and a real roller-coaster.

I allocated my time in the following manner: 20% resume, 20% research and 60% interview preparation.

I spent 20% of my time fixing up my resume, which hadn’t been updated in at least three years. I took a hard look at the stuff I’ve done in the past, and picked projects I handled end-to-end, regardless of complexity.

The reason for doing this is two-fold. Taking a project from start to completion demands discipline and leadership — two of the traits I’d like to be identified with.

Secondly, ownership of a project end-to-end means I can talk about each aspect of the project at length and in depth. This proved critical in helping me navigate my design round at Twitter, where they grilled me hard on not only the designs of my projects, but also the decisions behind them.

20% of my time was used for research. Research in this case meant doing due diligence on companies I was interested in and reaching out for referrals. Having referrals helps with return calls.

From my experience, I sent out 20 or so cold messages to startups and mid-stage companies, and only heard back from a handful. But, almost all the companies I was referred to by an existing employee sent me a message within a week. This is anecdotal, but there’s value to be had there.

I am not that sociable, and I didn’t know many people who’d be able to refer me to a company I was interested in. To solve that problem, I went on LinkedIn. They have a search functionality that I used to search for 1st and 2nd-level connections. 2nd-level connections are people who’re one hop away from your immediate circle. In other words, we have mutual friends who can vouch for my credibility.

This is incredibly important, because cold-calling someone for a job is very, very hard, especially in today’s market. People tend to err on the side of caution when it comes to cold-callers. Using LinkedIn was super helpful for my research phase.

Looking back at all the companies I interviewed at, here are my thoughts on each of them:

  • Facebook/Google — very mechanical. The standard interviewing process, and I didn’t feel any personal connection to them.
  • Pinterest — not the best interviewing experience, but a cool product and company.
  • Microsoft — loved the team and especially the manager and her manager. Standard interviewing questions, but very personable. Close-second choice. Your mileage may vary, though — each team at Microsoft interviews differently.
  • Amazon — standard interviewing process. About 50% of the people love it, the others don’t.
  • Twitter — incredibly fun and personal. Loved the interviewing process, gave a lot of emphasis on the individual and what I’d done in the past.
  • Snapchat — cool office in LA, great bunch of people who decided to jump on the startup bandwagon. Felt like things were shrouded under a cloud of secrecy.
  • Lyft — near to where I live, nice office, standard interviewing process. No strong feelings about it.

Let’s talk about my favorite

In many ways, I’d say Twitter’s interviewing style was hard. But at the same time, it was more interesting and personable than other companies I’ve interviewed at.

Their interviewing process starts with an introductory phone call with an engineering manager. That’s followed up by one or two technical phone screens, depending on how you perform. If you do well, they’ll fly you out to the office you’re interviewing for, which was Seattle in my case. There are three 1-hour-and-15-minute rounds, each with two interviewers.

The first two technical phone screens are the standard, run-of-the-mill technical screens where you solve coding problems on a shared coding doc.

The onsite rounds, however, are much more conversational and feel much less intimidating. The interviewers will ask you in-depth questions about your past projects, and they’ll grill you on what you’ve done in the past. If you claim ownership of a project, you should expect some questions about it. You’re encouraged to use them for references and to bounce ideas off of.

I never felt any pressure to magically come up with a fully working solution, and it felt highly collaborative.

The others

In comparison, interviewing at Facebook and Google felt much more mechanical. They have one or two technical phone screens, and five to six onsite coding rounds. Each round involves some coding on a whiteboard, and you’re expected to come up with a near-perfect solution in a reasonable amount of time.

Facebook has two coding rounds, one design round, and one behavioral round.

I went through an additional shadow round at the end of the day, which didn’t count towards my overall score.

Google had five coding rounds, none of which focused on designs, and not a single interviewer asked about my previous projects. I don’t necessarily think this is bad. But I think it felt very mechanical and didn’t give much opportunity for the engineer to show what they’re capable of. Some people do well in these scenarios, much like some students do well in exams.

I did not enjoy my interview with Pinterest. I think the product itself is interesting, and their engineering team seems to be working on very cool technical problems. But I definitely had a negative experience during my interview there.

Pinterest has three coding rounds and one design round. Of those four rounds, the design round was most disappointing to me. Here’s why:

The interviewer came in late, and he spent a few minutes glancing over my resume before proceeding to draw some APIs on the board. He gave a short description of what he expected the API to do, and asked how I would solve it. We clarified the features of the API, and I started describing my solution using the whiteboard. About 5 minutes into it, I turned around and saw him taking a nap!

Not cool.

I gave the recruiter my feedback in a survey, and I didn’t hear back from them after that.

I won’t delve into specifics of the questions I was asked during all the interviews. Instead, I’ll share some of the insights and useful tips I learned from my preparation process.

What I learned:

  • Be honest on your resume. Most companies will ask you questions about your resume, and they can tell if you made it up. It’s better to be able to know 100% about one project than to know 10% about 10 different projects.
  • One-page resumes are recommended. This is especially true for tech companies, and it seems that the wisdom within the tech sphere is that you should reserve two pages and longer for post-doctoral work, or if you’ve done a lot of projects that you know and care deeply about. A friend of mine runs a company called Jobscan that scans resumes and makes specific, actionable improvements on them. They’re pretty awesome, so try them out :)
  • Socialize and establish a network. There’s a lot of competition for software engineering jobs, and these top tech companies are filtering through thousands of resumes a day. Having a referral will help you get some eyes on your resume.
  • Nail your pitch. Every company that’s interested in you wants to know why you’re interested in them. A bad answer: I just need a job right now to pay bills. A less-bad answer: I was browsing online and found you guys. Sounds like you’re working on interesting things. A good answer: I know you’re doing some interesting work in X to achieve Y. I’ve done some work in the past and here’s what I learned about A, B, C that might be related to X. I am passionate about Y because blah. (Don’t use this as a template. Instead, you should see the pattern here — do your research, use your background, and show the company why both of you would fit well together.)

Some more advice

Technical interviews are incredibly difficult, and sometimes it’s a hit-or-miss. The best opportunities, however, are reserved for those who are prepared.

  • Prepare early, prepare well. Everyone knows that they should prepare for an interview, but most don’t know how to do it well. As with anything worth doing, it takes deliberate practice to do well at something. And deliberate practice means you need to have a system.
  • Build a system to practice technical skills. I started by rating myself from 1–10 on how good I was, and worked on the ones I was worst at. I spent days on different types of questions until I fully mastered each concept. And I wrote notes daily on Evernote. I had a note that serves as a brain dump for all things programming. It is full of programming tips & tricks, common errors and misconceptions, frameworks for solving specific types of questions, and much more.
  • Keep a notebook of the things you’ve learned. I use both Evernote and OneNote to keep track of things. OneNote for technical stuff/code, because I like that I can easily format the note any way I like. I use Evernote for essays/thoughts. The image above shows a note I keep on architecture and system designs.
  • Jot everything down, even if you don’t think you’ll use it. I tend to forget very easily, so anything that I learn I write it down, including shell commands. I read technical blogs from time-to-time, and if I find anything interesting I jot it down on Evernote right away. I’ll revise it every week or month and reorganize accordingly. This has helped me tremendously over my career.
  • Get mock interviews. This was definitely very valuable and I highly advise it. I had mock interviews with friends and tried to practice as much as I could. If you can’t find friends to practice with, then I recommend Refdash, which is an Interview-As-A-Service. They have a group of interviewers who work at big tech companies like Google, Facebook, and Microsoft. These interviewers will assess you on your coding and design skills. The best part of it is they’ll give you a score at the end of it with specific actionable items on how to improve.
  • It’s OK to fail. I failed multiple interviews during this whole process. Sometimes you just have a bad day. It’s not the end of the world if you fail. Companies are biased towards saying no because it’s a lower risk for them. A false positive costs more than a false negative in the long run. The first few rejections definitely stung the most. I failed multiple phone screens when I first started interviewing, and my confidence level sunk. I had doubts in my mind about my abilities and started fearing that my skills weren’t relevant in today’s job market. However, I gave myself a tip: If you fail 10 times, then try 10 times more. All you need is one success. That reassurance gave me a lot of confidence to keep pushing through and when my first offer came through, the other offers came much more easily.

It took me about 2 months of deliberate practice and preparation for my interviews. I spent about 20 hours/week, or 80 hours/month, learning and writing notes on top of a full time job.

To build up my resume, it took 3.5 years of focused, deliberate work. I intentionally picked things that were tough and icky so that I could learn more than anyone else. Even though I don’t have a brand name university or top-tier tech company on my resume, I made up for it with a clear, thorough understanding of the projects I worked on. And this was possible because I researched and wrote down notes of everything I learned, and have a system to review them.

Remember: the strong survives, the tough thrives.

TL;DR: Don’t give up, set yourself up for opportunities, practice a lot, and stay hopeful. Focus on the process, and take a disciplined, dedicated approach to the process.

Tools I Recommend

  • Designing Data-Intensive Applications: Awesome book for learning about scaling distributed systems! Highly recommended.
  • Elements of Programming Interviews: Great for solving coding problems.
  • Cracking The Coding Interview: Great for covering foundational CS coding problems.
  • Daily Coding Problem.com: This is a free-to-try website that offers free daily coding problems. You can sign up for interesting daily coding challenges, and you can pay for solutions if you want.
  • Dropbox: I keep all my files, pictures, resume here. Easy access, installed once and available everywhere. Love it ❤️ (If you sign up thru this link, both of us will get free 500MB!
  • CodeRunner: I love this Mac app! I used this multiple times to run ad-hoc Python scripts/functions and it just works amazingly well. ?
  • Kafka the Guide: I used this book as a reference guide, and enjoyed it for the high-level description.

(I share more resources I personally have used and recommend on zhiachong.com, if you’re interested in learning more.)

Thanks for reading my story! You can find me on Twitter and LinkedIn. I would love to connect and talk more about tech, startups, travel :D

Credits:

Brandon O’brien, my mentor and good friend, for proof-reading and providing valuable feedback on how to improve this article.

YK Sugishita, an up-and-coming Youtube star who left his job at Google to pursue his dreams, for proof-reading and giving critical feedback.