What I Learned from Remote Startup Internship

I worked as Software Engineer Co-op at a start up from last August to December, and it was my first remote job experience and second software engineering job. I thought it was worth to share what I learn from the job and how it influenced me to develop my career

What I learned

1. Having a routine in remote setup is important. It is easy to get distracted in WFH setup so design your work environment so that you can focus on work. For me, I think it would have been helpful for me if I could separate work space and my bedroom (which was not possible for me last year). Create friction on possible distraction. For example, turn off your phone while you’re working and put it in another room.
2. Overcommunication is better than under-communication. In standups, make sure you provide enough context on the works you are working on. This not only help your teammates to understand your problem to help you out, but it also helps you to organize your thoughts and to have clearer understanding of the problem. It might seems like more work than needed, but trust me, it will save your time in the end. If you’re working remotely, writing clearly is extremely important.
3. Being independent is good, but try to maximize learning per time. It is crucial to maximize learning in early career, which will trigger compound effect in the future. Even though it might seems like a small step, it can add up really quick. Break down the problem to many sub problems, and set a short timebox for each subproblem (max 30 mins). If you’re stuck, it would be more efficient to ask questions instead of digging things by yourself. If it feels like the timebox needs to be bigger than 30 minutes, divide the problem into smaller ones. Also, be patient in learning! You are not going to learn every feature of the framework in 2 weeks. Take some time on reading documentation or going through tutorials if you are learning a new technology. Zoom out to understand the big picture, and zoom in to the feature you need to know to solve particular problem. You don’t have to memorize every little details in a month.
4. Think about side effects! Sometimes, an update can overwhelm the system so think about side effects of increased requests or workers. I had to make an update on our data system, and the update increased the amount of Sidekiq jobs tremendously which overwhelmed our system. We had a great team so we were able to manage the situation, but it was a good lesson for me to think about side effects more before deploying changes.
5. Take time to understand the problem clearly before dive into implementation. Communicate with stakeholders and truly understand what the real problem is. If you don’t understand or you think there might be better solution than what stakeholders want, do not hesitate. This might seems like waste of time to lot of engineers, but this is most crucial part of solving problem (understanding the real problem).
6. Ask lot of questions, and make lot of mistakes! Especially on the beginning! This is a fastest way to learn! We hate to make errors, and it is based on human nature. Acknowledge this and remind yourself that this is the best way to learn things. Also, if you are going to ask questions eventually, it is better to ask early than later to save time.
7. Have deep understanding in language and frameworks you use. You don’t have to have deep understanding in every language and frameworks out there, but it is important to have good understanding on technologies you use daily. You don’t have achieve this in short period of time (it can take years to achieve this), but spend some time daily and it will help you to become better engineer.
8. It is okay to have black boxes in your understanding! As mentioned in number 3, you sometime have to zoom in to understand deeply on specific feature to solve particular problem. However, it is still okay to have some black boxes. You don’t need to memorize all the minor details of the frameworks you are using. My approach would be understand the big picture of technologies I use by reading intro documentation or going through few hours tutorial, and if I feel like I understand philosophy and core idea of the framework, I will start learning details to solve my current problem.

Strengths I have (Based on feedback from teammates)

1. Communicating with staekholders
2. Asking “why” questions (don’t be afraid to keep going back to it)
3. Having a curiosity (keep asking questions!)
4. Trying to be active in meetings
5. Having a grit in a problem!

Technical Feedback from teammates

One of my co-workers said that he believe moderately learning deeply on two areas helped him to become better engineer, which are understanding in C and OS, and database system.

1. C and UNIX intersect: How signals work? How does debugger work?

• Book: https://en.wikipedia.org/wiki/A_Commentary_on_the_UNIX_Operating_System
• Strace: https://strace.io/
• Proc filesystem: https://docs.kernel.org/filesystems/proc.html

2. Databases: Understand relational model, What is happening inside this query, What are indexes, How postgresql actually works?

• Sqlite source code, including a quick “tour”: https://sqlite.org/src/doc/trunk/README.md
• Book 1: https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321
• Book 2: https://edu.postgrespro.com/postgresql_internals-14_parts1-4_en.pdf

I will spend little time daily to learn these.

What If You Go Back To School?

I asked my co-workers what they would do differently if they could go back to school.

1. Explore knowledge outside of computer science since it is hard to explore them after graduation, and they can definitely give you different perspectives to look at problems.
2. MS can be a good option if you are not really into what you are working on, and if you get paid well and your company is paying tuition. However, the value of a degree tends to go down as your career advances.
3. Realizing the importance of a company’s mission/product. The quality of life can improve a lot if you really like what you are building.
4. Use the interview process to evaluate if the company is the right suit for you.
5. Don’t be terrified if individual things go wrong, your career is organic and one bad thing is not going to ruin your career.
6. In early career, try to do a good job in what you are doing, but don’t try to sacrifice everything
7. Networking is not a bad word. Keep in touch with your old coworkers once in a while

Wrap Up

I had amazing time working remotely at a start up. Of course, there some things that I could have done better, but I learned a lot and it was great to work with fantastic engineers. I hope this experience will be helpful to my future career.