by Jordan D. Jackson
What I learned going from Twitter intern to full-time Twitter software engineer
More coding and growth!
*Looking at the calendar* Whoa! Has it been six months already?! On the first day of my Twitter internship, I knew it was going to take forever to see the end of the tunnel, but here we are. I am a full-time engineer at Twitter!! ?
It was definitely a sprint, and I learned more than I could imagine. I am happy I could soak up most of the knowledge. Now I want to take the time to write about my experience completing the program. I know most internship programs have simple paths to full-time employment. So I want to highlight some of the phases I went through, pitfalls I faced, and reflect on everything that I learned. If I can assist one person on their coding journey from this post then → ?!!
Note: If you are curious about how I landed the Twitter internship, that story can be found here: How I went from enlisted Air Force to software engineer intern @Twitter
As soon as I found out I would be interning at Twitter, I felt like the biggest engine in the world. Full of energy, and ready to conquer whatever projects were unfortunate enough to land on my path.
Except, an engine is nothing without the rest of the car, and it is unlikely that you will show up as a full car. Even if you have worked as an engineer before, there are things that vary from company to company. But on-the-job training will be your new best friend. With a good bit of this you will be cruising in no time!
The first step towards building the rest of the car was the New Hire Orientation. It was here that I realized that Tech Company XYZ does not base their stack off of the FreeCodeCamp calculator project.
During orientation week at Twitter, engineers are given an overview of how Twitter works and details about how the pieces come together to make it happen.
At first it evokes a woah-this-is-insanely-complex type of emotion. ? After you start actually working through, it will make a lot more sense. All of a sudden you will be working on a project and come across stuff you remember hearing about in orientation. Make sure you do not feel, think about, want, or consider the need to dive into every piece of the stack.
Still these high-level explanations are helpful. They help you see the big picture and how your team contributes to the mission of the company. So while I was anxious to get started, giving myself the time to get settled in would have allowed me to ramp up a lot more smoothly!
Starting at a new company in an entirely new industry doing an entirely new job was a massive shift for me. I suddenly felt like I was in basic training all over again. When I started, I did not even know how to use a Mac. ? I have been a PC person my whole life. It is a pretty scary feeling, because as a new hire, you want to provide value — and instead you can sometimes feel pretty useless. Just be patient with yourself. Not having this patience was one of the most challenging things to deal with when I first got started.
As I said, you have this engine that is ready to go all out. But there is a bit of work that needs to be put in before you can take over the world! Being patient will help you get productive faster. It will also help you not feel like a waste of oxygen while you learn. ?
To ramp up on the skills I needed to become productive, I knew I would have to break them up into stages. I wanted to learn the most necessary skills first, some productivity-boosting skills, and so on.
The issue I had at first was figuring out which skill in these stages to learn first. The number of things that could be learned was overwhelming. There was just so much newness surrounding me! However, I knew only a small fraction would be pertinent to what I was trying to accomplish.
Eventually I made learning how to use the new IDE my first goal. The editor I would be using is called IntelliJ and it has a crazy amount of buttons on it, and I was previously using Atom. So another huge switch!
When I was finally ready to write some code, my first instinct was to figure out how to do a small project that I was familiar with. Essentially doing a translation project with my new tools. So, here I was trying to get to a helloWorld Scala program (Yes I count this as a small project ?) to print to the console. I felt as if it was day one of FreeCodeCamp again.
After I got that project to work, I received a bigger practice project. The only problem was I did not know how to build and test this project with my new tools. What was even crazier was that I had built this practice project before (The Bit.ly style URL Shortener). So I knew how to implement the logic, and I could even persist the data. But, without Atom, NPM, MongoDB, and NodeJS I was lost! At least I was decent at navigating around the Mac at this point.
Learning a new language (Scala) and IDE (IntelliJ) at the same time slowed me down a bit. Needless to say it was a slow process for me to “feel” productive.
Looking back, I’ve learned that sorting and prioritizing which topics to learn now and which ones to dig deeper into later is immensely helpful. It actually may be easier to eliminate all the things you do not need to learn, and focus on what is left.
There were at least two or three things I dug into that, looking back, I had no business dedicating time to. If I could start over I would have started off exclusively with a few IntelliJ tutorials. This way I could have at least run simple programs and modified them to experiment with the environment. I know this may sound like a no-brainer, but when you are bombarded with fifty things you never heard of, it is a little difficult to sift through them.
No matter which route you take, it will all come together with time. Just do not stop. It is just a matter of how efficient you want to be! (Prius or Hellcat?) Before I knew it I was actually building projects! The joy I felt was awesome. I was writing Scala code, using IntelliJ, and even using my Mac without Googling how to use simple features. Definitely a “W” but still not the time to rest!
This section touches on a topic that many may have experienced. If you have not, here is a little heads-up in case you do one day! This topic is impostor syndrome. It has quite a few forms, but they all come back to not feeling like you are capable. The weird part is that you can experience this while having a track record of getting things done or proving yourself to yourself repeatedly.
I experience it almost every time I start working on a new project. I quickly find that there is ramping up to do for almost every project no matter how small. This knowledge gap that I have before each project makes me feel inadequate. This naturally leads me to the “Do I belong here?” mind-state. And I believe I have finally figured out why!
The fact that I do not have a formal CS education or even code boot camp training is a piece of it. I mean, I know I am not a total beginner, but that I also know that I am missing bits and pieces of core CS knowledge. For a little while my CS knowledge felt like a piece of Swiss cheese. With time, though, I filled a lot of those knowledge gaps and gained more confidence.
But this is not to say that was the end of feeling like an impostor! Almost every time I came face-to-face with a new project, impostor syndrome would resurface. ? I eventually learned that this resurfacing was just due to me having 0%–25% familiarity with a given project or codebase. This sounds like a “Well duh” type of thing, but when I got assigned a project my brain would just start racing to figure out how I am going to tackle it. My brain is thinking about the finish line, and at the same time it knows I do not understand all the intricate parts of the project. So my brain says something like “Bro, we have no clue what is going on here how are we going to do this?!”.
After digging into the code and reading the documentation, we would be back at “I got this!”. Please let the rest of you catch up. ? For me the analogy above is the majority of the reason why I would feel and sometimes still feel like an impostor. Now that I understand this more, I can argue with my brain and then relax to catch up. Anyone that experiences impostor syndrome knows that we always “catch up”!
Now my internship was awesome! I learned so much. But I would be doing everyone a disservice to leave out the most important feedback I received. Of course I am not perfect! ? So here is a list of the most common feedback I received during my six months of interning.
- Take notes (I have a good memory, but after meetings about different things you can forget some things). It was awesome to talk to my teammates in Slack. I could always just scroll up 24/7 and see details. If only I could have that for every conversation. ? Oh yeahhh, a notebook or a Google Doc.
- Give teammates more context when asking questions. I feel like this is a common issue for new engineers. I would ask questions sometimes as if the other person had been working in the same file and on the same line of code I had been working on. And not surprisingly it would lead to confusion, if not a wrong answer to my question. It is almost like calling someone on your phone and saying “Hey! Can you give me directions home?”. (Before Google Maps, GPS, and stuff like that of course) But if you say “I am at the intersection of Blah and Blah headed West and trying to get home, can you help?” they definitely can help a lot more! If they have a map aka their more senior engineering brain!
- Do not be a gladiator! Software development is a team sport. However, I could not shake the feeling that I had to prove myself. Not that I did not want to work as a team, but I felt I needed to show I could handle a project on my own. The only problem was…..I did not need to do this. This obsessive mission to prove myself only made me receive what I consider the only major negative feedback in my second internship. I mean unless you are creating a startup, you will have a team to support you! Work with them and everyone benefits!
Bonus: In addition to being more specific when asking questions, make sure you ask any and all questions you may have. This is super helpful advice for us out here teaching ourselves to code.
There is just no quiz to take to see if your knowledge compares to current junior software engineers. So frankly, you do not know what you do not know. And I feel like most of us accept this as true.
This is not an issue until you hear something that sounds like common engineering knowledge. If you ever hear other engineers chatting and you think to yourself “I probably should know that ?” this is what I am talking about.
As it turns out, it is TOTALLY fine if you do not know. As a matter of fact, some of the more senior engineers ask the exact question I was thinking of. Then you realize every engineer does not know everything. You then see that each member of the team all knowing a good amount is what makes the team powerful. And questions and sharing do the rest! Do not sit in fear of the topic being something basic that you should know. Ask away!!
To be totally honest, heading into this internship I had no idea what to expect. Just that I would write code at some point. I had never worked in tech or worked in a team setting developing software.
Overall, I think it went perfectly. From the successes I had along with the constructive feedback I received. Coming from the military definitely made it interesting! Especially after you are trained to follow orders for years and all of a sudden you have to decide most of your day-to-day workflow.
As always, though, I knew I would figure it out. Just like basic military training when we were bald and confused and had to figure out random stuff in 1.5 seconds. Only now I am not bald.
There are actually a lot of things I learned from the military that I feel help me a lot in tech. We will save that for another post, though. I also want to thank everyone that helped me on my journey and my family for dealing with the time away from them. I literally felt like I had a small village raising me to be a great engineer. I am super thankful and lucky for the support system I have. Thank you for reading!