June 21st 2020
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?
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.
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.
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.
If you’re counting, the math doesn’t line up perfectly because some companies ghosted after the onsite.
How I Prepared For Interviews
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 few weeks later, a recruiter finally reached out to me and would like to schedule an initial phone screen.
- 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.
The onsite had 3 rounds in total with a lunch sandwiched in between (pun intended):
- Breadth (75 mins)
- Depth (75 mins)
- 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.
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.
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.
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.