Landing A Job At Twitter As A Software Engineer [How I Did It]

This is the story of how I landed a job at Twitter as a full-time software engineer, what I went through, how I prepared and why I finally decided to join the company.

Click-clack-click-clack. The sound of my fingers furiously smashing the keys on the keyboard reverberated through the night.

I looked up from my laptop screen and glanced towards a clock on the wall of a basement apartment that I rent for $600 a month.

It was 2 in the morning.

Now you might think that I’m writing a piece of software or hacking away at something important. Why else would I be awake otherwise?

I wasn’t.

I was preparing for my upcoming technical coding interview using a website called https://leetcode.com/.

Fury took over me because I couldn’t reverse a linked list, which was rated Easy on the platform (try it here).

How I got here

An email from a Twitter recruiter arrived a week earlier, asking if I would like to schedule an initial phone screen with one of their engineers.

I was excited, but also nervous because I had applied to a software engineering position at Twitter a few years ago without success.

The recruiter had sent me a comprehensive prep sheet with links to practice and brush up on my coding and algorithms skills.

One of the items on the checklist pointed me to leetcode.com (a coding challenge website) and that’s how I ended up coating away on this website for hours in order to prepare for my technical coding interview.

It wasn’t easy preparing for technical interviews. For someone who has been out of college for some time, it takes a non-trivial amount of time to brush up on the skills and fundamentals required to succeed in a technical coding interview.

The recruiter explicitly emphasized that our technical interview will focus specifically on technical fundamentals, like maps, binary trees, linked lists, binary search trees, graphs, and so forth.

If I were starting out preparing from scratch today, I would try to seek out a much more structured approach so that I can maximize my preparation time. This is why I started a personalized coaching course, called Acing The Technical Interview, to help people prepare for their interviews as efficiently as possible and ace the technical interview so that they can avoid the pitfalls and traps I had to learn the hard way. Many other engineers have found success from the approaches outlined in the course.

My Background

I had 3 years of experience as a full-stack engineer at a startup, mostly on building microservices and API development on AWS stack. The stack was heavily focused on PHP, NodeJS, AWS SQS as a message queue, Postgres for our database, and AWS S3 for long-term storage.

I had neither prior professional experience nor internship experience and the job at the startup was my first “real” software engineering position.

I had a formal education in computer science — I graduated from a small, private Jesuit college in Washington state in 4 years with a bachelor’s degree in computer science.

Looking back, I think it was a valuable experience to go to college, and if I were to do it again, I would still opt for a formal education over a coding Bootcamp. You can watch my video here (link) for a breakdown of a 4-year degree in computer science vs a coding Bootcamp.

I applied to over 30 different companies, interviewed with 15, rejected by 6, received offers from 6, declined 5, and accepted 1. Read here if you’re interested in how I landed offers from top-tier FAANG companies without an Ivy League Degree.

If you’re counting, the math doesn’t line up perfectly because some companies ghosted after the onsite.

How I Prepared For Interviews

I spent the majority of my time on leetcode.com and a book called Elements of Programming Interviews. I also around 10% of my time browsing Youtube for systems design interviews, like Jack Gabbard (link) and Gauran Sen (link). Another I liked was DailyCodingProblem.com, which sends a coding question a day to my email, which allows me to get fresh new questions all the time.

Prep Time In Total

My preparation time was around a month of consistent, uninterrupted practice. It’s critical to have a consistent schedule. I used to go on coding spurts: 3 hours of hardcore coding and followed by a week of rest. I found that to be ineffective and I paid the heavy price of context switching multiple times.

In total, I spent about 3 hours a day on weekdays due to work, and 4 to 6 hours on weekends for a total of about ~20 hours a week for a month.

How I Applied

I applied to Twitter through their job careers page. In hindsight, it might have been more effective to find a referral or recruiter on LinkedIn because that would most likely expedite the application process.

A well-written resume is critical especially applying through an online career center. Without this, I don’t think I would be able to get an opportunity to interview with these top-tier tech companies. Read here about how I crafted my resume to get hiring managers to notice me.

A few weeks later, a recruiter finally reached out to me and would like to schedule an initial phone screen.

Timeline

• Feb 10 2017 — Recruiter reached out to schedule a TPS
• March 8 2017 — Initial TPS
• April 13 2017 — Second TPS
• April 18 2017 — Onsite
• May 2 2017 — Offer extended
• May 23 2017 — Twitter confirmed
• July 24th 2017 — official start date

