What I Learned Going from Twitter Intern to Full-Time Software Engineer

The past year has been a whirlwind as I transitioned from the military to a software engineering intern at Twitter and now to a full-time employee. It‘s been challenging, exciting, humbling and incredibly rewarding. I want to share my experience and some lessons learned along the way.

The Journey to Twitter

A little over a year ago, I was an enlisted airman in the US Air Force. I had taught myself to code through online resources like freeCodeCamp and built some side projects, but had never worked as a professional developer. Becoming a software engineer seemed like a pipe dream.

Through a lot of hard work and some fortunate connections, I was able to secure a summer internship at Twitter. Getting that offer felt surreal and I was thrilled to have the opportunity. But I was also daunted knowing I‘d be working alongside engineers with much more experience and formal education than I had. Imposter syndrome was real.

Drinking from the Firehose

My first few weeks as an intern were overwhelming to say the least. Twitter‘s tech stack is massive and complex. The core services are written in Scala, a language I had never used before. Large parts of the codebase utilize frameworks like Finagle, Thrift, and Mesos which were completely foreign to me.

In just my orientation sessions, I learned about Twitter‘s use of technologies like:

• Aurora for scheduling jobs across massive clusters
• Scalding for writing Hadoop MapReduce jobs in Scala
• Heron for real-time stream processing
• Flume for collecting and aggregating log data
• Scribe for aggregating streaming event data

And dozens more. It was a lot to wrap my head around.

I remember staring blankly at the IntelliJ IDE my first day wondering what all the windows and buttons did. It looked more complex than the instrument panel of the C-17 aircraft I worked on in the Air Force. But bit by bit, I learned the key commands and how to navigate the tool.

The sheer scale that Twitter operates at is mind-boggling. During my internship, Twitter was processing 500 million tweets per day and 200 billion read requests per day. The Hadoop File System stored over 500 PB of data. Graph databases like FlockDB stored over 100 billion edges.

Wrapping my head around numbers of that magnitude was tough. I had to learn to think in terms of distributed systems and massive parallelization rather than single process scripts.

When I got my first coding assignment, it took me forever just to set up my development environment by cloning the right repos, syncing dependencies, and figuring out the build system. I was used to running simple Python scripts, not spinning up clusters to test Scala programs.

Despite the steep learning curve, I tried to keep a growth mindset. I knew it was okay to feel like a novice and that the only way to grow was to continuously push beyond my comfort zone. Even if I only understood 10% of a codebase or technical design document, that was still progress.

Climbing the Mountain

One of the biggest challenges was prioritizing what to learn given limited time and mental bandwidth. There was an endless sea of information but only so many hours in the day. I had to constantly evaluate what knowledge would make me most effective in my work.

I focused first on core skills like getting comfortable with Scala and its ecosystem of frameworks and tools. I read books like Programming in Scala and Scala for the Impatient. I practiced coding interview style problems on HackerRank and LeetCode to get used to the functional paradigm.

When ramping up on a new service or codebase, I started by sketching out the high-level architecture. I‘d pore over design docs to understand how the components fit together. I‘d trace the path of a tweet through the system – from the user‘s app request, to the API, to backend services, to data stores, to the fan-out to followers‘ timelines.

Mentally mapping the topology helped me see the forest from the trees. Only then would I zoom in on the specific area I was focusing on.

Pair programming with senior engineers was illuminating. They taught me to break down large tasks into clear subtasks. To write code optimized for readability and maintainability, not just clever one-liners. How to use advanced IDE features to navigate and refactor code efficiently.

I learned to think more rigorously about edge cases, error handling, and performance at scale. Writing bulletproof code is crucial when you‘re serving hundreds of millions of users. A single missing null check can take down the site.

Code reviews were another learning goldmine. I‘d dissect the feedback, research the concepts I was fuzzy on, and figure out how to apply the suggestions. I tried to view each round of feedback as a free personalized tutorial.

Over time, all the micro-learnings compounded. After a few weeks, I was able to understand technical discussions in meetings and contribute ideas. After a couple months, I started writing design docs myself and leading small projects end-to-end. It was extremely gratifying to look back and see how much I had grown.

The Twitter Engineering Culture

The culture and caliber of the Twitter engineering team left a strong impression on me. Despite the company‘s size, the culture felt open and collaborative. Engineers were generous with their time and knowledge, always happy to hop on a call and whiteboard through a problem.

I was struck by how deeply engineers cared about the craft of software development. Everywhere I looked there were creators of popular open source projects, authors of programming books, and expert bloggers. Twitter engineers frequently presented at prestigious conferences and published academic papers.

But engineering skill was only one part of the equation. Effective communication and teamwork were just as important. Twitter‘s engineering culture placed a huge emphasis on clear written and verbal communication. I honed my skills in writing technical specs, giving presentations, and collaborating cross-functionally.

The high standards and rigor pushed me to level up. In every code review, I strived to write cleaner, more modular, well-documented code. I learned the best practices for testing and monitoring microservices. Techniques for releasing new code safely without disrupting the user experience for hundreds of millions.

I also gained an appreciation for the human side of software engineering. How to lead projects and influence without formal authority. How to give and receive constructive feedback. How to interview and mentor other engineers. These soft skills are often underrated but arguably just as important as raw technical ability.

Advice for Aspiring Engineers

For others taking a non-traditional path into software engineering, a few pieces of advice:

First, realize that much of your learning will happen on the job, not beforehand. It‘s okay to start before you feel 100% ready. No amount of personal study can fully simulate working on complex systems with a team. Pursue internships or apprenticeships to get real-world experience as early as possible.

Second, hone your problem-solving skills above all else. Technologies come and go but the ability to break down messy problems is evergreen. Practice algorithmic thinking and get comfortable with data structures and system design fundamentals. Cracking the Coding Interview is a good resource.

Third, focus your energy on a few core technical areas rather than trying to learn everything. Go deep, not wide. Seek to understand concepts from first principles. Learn to read documentation and source code. Build small projects using your target technologies to cement your understanding.

Fourth, cultivate a growth mindset. Embrace challenges as learning opportunities. Ask for feedback early and often. Adopt a craftsman‘s mindset, always looking to hone your skills. A sustainable career is one of continuous learning and reinvention.

Finally, don‘t neglect your communication skills, especially writing. Clear, concise writing is invaluable for everything from code comments to design docs to debugging with coworkers. Read classic essays on effective writing like The Elements of Style. Practice distilling technical concepts for non-technical audiences.

Conclusion

I feel incredibly fortunate to have found a full-time home at Twitter. The internship was a turning point in my journey into tech. I‘m still early in my career but the strong foundation from those three months accelerated my growth immensely.

If anything, I‘ve learned that becoming a successful engineer is less about what you know and more about your ability to learn and adapt. The tech world moves at breakneck speed. Many of the tools and frameworks I use today didn‘t even exist when I first started coding. What matters is constantly upgrading your mental models and being willing to step outside your comfort zone.

I‘m grateful to my brilliant colleagues at Twitter who invested in my development. Who created an environment where it was okay to ask "dumb" questions. Who gave me room to struggle and make mistakes. I wouldn‘t be where I am today without their mentorship.

To everyone else on an unconventional path into engineering – stay the course. The journey is long and winding but know that there‘s light at the end of the tunnel. With grit, curiosity, and a bias toward action, you will achieve your goals.

Keep learning. Keep building. And don‘t forget to document and share your learnings with the next generation. They might just be crazy enough to follow in your footsteps.