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

How I started my journey


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 was renting for $600 a month.

It was 2 in the morning.

Now you might think that I was 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 Leetcode. 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 there

An email from a Twitter recruiter had 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 (a coding challenge website) and that’s how I ended up coding 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 would 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 could maximize my preparation time.

This is why I started a personalized coaching course, called Acing The Technical Interview.

This course helps people prepare for their interviews as efficiently as possible so they can ace those technical interviews and 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 with 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 didn't have any prior professional experience or 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. 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 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, got rejected by 6, received offers from 6, declined 5, and accepted 1. If you’re counting, the math doesn’t line up perfectly because some companies ghosted after the onsite.

You can read more here if you’re interested in how I landed offers from top-tier FAANG companies without an Ivy League Degree.

How I prepared for interviews

I spent the majority of my time on Leetcode and with a book called Elements of Programming Interviews (highly recommended).

I also spent around 10% of my time browsing YouTube for systems design interviews, like Jack Gabbard and Gauran Sen.

Another resource / website I liked was, which sends a coding question a day to your email. This allows you 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 hard-core coding 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 to jobs

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've most likely expedited the application process.

A well-written resume is critical, especially when you're applying through an online career center. Without this, I don’t think I would've been able to get an opportunity to interview with these top-tier tech companies.

You can read more 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 wanted to schedule an initial phone screen.

Timeline of my application process

  • 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 first two rounds, I was moved forward to the next round of onsite interviews at Twitter Seattle.

The recruiter then sent me a link to an online coding repository, and asked me to do a code review. I needed to make suggestions on how to improve to code, 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.

The Onsite Interview

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 off each other.

Breadth (System Design)

The Breadth (System Design) interview focuses on a wide range of topics so they can 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.

They asked questions like this:

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?

I enjoyed the conversation because I've always liked 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 my 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, and 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.

Top-Grading / 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.

Interview process retrospective

Interviews at Twitter focus heavily on fundamentals of computer science. So make sure that you know your data structures from top to bottom and left to right. It's also a good idea to review all the basic algorithms that you would have learned in your CS101 class.

Here are some other tips:

Know your algorithms in-depth

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

Know one language really well

Know and understand 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.

Do a résumé review

Make sure that to brush up on the projects listed on my résumé. 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.

Be disciplined in your preparation

Figure out upfront the areas you’re lacking in, and set up a schedule to practice. It’s important to get consistent, uninterrupted practice.

I started out on the wrong foot and wished that I had known this earlier so that I hadn't wasted 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 I recommend

You can read more of my articles about technology 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 Youtube, LinkedInk and Twitter.

I'm also launching a new course that goes into what interviewers are looking for, how you can prepare, and how to maximize your chance of landing interviews and getting the job you want.