The first 2 technical phone screens involved coding on a shared online document, like Google Docs. We talked about different approaches and tradeoffs, and spent 30+ minutes on the implementation.

After the two rounds, I was moved forward to the next round of onsite at Twitter Seattle.

The recruiter then sent me a link to an online coding repository, and asked me to do a code review, make suggestions on how to improve, and discuss it with the interviewers onsite.

I took about a day to go through the code, printed it out on paper (about 5 pages long on 10pt font), and noted areas of improvement on the paper. This proved to be a useful exercise as I would discover later.

Onsite

The onsite had 3 rounds in total with a lunch sandwiched in between (pun intended):

• Breadth (75 mins)
• Depth (75 mins)
• Lunch
• Top-Grading (90 mins, Optional)

One thing to call out is that Twitter’s onsite rounds had 2 interviewers each round. It felt intimidating at first, being stared down by two interviewers who were judging me by my every move. But in reality, I liked it as it felt much more collaborative and we were bouncing ideas between each other.

Breadth (System Design)

The Breadth interview focuses on a wide range of topics to understand how much you know about designing a system from scratch. The goal is to stretch the candidate to their limits and see how far they can go.

Are you able to build a reliable system with a reasonable downtime end-to-end, from setting up the UI to communicating via an HTTP API, to a building a backend service?

These are the types of questions asked. I enjoyed the conversation because I always like to tinker around with different technologies. If you enjoy building things, you’d like this round too. The interviewers were really nice and politely guided me along during the interview.

We ended with a coding question at the end. I honestly can’t recall what it was, but it wasn’t anything out of the ordinary.

Depth (Resume)

The Depth interview focused much more on my past projects and expertise. This was, in all honesty, much more intense and challenging because the interviewer dove deep into every single aspect of the projects I built and challenged the design decisions.

What was a project you built recently? Why did you build it? What were alternatives considered? Did it work in the end?

Coming from a startup background, I was responsible for building many things from scratch, like setting up AWS clusters, setting up SQS for processing tasks.

Even though I was intimately familiar with many projects, this round pushed me to the limits. I had to step back through my experience and tell the story from my perspective - why did we design certain things in certain ways and were there better/worse approaches we thought of.

No coding questions for this round.

Cultural

The Cultural round was a 90-minute interview with the hiring manager and senior leadership.

I found out later that if you make it into this round, that means you have done well enough technically and they’re looking for a cultural fit both ways — whether you fit into their culture and would they have the right opportunities for you.

No coding questions for this round as well.

Retrospective

Interviews at Twitter focus heavily on fundamentals of computer science, so making sure that you know your data structures from top to bottom left to right and also all the basic algorithms that you would have learned in your CS101 class.

Understanding how time complexity and space complexity trade-offs work.

Knowing and understanding one language really well helped tremendously. For this I recommend something like Python or Java or C++ as these are very commonly used languages. I personally enjoy using Python because it is very easy to read, very easy to explain, and it has a bunch of data structures built-in.

Make sure that to brush up on the projects listed on my resume. This meant understanding the entire design of the software I was responsible for end-to-end, understanding the trade-offs that were made in the system, and having reasons for why the systems were built that way and what were the alternatives.

Have discipline in your preparation. Figure out upfront the areas you’re lacking and set up a schedule to practice. It’s important to get consistent, uninterrupted practice. I started on the wrong foot and wished that I had known this earlier so that I wouldn’t waste time on the wrong things.

Think about the systems you interact with day-to-day. Figure out the trade-offs, alternatives, pros and cons, and how you can build a better system. This skill will carry you very far in software engineering.

Resources

• Rooftop Slushie — Rooftop Slushie helps you connect with employees at top tech companies like Google and Facebook. Get resume feedback, employee referrals, interview tips, career advice, and more
• Elements of Programming Interviews: Great for solving coding problems
• Cracking The Coding Interview: Great for covering foundational CS coding problems
• Acing The Technical Interview: Personalized coaching to help you ace the technical interview at top tech companies
• Designing Data-Intensive Applications: Awesome book to learn about scaling distributed systems! Highly recommended
• 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.
• Leetcode.com: Practice coding problems here
• (Check out resources page for more equipment, tools, books I highly recommend)

This story is also cross-posted on my personal blog, where I share my journey of becoming a professional software engineer. If you enjoyed this, please do consider sharing this with someone who'd benefit from it, and follow me on LinkedIn and Twitter.