Reflections on My Summer 2020 Internship

From May 2020 to Aug 2020, I worked for Snowflake, a Data Warehousing company. It was an interesting time to be at the company, given that I was there at the period leading up to an IPO later this year.

Snowflake#

Snowflake was probably both the fastest and largest engineering organization I’ve worked at til date.

The smartest engineers in the organization were probably in the query execution and database side, which I wasn’t really a part of. Nonetheless, it was my first experience working at a SV company and getting a gauge on what engineering here is like.

Personal Growth#

The technical growth I experienced came in phases. Most definitely, I grew the most when I first joined.

The first project involved learning about a library called ANTLR, which in turn required that I learn about compilers work. It took me some time to pick this up, especially because I did not have the foundational knowledge of how compilers work. I’d coded in Node before, but it was my first time using Typescript. I was uncomfortable and put myself in an environment where I had to learn, so I did.

Regarding learning the specifics of ANTLR, it wasn’t until I built something with it that I learned how it was integrated into the project. This is a learning pattern I’ve observed in myself—I struggle to truly grasp complex projects just from reading the code. It becomes all too easy to lose track of the larger architecture that surrounds it. Later on, I found that writing down diagrams and keeping track of definition paths definitely helped me.

Tackling Technical Complexity#

From this observation, I’ve take away a new approach towards tackling new code I don’t understand. It’s not so different from how I try to understand any subject that I find complicated—I simply ask a lot of questions until the picture becomes clear.

Most concepts in code become evident if you drill it into your head enough times. But certainly, there are some steps that you can take.

1. Read the code until you understand which parts you don’t understand.
   • It’s important to gradually identify what you don’t understand. Formalizing what you don’t know makes it addressable.
   • Write them down.
2. Write tests or interact with the code.
   • Test cases are a good way to test for the robustness of the code and its behavior. Specifically, I like it because often, it makes you write out the usage of the code itself, which is related to the purpose behind the code.
   • Throw in a shit ton of log lines; they often reveal side effects you might’ve not identified a priori.
     • A debugger might help, but I’ve not found VSCode’s Node debugger that great. GDB is really the GOAT.
3. Repeating 1 & 2, reduce the surface area of what you don’t know.
   • Change things in the code & see if the outputs match what you anticipated.
   • If you have the luxury of having a mentor, ask them the specific questions you wrote down in part 1.
   • If none of these are effective, you should consider building it from scratch yourself. This will give you the most intimate understanding of the code.

Regardless of how expedited your approach is, complex concepts require time and effort to digest. Often times, it warrants a conscious effort to bring it into your own understanding and intuition.

Know the Fundamentals#

I had a similar experience during the last quarter of my internship, when I switched teams so that I could try to learn more parts of the codebase. The task assigned to me was moderately difficult, but nothing beyond my abilities. Yet due to shortcomings in my approach, it ended up taking an entire two weeks—a lot longer than what I expected.

The task required an understanding of two concepts that I did not have at the time: 1) a basic understanding of Golang, 2) knowing how the browser stored and refreshed session metadata. On top of this, coding Golang on VSCode became unbearable, so I switched to Vim, which has a pretty high learning curve.

For someone who has a good grasp on these two things, my task would have taken them far less. Yet I found myself bouncing between these different concepts and just overall struggling to get anything done.

In retrospect, it would have been much better had I taken the time to learn the basics, then work through the more complex details surrounding the task. It’s the more sustainable approach since you’ll be able to build more knowledge off of it in the future.

The Engineer I Want To Become#

An interesting aspect of the internship was talking to individuals about their careers. Snowflake did have a lot of individuals from different career paths, and it was interesting to hear about their perspectives.

These are some of my own conclusions I’ve made through conversations with engineers. Some will certainly change in the future.

1. There’s a high demand for senior engineers not necessarily for new grads in the valley.

2. Working at a big company as a new grad generally entails working on more specialized parts of the codebase.

   • I’d rather be a generalist with a few sharp points of expertees. This is because I see code as a means of accomplishing what I want and usually not as an end itself.

3. A lot of engineers burn out because they don’t take the weekend off.

4. Working close with smart colleagues is usually when you improve the most, not when you work alone.

   a. The caveat here is that the individuals who started companies did not find that they technically grew a lot from starting companies. Rather, some pointed to more growth in other aspects (the business side, for instance). The quickest way towards technical competency is not to start a startup.

   b. This brings out a larger point. Growth is a lot more difficult if it’s merely internally motivated. I need to go out there to surround myself in a community where I can learn from other individuals.

5. Work culture makes a large difference & sacrifices of colleagues or environment for pay early on isn’t generally worth it.

6. You can start a company too early, and there are many opportunities down the line to do so.

   a. This is something I need to be wary of; I do not want to prematurely optimize.

7. Generally, as an engineer, no matter what path you take, it works out financially.

   • The perception of career risk in engineering is probably a little overexaggerated.

8. Talked to an engineer who just worked their job—they regret not building anything on the side.

Future#

There are a couple things I’d continue to do or do differently if I was given this opportunity again.

Continue to Do

1. Get to know colleagues personally and reach out for calls
2. Make myself uncomfortable and don’t settle for not learning new things.

Differently

1. Reviewing other engineers’ pull requests.
   • I didn’t do this, and had I, I would’ve learned so much more from learning about how other engineers approach problems.
2. Spend more time reading the codebase and trying to understand the codebase.
3. Studying concepts much more rigorously and deeply.
   • It’s not enough to learn the minimum to finish the task and forget about it.
4. Being more detail-oriented, especially with the way I write code.
   • I have this really bad habit of writing out the juicy crux of the code and ignoring the edge cases where the code could behave wrong. I need to be more paranoid about unexpected behavior and bugs.
5. Don’t optimize for beautiful code syntax alone, but its use case and how others might interact with it.
6. Write better tests not just more.